[12427] in bugtraq
bash 1.x - command substitution bug
daemon@ATHENA.MIT.EDU (Michal Zalewski)
Wed Nov 3 16:53:09 1999
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-2
Message-Id: <lcamtuf.4.05.9912122110230.4197-100000@nimue.ids.pl>
Date: Sun, 12 Dec 1999 21:10:36 +0100
Reply-To: Michal Zalewski <lcamtuf@IDS.PL>
From: Michal Zalewski <lcamtuf@IDS.PL>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
Content-Transfer-Encoding: 8bit
Rather dangerous bug is present in output processing after "command
substitution" in bash 1.xx. It seems to be NOT present in bash 2.0.x, but
I haven't found any bugreport on this vulnerability. I looked for:
'command substitution', 'ff', 'subshell' and '$(' CHANGES file, no
effects... Seems to be one of these 'silently fixed' bugs - IMHO the most
dangerous group ;) As bash 1.14.x is shipped with most of the
distributions and seems to be widely used - here's an advisory.
It's nothing than a possible reason of 'unexplainable' bugs - as long as
we're talking about unprivledged scripts/commands. But with scripts at uid
0 (no matter, launched by root or via sudo), it seems to be deadly harmful
- if only attacker has any control on output of one of the nested commands
- and usually he has. Real-life example:
HEADER="`head -1 $INPUT_FILE`"
If we can put 'magic' content into input file, we can put arbitrary output
on EVERY subsequent nested command - for example (yep, another real-life
example ;):
SAFEFILE=`mktemp /tmp/secure-XXXXXX`
...in this case, we can alternate rendered SAFEVALUE to anything we want
- what about making /etc/passwd our 'safe temporary file'?;)
Believe or not, usually it's wonderful weapon again custom 'anti-hacker'
scripts launched from crontab, as it process OUR files, OUR processes and
almost always subshells are called for some purposes (awk/sed/tr combos
are lovely)... Let's see, some ideas on malicious attacker-dependent
values used in root scripts:
- argv[]s (on sudo scripts)
- /proc entries (against home-made /proc scanners)
- file names (against home-made fs scanners)
- file contents
- hostnames (remote scanners)
- service banners (remote scanners)
- and much more...
Ok, ok, an experiment follows - no comments necessary:
[root@nimue:1 /testing]# cat test.sh
#!/bin/sh
FIRST="`cat $1`"
SECOND=`whoami`
THIRD=`echo something`
echo "[$FIRST] [$SECOND] [$THIRD]"
[root@nimue:1 /testing]# od -v -t x1 -A n test
54 45 53 54 31 ff 54 45 53 54 32 ff
[root@nimue:1 /testing]# cat test
TEST1˙TEST2˙
[root@nimue:1 /testing]# ./test.sh
[TEST1] [TEST2] [something]
...while the proper output should be:
[TEST1˙TEST2˙] [root] [something]
Nothing more to say... 0xff character has deadly meaning :P
Btw. has any of Midnight Commander developers an idea WHY mc is
still vulnerable on #lslR attack I've posted days ago? Seek BUGTRAQ
archives, people? Again, this problem does not affect Slackware, but
seems to be present in .tar.gz official releases?
_______________________________________________________________________
Michal Zalewski [lcamtuf@ids.pl] [link / marchew] [dione.ids.pl SYSADM]
[Marchew Industries] ! [http://lcamtuf.na.export.pl] bash$ :(){ :|:&};:
[voice phone: +48 22 813 25 86] <=-=> [cellular phone: +48 501 4000 69]
Iterowac jest rzecza ludzka, wykonywac rekursywnie - boska [P. Deutsch]
