home *** CD-ROM | disk | FTP | other *** search
/ Hackers Handbook - Millenium Edition / Hackers Handbook.iso / library / hack99 / bash.parse.txt < prev    next >
Encoding:
Internet Message Format  |  1999-04-28  |  12.5 KB
  1. Date: Tue, 20 Apr 1999 21:25:47 -0400
  2. From: Shadow <shadow@OPERATOR.ORG>
  3. To: BUGTRAQ@netspace.org
  4. Subject: Bash Bug
  5.  
  6. Figured while everyone was working with bash, I might as well make this
  7. one public(I apologize if this is old news, apparently it hasnt been fixed
  8. if so).
  9.  
  10. If a user creates a directory with a command like
  11.  
  12. mkdir "\ `echo -e \ "echo + +> ~\57.rhosts\ " > x; source x; rm -f \x\ ` "
  13.  
  14. and someone cd's into said directory, either by accident, or whatever,
  15. then it will cause it to actually execute. I also did this with a passwd
  16. file, echo a user such as r00t::0:0:\57root\57bin\57bash instead of + + to
  17. the rhosts. Played with symlinks and a few other ways to see if perhaps
  18. maybe the system could trip it if a user made the directory in say /tmp.
  19. Granted it may be a long shot on the users part, the ability to do so is a
  20. bad thing IMHO. This didnt seem to work on any of my BSD boxes.
  21.  
  22. shadow - CLE
  23.  
  24. -------------------------------------------------------------------------
  25. Most Failure is due to giving up, not realizing how close to success you
  26. were - Thomas Edison
  27. -------------------------------------------------------------------------
  28.  
  29. ----------------------------------------------------------------------------
  30.  
  31. Date: Thu, 22 Apr 1999 13:10:52 +0200
  32. From: Henrik Nordstrom <hno@HEM.PASSAGEN.SE>
  33. To: BUGTRAQ@netspace.org
  34. Subject: Re: Bash Bug
  35. Parts/Attachments:
  36.    1 Shown    21 lines  Text
  37.    2 Shown    20 lines  Text
  38. ----------------------------------------
  39.  
  40. Shadow wrote:
  41.  
  42. > mkdir "\ `echo -e \ "echo + +> ~\57.rhosts\ " > x; source x; rm -f \x\ ` "
  43. >
  44. > and someone cd's into said directory, either by accident, or whatever,
  45. > then it will cause it to actually execute.
  46.  
  47. It is a vulnerability of the prompt parsing, or more specifically the \w
  48. or \W prompt escapes for showing the current directory. These get parsed
  49. before backquote parsing of the prompt string.
  50.  
  51. Workaround: Make sure the variable PS1 is set to something not including
  52. the above escapes when cd'ing into directories with backquotes or $ as
  53. part of their name.
  54.  
  55. Patch for bash-1.14.7 attached.
  56.  
  57. bug-bash@prep.ai.mit.edu has been notified.
  58.  
  59. --
  60. Henrik Nordstrom
  61.  
  62.     [ Part 2: "Attached Text" ]
  63.  
  64. --- parse.y.orig        Thu Apr 22 11:53:01 1999
  65. +++ parse.y     Thu Apr 22 12:56:34 1999
  66. @@ -2729,6 +2729,17 @@
  67.  #else
  68.                 getwd (t_string);
  69.  #endif /* EFFICIENT */
  70. +               if (strcspn(t_string, slashify_in_quotes) < strlen(t_string)) {
  71. +                   char t_string2[MAXPATHLEN];
  72. +                   int i, j;
  73. +                   for (i = 0, j = 0 ; t_string[i] && j < MAXPATHLEN - 2 ; i++) {
  74. +                       if (member(t_string[i], slashify_in_quotes))
  75. +                           t_string2[j++] = '\\';
  76. +                       t_string2[j++] = t_string[i];
  77. +                   }
  78. +                   t_string2[j] = '\0';
  79. +                   strcpy(t_string, t_string2);
  80. +               }
  81.  
  82.                 if (c == 'W')
  83.                   {
  84.  
  85. ----------------------------------------------------------------------------
  86.  
  87. Date: Wed, 21 Apr 1999 20:39:48 EDT
  88. From: Andy Church <achurch@DRAGONFIRE.NET>
  89. To: BUGTRAQ@netspace.org
  90. Subject: Re: Bash Bug
  91.  
  92. >Figured while everyone was working with bash, I might as well make this
  93. >one public(I apologize if this is old news, apparently it hasnt been fixed
  94. >if so).
  95. >
  96. >If a user creates a directory with a command like
  97. >
  98. >mkdir "\ `echo -e \ "echo + +> ~\57.rhosts\ " > x; source x; rm -f \x\ ` "
  99. >
  100. >and someone cd's into said directory, either by accident, or whatever,
  101. >then it will cause it to actually execute.
  102.  
  103.      Just to clarify, this only happens if PS1 (the bash prompt) contains
  104. \w or \W _and_ a prompt is displayed containing the bogus directory name.
  105. This means unattended shell scripts are safe.  As a workaround, use `pwd`
  106. in place of \w.
  107.  
  108.      Tested with bash 1.14 (it's the only one I have handy).
  109.  
  110.   --Andy Church
  111.     achurch@dragonfire.net
  112.     http://achurch.dragonfire.net/
  113.  
  114. ----------------------------------------------------------------------------
  115.  
  116. Date: Thu, 22 Apr 1999 03:18:48 +0200
  117. From: Marc Lehmann <pcg@GOOF.COM>
  118. To: BUGTRAQ@netspace.org
  119. Subject: Re: Bash Bug
  120.  
  121. On Tue, Apr 20, 1999 at 09:25:47PM -0400, Shadow wrote:
  122. >
  123. > If a user creates a directory with a command like
  124. >
  125. > mkdir "\ `echo -e \ "echo + +> ~\57.rhosts\ " > x; source x; rm -f \x\ ` "
  126.  
  127. It seems to me that this is related to the prompt string parsing. If yes,
  128. then bash is not vulnerable unless configured to display the current
  129. directory (correct me if the root of the problem is different).
  130.  
  131. Some additional notes:
  132.  
  133. - I was unable to reproduce this on my system, even when bash is configured
  134.   to display the current path in the prompt. (bash 2.02.1(1))
  135. - The original example seemed to have too much whitespace. I used:
  136.   mkdir "\`echo -e \"echo + +> ~\57.rhosts\" > x; source x; rm -f \x\`"
  137. - PS1 was set to \h:\w\$
  138.  
  139. HTH
  140.  
  141. --
  142.       -----==-                                             |
  143.       ----==-- _                                           |
  144.       ---==---(_)__  __ ____  __       Marc Lehmann      +--
  145.       --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
  146.       -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
  147.     The choice of a GNU generation                       |
  148.                                                          |
  149.  
  150. ----------------------------------------------------------------------------
  151.  
  152. Date: Thu, 22 Apr 1999 11:16:06 +0200
  153. From: Pavel Kankovsky <peak@ARGO.TROJA.MFF.CUNI.CZ>
  154. To: BUGTRAQ@netspace.org
  155. Subject: Re: Bash Bug
  156.  
  157. On Tue, 20 Apr 1999, Shadow wrote:
  158.  
  159. > mkdir "\ `echo -e \ "echo + +> ~\57.rhosts\ " > x; source x; rm -f \x\ ` "
  160.  
  161. Bash 1.x screws up during PS1 substitution (\w, \W). Bash 2.x does not
  162. seem to be vulnerable. Anyway, there's a hope even for those who want to
  163. stick to 1.x: replace \w with $PWD, \W with ${PWD##*/} (no guarantee).
  164.  
  165. --Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
  166. "NSA GCHQ KGB CIA nuclear conspiration war weapon spy agent... Hi Echelon!"
  167.  
  168. ----------------------------------------------------------------------------
  169.  
  170. Date: Fri, 23 Apr 1999 00:02:57 +0300
  171. From: Guy Cohen <guy@SPICE.ORG.IL>
  172. To: BUGTRAQ@netspace.org
  173. Subject: Re: Bash Bug
  174.  
  175. At this (Wed, Apr 21, 1999 at 08:39:48PM -0400) day, Andy Church wrote:
  176. .| >If a user creates a directory with a command like
  177. .| >
  178. .| >mkdir "\ `echo -e \ "echo + +> ~\57.rhosts\ " > x; source x; rm -f \x\ ` "
  179. .| >
  180. .|      Just to clarify, this only happens if PS1 (the bash prompt) contains
  181. .| \w or \W _and_ a prompt is displayed containing the bogus directory name.
  182. .| This means unattended shell scripts are safe.  As a workaround, use `pwd`
  183. .| in place of \w.
  184. .|
  185.  
  186. Unfortunately this is not true. here is why:
  187. rush:/tmp> bash --version
  188. GNU bash, version 2.03.0(1)-release (i586-pc-linux-gnu)
  189. Copyright 1998 Free Software Foundation, Inc.
  190. rush:/tmp> bash
  191. bash-2.03$ echo $PS1
  192. \s-\v\$
  193. bash-2.03$ cat ~/.rhosts
  194. cat: /export/home/guy/.rhosts: No such file or directory
  195. bash-2.03$ mkdir "\ `echo -e \ "echo + +> ~\57.rhosts\ " > x; source x; rm -f \x\ ` "
  196. bash-2.03$ cd \\\ \ /
  197. bash-2.03$ cat /export/home/guy/.rhosts\
  198. + +
  199. sh-2.03$
  200.  
  201.  
  202. --
  203. Guy Cohen <guy@spice.org.il>
  204.  
  205. ----------------------------------------------------------------------------
  206.  
  207. Date: Thu, 22 Apr 1999 17:43:24 -0400
  208. From: Daniel Jacobowitz <drow@FALSE.ORG>
  209. To: BUGTRAQ@netspace.org
  210. Subject: Re: Bash Bug
  211.  
  212. On Fri, Apr 23, 1999 at 12:02:57AM +0300, Guy Cohen wrote:
  213. > Unfortunately this is not true. here is why:
  214. > rush:/tmp> bash --version
  215. > GNU bash, version 2.03.0(1)-release (i586-pc-linux-gnu)
  216. > Copyright 1998 Free Software Foundation, Inc.
  217. > rush:/tmp> bash
  218. > bash-2.03$ echo $PS1
  219. > \s-\v\$
  220. > bash-2.03$ cat ~/.rhosts
  221. > cat: /export/home/guy/.rhosts: No such file or directory
  222. > bash-2.03$ mkdir "\ `echo -e \ "echo + +> ~\57.rhosts\ " > x; source x; rm -f \x\ ` "
  223. > bash-2.03$ cd \\\ \ /
  224. > bash-2.03$ cat /export/home/guy/.rhosts\
  225. > + +
  226. > sh-2.03$
  227.  
  228. That's a quoting error.  Look at the mkdir command you typed, and
  229. observe that the backticks are not escaped - thus even inside of ""
  230. they are evaluated.
  231.  
  232. Witness:
  233.  
  234. $ ls /drow/.rh*
  235. ls: /drow/.rh*: No such file or directory
  236. $ echo $PS1
  237. \$
  238. $ mkdir "\ `echo -e \ "echo + +> ~\57.rhosts\ " > x; source x; rm -f \x\ ` "
  239. $ ls /drow/.rhosts\
  240. /drow/.rhosts
  241.  
  242.  
  243. It doesn't even get .rhosts right - there's a space at the end.  You
  244. told bash to make the directory:
  245.   `echo -e \ "echo + +> ~\57.rhosts\ " > x; source x; rm -f \x\ `
  246.  
  247. Dan
  248.  
  249. /--------------------------------\  /--------------------------------\
  250. |       Daniel Jacobowitz        |__|     CMU, CS class of 2002      |
  251. |   Debian GNU/Linux Developer    __   Part-Time Systems Programmer  |
  252. |         dan@debian.org         |  |        drow@cs.cmu.edu         |
  253. \--------------------------------/  \--------------------------------/
  254.  
  255. ----------------------------------------------------------------------------
  256.  
  257. Date: Thu, 22 Apr 1999 15:44:35 -0400
  258. From: Chet Ramey <chet@NIKE.INS.CWRU.EDU>
  259. Reply-To: chet@po.CWRU.Edu
  260. To: BUGTRAQ@netspace.org
  261. Subject: Re: Bash Bug
  262.  
  263. > On Tue, 20 Apr 1999, Shadow wrote:
  264. >
  265. > > mkdir "\ `echo -e \ "echo + +> ~\57.rhosts\ " > x; source x; rm -f \x\ ` "
  266. >
  267. > Bash 1.x screws up during PS1 substitution (\w, \W). Bash 2.x does not
  268. > seem to be vulnerable. Anyway, there's a hope even for those who want to
  269. > stick to 1.x: replace \w with $PWD, \W with ${PWD##*/} (no guarantee).
  270.  
  271. This is correct; the bug was fixed in bash-2.0, which was released in
  272. December, 1996.  If you're still running 1.14.x, or earlier versions,
  273. you should upgrade to bash-2.03.
  274.  
  275. --
  276. ``The lyf so short, the craft so long to lerne.'' - Chaucer
  277. ( ``Discere est Dolere'' -- chet)
  278.  
  279. Chet Ramey, Case Western Reserve University     Internet: chet@po.CWRU.Edu
  280.  
  281. ----------------------------------------------------------------------------
  282.  
  283. Date: Fri, 23 Apr 1999 11:25:58 +0100
  284. From: Ph. Rueegsegger <philip.rueegsegger@BRUKER.CH>
  285. To: BUGTRAQ@netspace.org
  286. Subject: Re: Bash Bug
  287.  
  288. Date sent:              Thu, 22 Apr 1999 01:39:48 +0100
  289. Send reply to:          Andy Church <achurch@DRAGONFIRE.NET>
  290. >From:                  Andy Church <achurch@DRAGONFIRE.NET>
  291. Subject:                Re: Bash Bug
  292. Originally to:          shadow@OPERATOR.ORG
  293. To:                     BUGTRAQ@netspace.org
  294.  
  295. Hello together
  296.  
  297. > >Figured while everyone was working with bash, I might as well
  298. make this
  299. > >one public(I apologize if this is old news, apparently it hasnt been fixed
  300. > >if so).
  301. > >
  302. > >If a user creates a directory with a command like
  303. > >
  304. > >mkdir "\ `echo -e \ "echo + +> ~\57.rhosts\ " > x; source x; rm -f \x\ ` "
  305.  
  306. Not bad !
  307.  
  308. > >
  309. > >and someone cd's into said directory, either by accident, or whatever,
  310. > >then it will cause it to actually execute.
  311. >
  312. >      Just to clarify, this only happens if PS1 (the bash prompt) contains
  313. > \w or \W _and_ a prompt is displayed containing the bogus directory name.
  314. > This means unattended shell scripts are safe.  As a workaround, use `pwd`
  315. > in place of \w.
  316.  
  317. Sorry, with bash version 2.01.1 (supplied with SuSE5.3) is just the
  318. opposite of what you are clarifying. If one has \w or \W specified in
  319. PS1 to show the path, it does NOT happen and if `pwd` is specified
  320. instead of \w or \W it DOES happen.
  321.  
  322. >
  323. >      Tested with bash 1.14 (it's the only one I have handy).
  324. >
  325. >   --Andy Church
  326. >     achurch@dragonfire.net
  327. >     http://achurch.dragonfire.net/
  328.  
  329. Kind regards
  330. Phibus
  331. -----------------------------------------------------------
  332.                      Philip Rueegsegger
  333.                       System Manager
  334.  
  335. Bruker AG                Direct dial   : +41-1-825 93 46
  336. Industriestrasse 26      Telephone     : +41-1-825 91 11
  337. CH-8117 Faellanden       Telefax       : +41-1-825 94 69
  338. Switzerland              E-Mail        : philip.rueegsegger@bruker.ch
  339. -----------------------------------------------------------
  340.  
  341. ----------------------------------------------------------------------------
  342.  
  343. Date: Tue, 27 Apr 1999 16:38:15 +0200
  344. From: Peter J. Holzer <hjp@WSR.AC.AT>
  345. To: BUGTRAQ@netspace.org
  346. Subject: Re: Buffer overflow in BASH
  347.  
  348. On 1999-04-19 14:59:06 -0400, Adam D. McKenna wrote:
  349. > I really don't see the point of people posting bash bugs here.
  350. > Especially not bugs in old versions. There are a lot of bash bugs, you
  351. > can't gain any extra priveleges by exploiting them though.
  352.  
  353. You can, if you can trigger the bug in a script which is not running
  354. with your privileges - suid and cgi scripts are obvious examples.
  355.  
  356. So, posting bash bug reports at least reminds people that using
  357. bash - especially old versions - for such scripts is not a good idea.
  358.  
  359.         hp
  360.  
  361. --
  362.    _  | Peter J. Holzer             | Where do you want your keys
  363. |_|_) | Sysadmin WSR / Obmann LUGA  | to go today?
  364. | |   | hjp@wsr.ac.at               |     -- Tom Perrine <tep@SDSC.EDU>
  365. __/   | http://wsrx.wsr.ac.at/~hjp/ |        on bugtraq 1999-04-20
  366.  
  367.  
  368.