[1134] in linux-security and linux-alert archive
Re: [linux-security] bash security hole
daemon@ATHENA.MIT.EDU (Rogier Wolff)
Tue Sep 3 08:06:32 1996
To: linux-security@tarsier.cv.nrao.edu
Date: Mon, 2 Sep 1996 09:41:04 +0200 (MET DST)
From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
R. DuFresne wrote:
>
> On Sat, 31 Aug 1996, Rogier Wolff wrote:
>
> > R. DuFresne wrote:
> > >
> > > On Sat, 31 Aug 1996, Rogier Wolff wrote:
> > >
> > > > "R. DuFresne" <dufresne@darkstar.sysinfo.com> wrote:
> > > > > >
> > > > > > Just to clarify this, the way I found that I _was_ vulnerable,
> > > > > > was with this. NB copy the quoting exactly:
> > > > > >
> > > > > > bash -c "`/bin/echo 'ls -al\377who'`"
> > > > > >
> > > > > > However, note that the bit after the \377 is run the _next_
> > > > > > time you run the command, so you need to run it _twice_.
> > > > > > Hopefully this will help people who incorrectly believe
> > > > > > they are not vulnerable.
> > > > >
> > > > > As Jonathon and ZOLTAN have pointed out, a double run of the
> > > > > command line, fully quoted, proves the bug...
> > > >
> > > > That's odd. Mine does it first time around. The fixed version
> > > > passes the 0xff to ls, which complains.....
> > >
> > > Someone posted to bugtrack <I think> that if you add the zero <0>
> > > to the \377 so that it becomes \0377 it's interpreted right off....
> > >
> >
> > I just used my xterm's cut-and-paste to take the above commandline
> > and paste it into an xterm......
> >
> > I then did cursor-up and added ".old" to "bash". The first complained
> > "ls: unknown option y" and the second gave me ls and who output.
> >
>
> Seems to be really odd, different quoting produces different results on
> various systems. And those that are supposed to have fixed the 'bug'
> still fail with:
>
> bash -c "$(echo -e echo\\377who)"
>
> Some require a double play of the comamnd, some a single entry...
I run the "fixed" bash. I am still vulnerable. At first I thought Ron
must have made an error in patching his bash, but now it seems it is
more complicated than that oneline fix.
The vulnerability test with the backquotes shows I wouldn't be
vulnerable, but still......
Maybe bash should be compiled with "chars are unsigned by default"?
Would that break anything? (I'm not volunteering my system to try
that.... :-)
Roger.