Re: Arbitrary command execution in shell - by design!

[L A Walsh]

On 2021/10/29 05:01, Greg Wooledge wrote:
> On Fri, Oct 29, 2021 at 12:48:57PM +0300, Ilkka Virta wrote:
>   
> > Not that I'm sure the upper one is still safe against every input. I think 
> > issues with associative array keys have been
> > discussed on the list before.
> >     
> Sadly, yes.  Bash is the exploding barbed wire death match of programming 
> languages.  Every single feature of bash is capable of hurting you if you use 
> it in the naive or obvious way.
>   
Bash is a command_line console language designed to execute commands 
locally in the context of the user.  Local user access to a console,
from a security standpoint, is generally equated with root-access,
game over as far as being secure.  People have the wrong expectations,
if they expect the 'language that allows you all-access to your machine'
to be 'secure' when random users are permitted to use it.

Perl was developed with features that encompass the commands in shell
with facilities (like taint) that help the developer to catch
mis-use of raw-environment (including user) input.

If you need to develop a script for generic-untrusted third parties,
a shell-script of any sort is not a good solution.

Shell is good for non-malicious control of local system events.  As
soon as anyone untrusted can execute a shell script or has
generic shell access, you have lost system security. 

Stop blaming and shaming shell for doing what it was intended to
do by using it  in a hostile-user environment.  If you aren't
smart enough to choose the right language for a given purpose,
then you need to hire a trained programmer who does.  Note --
universities train computer scientists in design -- like collecting
requirements (including security) and making decisions for
further development.  That doesn't mean all graduates are equal.
Experience helps, but experience w/o any context in theory,
context, and what has been done before is very often wasted.

Note -- perl isn't a panacea.  It was developed as a tool, but
is, in its later life, being randomly changed to suite the wants
of its current set of developers (some who think documentation is
the same thing as code, and that the perl language should read the
documentation of those who write extensions, modules or packages).
I wouldn't personally recommend using a perl > 5.16.3, since with
5.18 and above, various incompatibilities with older perls were
(and are being) introduced.

Also, note, python isn't a shell-scripting language.  It may be
getting popular, but it was designed more for applications than for
operating system control.  It's more of a learning-language -- and
is being increasing used for such to replace 'pascal' -- another
teaching language that has been historically used in schools.

But stop thinking bash has security bugs because it lets users
(who have shell access and arbitrary root access to their machine
to "do things".  Because that's what it was designed for.

How much lameness Chett has introduced into bash to accommodate
the wrong users.