bug-bash
[Top][All Lists]
Advanced

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

Re: simple prob?


From: L A Walsh
Subject: Re: simple prob?
Date: Tue, 29 Jun 2021 16:29:05 -0700
User-agent: Thunderbird 2.0.0.24 (Windows/20100228)

On 2021/06/29 15:49, Greg Wooledge wrote:
On Tue, Jun 29, 2021 at 02:58:28PM -0700, L A Walsh wrote:
njobs() { printf ${1:+-v $1} "%s\n" "$(jobs |wc -l)"; }

Using that with your input:

njobs 'x[0$(date >&2)]'

bash: printf: `x[0$(date': not a valid identifier

This is because you didn't quote "$1".
----
   $1 should never be quoted -- it is an identifier, and as such
cannot contain a space.  By quoting it, you are allowing inputs that
would otherwise be filtered out because they are not valid variable
names.

  Since you only ever tested
the cases where $1 was a valid variable name
----
It is only designed to work with $1 being an optional, valid variable name.
Anything else should fail.  There are times when putting quotes around a
var will enable problems.
, you never ran into that particular result... until now.
----
   I never ran into "invalid input" because I didn't program it to
accept anything other than a variable name there.

As you can see, the unquoted $1 underwent word splitting, so you're
effectively running printf -v 'x[0$(date' '>&2)]' '%s\n' "...".
----
Which is detected as "illegal input" and disallowed. If you don't enable
some security errors, they can't be as easily introduced.  I assert that you
should never put quotes around something that is supposed to be a variable name
since valid variable names can not be word-split.  Many of the items on your
website about bash cautions, are because bash disallows some sketchy constructs.
That's not a bash-caveat, but a bash feature!


This won't protect against all code injections, of course; only the
ones that contain a whitespace character.
----
Nothing protect against "all" 'X' or "everything", especially when talking about security. Security is best handled as a layered approach with different
layers protecting against different things.  There's no such thing as a
'Security Magic Bullet'. Just because NOTHING protects against "ALL" [anything] is not a reason to take extreme action. In fact realization that NOTHING is perfect is one of the better defenses against over-reacting in response to supposed security
flaws.







reply via email to

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