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 :)