Overview of WebKit Vulnerabilities from 2006

(Note: I wrote this article probably back in October or so, it just got lost in the shuffle when I was posting all my articles I wrote before the site went live. I did update it though to add the one new vuln that has been found since I wrote this.)

I wanted to start talking a little bit about email clients so I thought I would talk about Outlook. Of course that's too big of a topic since it is intimately tied to IE, and it is difficult to sort out their different vulns. So then I thought I would talk about Thunderbird. But you know what? That's kinda tightly tied to Mozilla's rendering engine too, so I have sort of the same problem. So the next logical choice (for me anyway) is Apple's Mail right? But that got me thinking about the fact that supposedly in Mac OS 10.5, Mail is going to support "full html" rendering. Well, as it turns out, it's already using WebKit which is also the core component of Safari (and also open source, nicely enough). So I decided that I would talk about WebKit a little bit since it is also used by 3rd party components, for instance OmniWeb, and because I care more about the Mac vulnerabilities :P. So without further ado, here are some juicy WebKit bugs.

CVE-2006-4412: This is one of the interesting ones where it's a plain HTML page that causes the exploit. No fancy plugins or filetypes, it's just an exploit against the one thing which a browser is expected to be able to do flawlessly, render HTML ;). The CVE is missing the original advisory from Tom Ferris, so I tracked it down as it's worth checking his site as he's posted quite a few advisories for Apple products.

CVE-2006-3946: This bug comes to us courtesy of the [MoBB.html Month of Browser Bugs], specifically this one. See, so the MoBB post is talking specifically about Safari, but when all is said and done, it turns out to be a WebKit bug. This means that Mail would probably have been vulnerable as well. I don't think I could state the problem more concisely than the MoBB post, so I won't try: "Safari will dereference and call a pointer from the heap if a script element, inside a div element, redefines the document body." Translation Key: "script element" == javascript, "div element" == html tag for making a division in the webpage and used mostly with CSS. And "heap" is a portion of memory where…just kidding ;)

CVE-2006-3505: This one sounds like it would be interesting (potential code execution), however there are no details except those in Apple's security update. Any time something supposedly requires only a malicious HTML document (no plugins, ActiveX, etc) it has the potential to either be an ingenious exploitation, a boneheaded bug, or possibly both. Maybe "Jesse Ruderman of Mozilla Corporation" (reporter) would care to enlighten us? :)

CVE-2005-3705: A heap overflow with no details. This is a little weird as one of the credited authors is Neil Archibald aka nemo, a well known (to us Mac security people ) Mac hacker who has found many vulnerabilities and generally releases advisories via the company he works for, Suresec.

CVE-2005-2522: This one is a little weird as described. It says that Safari/WebKit was rendering links inside PDFs in such a way that they were not checked against Safari's "security checks". And it says that the absence of such checks can lead to code execution. So I'm not exactly sure whether the "security checks" are like just some sort of bounds checking, whether they are somehow related to validation such as when Safari asks you if you actually want to download an executable, or whether they are something else. I might actually try to look into this one.

CVE-2005-0976: To my recollection, there have been exactly 3 exploits through Safari which had actual proof of concept code which exploited if you had the "Open 'safe' file types" checked (and one of them was the sort of lame "widget" auto-installation one). This was one of them, and it used auto-mounting .dmg files. However, unfortunately the old PoC link seems to be broken. As the page says, the actual vulnerability was in calling XMLHttpRequest in JavaScript which could allow the attacker to read files on the system. Not "check the existence of files" like the two Acrobat vulnerabilities, I have talked about; actually read the file contents.