[Top][All Lists]

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

Re: Testing for Shellshock ... combinatorics and latest(Shellshock) Bash

From: Stephane Chazelas
Subject: Re: Testing for Shellshock ... combinatorics and latest(Shellshock) Bash Vulnerability...(attn: Chet Ramey)
Date: Fri, 10 Oct 2014 16:27:12 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

2014-10-10 09:04:10 -0600, Eric Blake:
> On 10/10/2014 08:55 AM, Stephane Chazelas wrote:
> > But I can't see why the content of a variable should be
> > interpreted as anything else than an arithmetic expression just
> > because it's in an array subscript.
> For the record, there are vulnerable shell scripts in the wild that fail
> to sanitize their inputs before passing it through arithmetic expansion,
> all because MULTIPLE shells (bash, ksh, mksh, zsh) all have the same
> semantic decision of performing command substitution as part of
> arithmetic expansion.  For example:
> $ /usr/sbin/fsadm -n resize /dev/sdb '0+x[`id >/dev/tty`]T'
> demonstrates that fsadm is vulnerable for trying to do $(($1)) without
> sanitizing $1 first.

In this case though, it would still be vulnerable with a
strictly POSIX shell as with

/usr/sbin/fsadm -n resize /dev/sdb 'PATH=1'

The evaluation of $(($1)) when $1 is 'PATH=1' is required to
assign 1 to PATH.

What is unspecified by POSIX is:

var=PATH=1; : $((var))

so changing the shell so it no longer does assignments and other
expansions upon indirect/nested/recursive arithmetic evaluation
would not break POSIX compliance (so could be done by
ksh/bash/zsh when invoked as sh), but you'd still have a problem
if you did:

var=PATH=1; : $(($var))

But at least in that case, it's more obvious that you need to
sanitize the input.


reply via email to

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