Re: simple prob?

[Greg Wooledge]

On Fri, Jul 02, 2021 at 05:45:23PM +0200, Phi Debian wrote:
> Regarding the code injection I am not sure I got it.
> 
> If you are sitting at a prompt, why would you trick
> 
> unicorn:~$ njobs_ref 'x[0$(date>&2)]'
> 
> when you could simply type
> unicorn:~$ date
> 
> I assume protected script/source (the ones you can't write into), are wise
> enough not to run command based on user input, in short I guess no
> protected script are doing thing like read in; eval $in :) that is the
> simplest code injection :) and then would never let you have a chance to
> enter 'x[0$(date>&2)]' at any time.

For functions that you've written exclusively for personal use, it's
not an immediate concern.  It's more of a thing that you want to be
aware of for the future.

Where it becomes important is when you're writing scripts for other
people to use, or which run as different user accounts, or with
different privileges.

The classic example of this is a script that's run by a web server in a
CGI environment, which accepts query parameters from the end user.  If
one of those query parameters is used in an unsafe way, it can execute
undesired commands on the web server.

Of course, there are *many* other places that shell scripts are used,
such as booting an operating system, starting various services, and
so on.  In some of these cases, there is no external input being read,
or the external inputs are "trusted" files owned and edited only by
the system admin (root).  But in other cases, untrusted input may be
read.

So, there's merit in adopting a proactive strategy to shell script
security.  Maintaining a slightly paranoid mindset can help you spot
potential security holes and possibly avoid disasters.