Exploits of 1990: mount_smbfs brings it on

Who doesn't remember those old root setuid binaries with argument parsing stack buffer overflows, the days when sudo had trivially exploitable vulnerabilities and system administrators panicked at the sight of any setuid binary after a some advisory showed up on BUGTRAQ. Apple had its share of bad luck with one of the latest Security Updates for Mac OS X. But it's 2007, approaching 2008 already, not 1997! Apparently, a regression was introduced into Tiger via one of the updates (in previous audits we didn't find this binary to be affected by this vulnerability), and made the mount_smbfs root-setuid binary vulnerable to a trivially exploitable stack-based buffer overflow, which allows (root) privilege escalation for any user on the system. The condition triggers when an overly long string is passed as parameter to the -W (workgroup name) option. Depending on how many registers you require, the padding size is approximately 1040+16 bytes for x86, to overwrite eip. One of the requirements to abuse this issue properly is doing a setuid(0) call, in order to make the root privileges effective. There are different possibilities to successfully exploit this issue:

• Control eax, return to setuid(), with saved eip pointing at system() and argument set to shell of choice (ie. use the SHELL environment variable value).
• Find a stable or almost stable location for your shellcode on dynamically allocated memory (in this case, heap memory). This might be tricky for this specific issue, since we are calling a command line tool that does very little use of malloc().
  • You might notice some data replication in a MALLOC_LARGE section... it could be in Unicode format.
  • Play with sending large arguments to the command line, any changes?
• As we explained in previous posts, on PowerPC you don't need to worry about bypassing NX stack: the stack is executable by default. It can't be easier.

Apple definitely needs to deploy some sort of Secure Development Lifecycle. Not because it was popularized by Microsoft, not because we want a cheap shot at Apple, but because it simply works. And we don't agree with some security practices at Microsoft as well (namely the ASLR of Vista; while it's more solid than Leopard's, it's still not enough for many real world scenarios — for in-depth documentation on the ASLR concept, read its PaX project documentation). Don't call it SDL. Make it the “Apple Secure Development iLifecycle”. But please, security updates also need to be tested against a regression test suite! We really enjoy using iWorks 2008 but we don't like vulnerable root-setuid binaries.