[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Arbitrary command execution in shell - by design!

From: L A Walsh
Subject: Re: Arbitrary command execution in shell - by design!
Date: Fri, 29 Oct 2021 11:59:02 -0700
User-agent: Thunderbird (Windows/20100228)

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]