I'm releasing it now for a few reasons:
- The bug was already publicly noted here.
- 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.
- 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 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:
Let's see how this renders in different browsers:
Firefox (64-bit Linux)
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)
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)
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);
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.
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