[Top][All Lists]

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

Re: simple prob?

From: Phi Debian
Subject: Re: simple prob?
Date: Sat, 3 Jul 2021 06:17:42 +0200

Ha ok, I got it, I was focused on our interactive session. Surely a script
running on a UID behalf would be ill-advised to interpret (in the sense of
shell evaluation) an arbitrary shell expression.

On Fri, Jul 2, 2021 at 6:06 PM Greg Wooledge <greg@wooledge.org> wrote:

> 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.

reply via email to

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