Even if time for keeping this blog updated is becoming rather scarce, we couldn’t resist publishing a note about Quicktime again. It was on the news some time ago, due to another simple, classical stack buffer overflow flaw. It was related with RTSP interfaces again.

Our exploit pack already provides a reliable exploit against this and other recent flaws, and there’s no real exploit for this flaw publicly available (in terms of quality and reliability). It’s quite possible that so-called drive-by malware installation kits are making use of this flaw to infect unsuspecting users.

We expected Apple to perform some due diligence with Quicktime’s QA, since the last real 1990 style flaws have been all related to RTSP functionality, but looks like they are still missing some guidance. Hopefully it won’t take long for them to realize that something like SDL could significantly improve their product security.

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.

We’ve been coming across different annoyances in our quest of deploying YUI into one of our main products (a few more articles talking about its development coming soon), the Ruby on Rails content management system behind our almost-ready customer portal and corporate site. The problem comes mainly from the coexistence of our custom CSS and JavaScript code, and the YUI specific style-sheets and library files.

• TabView control is rendering the tabs with an incorrect height: possibly caused by style conflicts, but we have confirmed this is not the case (at least our CSS is consistent and not conflicting with YUI).
• Editor component is unable to adjust its size to a sensible default (in other words: it seems unable to match approximately the old size of the barebones textarea element).
• YUILoader is not liking our layout and failed to expose the YAHOO.widget objects properly. Thus we couldn’t make any real use of it without resorting to Event driven functions and slow transitions (as unpleasing as watching a textarea transform into the Editor UI in “real time” ).

The problems are really bugging us and we have considered moving to fully custom code, even if that means delaying the development of some other features that might be of higher priority. Hopefully we will solve the issues soon and keep YUI in place, since the functionality is really complete.