Apple ColorSync heap overflow

Apple just released the Mac OS X 10.5.8 update, which includes security fixes:

http://support.apple.com/kb/HT3757

One of the fixes is for a heap-based buffer overflow in the ColorSync component (which handles the parsing of ICC profiles). Limited details are here:

http://scary.beasts.org/security/CESA-2009-011.html

This vulnerability could likely be used to execute arbitrary code in contexts such as Safari browsing to a malicious page. Mail clients (both web-based and local client based) might make an interesting target.

This was discovered because the test case for my earlier LittleCMS (lcms) vulnerabilities happens to crash Safari when you hit it:

https://cevans-app.appspot.com/static/CVE-2009-0733.jpg

Beware the little pieces you use in your web app

I've just released the technical details behind some recently fixed vulnerabilities in mimetex:

http://scary.beasts.org/security/CESA-2009-009.html

"mimetex" is a little binary (written in the C language) used to render mathematical equations based on the TeX language. It looks very nice and is a cool concept to embed it in web apps. You can use a Google search to locate places that use it:

http://images.google.com/images?hl=en&q=inurl:mimetex.cgi

Unfortunately, the binary suffered from various classic stack-based buffer overflows as well as some commands that might leak inappropriate information.

So be careful what random little binaries and pieces you use to beef up your web app.

iPhone and Safari advisories

Catching up on a few items. I seem to have gotten a mention in a couple of recent Apple advisories:

iPhone 3.0 security fixes

Safari 4.0.2

It's one of the Safari bugs that interests me today, CVE-2009-1725 or an off-by-one heap memory corruption in Webkit. The patch says it all, really:

http://trac.webkit.org/changeset/44799/trunk/WebCore/html/HTMLTokenizer.cpp

Here's the faulty code:

checkBuffer(10);
// ignore the sequence, add it to the buffer as plaintext
*dest++ = '&';
for (unsigned i = 0; i < cBufferPos; i++)
dest[i] = m_cBuffer[i];

Turns out, that 10 should be an 11 so it is possible to write a semi user-controlled byte off-by-one off the end of a heap chunk. If you know what useful tricks you might do with that in the various heap implementations (Windows, Mac, Linux) -- please leave a comment.

Here's a demo HTML document:

https://cevans-app.appspot.com/static/webkitentityoffbyone.html

It tries to pad the HTML so that the errant byte is written off the end of the heap, instead of into buffer slack. Bear in mind that the most common symptom here is no symptom at all :) In Chrome / Windows, repeated refresh of that URL would occasionally render a random Asian character, but no crash.

vsftpd-2.2.0pre1 and network separation

Following on from vsftpd-2.1.2, I've just released vsftpd-2.1.0pre1:

ftp://vsftpd.beasts.org/users/cevans/vsftpd-2.1.0pre1.tar.gz

This further plays with the new Linux container flags: this time, CLONE_NEWNET. This flag creates a process with a separate (and empty) list of network devices and bindings. A process isolated in such a way can create network sockets but any attempt to e.g. do an IPv4 connect() to localhost (or any other destination) will get ENETUNREACH.

CLONE_NEWNET is a very new facility and is not yet generally available in Linux distributions. For example, Fedora 11 offers it whereas Ubuntu 9.04 does not.

When available, vsftpd uses CLONE_NEWNET for the unprivileged protocol handler processes (both pre- and post-login). This means a compromised handler process will no longer get access to sensitive networks such as localhost or behind the firewall. This is on top of existing restrictions on the filesystem, local processes and local IPC.

The use of CLONE_NEWNET does provide some design challenges -- fundamentally, the protocol handler needs to be able to connect() out to handle the PORT command. Also, the listening sockets handling PASV need access to network interfaces. vsftpd solves this by re-using its privileged helper architecture. The creation of any data channel network socket is now a privileged operation. The privileged side enforces that a connect() may only be performed back to the real FTP client machine. It hands the resulting socket to the unprivileged protocol handler which then gets to use it as normal since it is already bound to a real network interface and connected. I've checked that attempts to shutdown() and connect() such a socket result in EISCONN so hopefully there is no way to abuse the connected socket on the untrusted side to bypass the CLONE_NEWNET setup. Input welcome. This was fun :)

Clusterfuzzing

I've just noticed that a Google search for "clusterfuzzing" (including the quotes) has no hits. Therefore, I'm reserving the term :) All I need now is a new fuzzing angle and then I've got all the makings of a great presentation!

Actually, I do have a new twist on fuzzing. All I need is the bugs. Watch this space!

Bonus Safari XXE (only affecting Safari 4 Beta)

Here's another XXE bug for you (resulting in file theft), just to make the point that this class of bugs is well worth watching out for in client-side applications (such as a browser :)

http://scary.beasts.org/security/CESA-2009-007.html

The good news here is that this WebKit regression was quickly fixed by Apple -- and in time for the Safari 4 final release -- so no production browser should ever have been affected. Just the Safari 4 Beta.

Full credit here to Carlos Pizano who noticed the WebKit regression due to a collision with the Chrome sandbox. I just put together the Safari test case / demo:

https://cevans-app.appspot.com/static/safari4filetheft.xml

Apple's Safari 4 also fixes cross-domain XML theft

Safari 4 also fixes an interesting cross-domain XML theft. Full technical details live here:

http://scary.beasts.org/security/CESA-2009-008.html

XML theft can include highly sensitive data thanks to things like XHTML, AJAX-y RPCs using XML and authenticated RSS feeds. The example I have steals XML representing a logged-in Gmail user's inbox:

Safari 3 demo for users logged in to Gmail

I think there's a lot more room for browser-based cross-domain leaks (sometimes called UXSS or universal XSS). This is because the pace of new browser features is very high, and lots more functionality is being added that involves reference by URI. Every such addition is a possible vector for a missing or incorrect (e.g. 302 redirect tricks) cross-domain check; or even an ill-advised specification-based cross-domain leak.

This is one of the serious Safari bugs demoed but not disclosed at my PacSec and HiTB Dubai presentations. I forgot to note that my previous post on file theft was another.