Archive for July, 2007
Tuesday, July 24th, 2007
**** UPDATE ****
Apparently this flaw affects Firefox users that also have IE7 (with full security patches) on their system. Just to be clear, this vulnerability is delivered through the Firefox browser, NOT IE. You simply have to have IE7 installed somewhere on your system for this to work (which is basically most WindowsXP Sp2 systems) You can read about the details HERE. So it seems once again… as my first post (HERE) about URI handling issues stated…. IE PWNS Firefox…..
On a good note… I’ve noticed that this Mozilla bug ID has been changed to RESOLVED – FIXED. That was LIGHTING FAST… I’ll be waiting for the patch to get pushed out…
**** UPDATE ****
IE has gained a LOT of attention from the way it handles registered URIs. We (Nate McFeters and I) have repeatedly mentioned that IE isn’t the only browser that has issues dealing with registered URI handlers. In fact, some of the behavior exhibited by URI handling issues by other browsers can lead to remote command execution…. some examples can be found here.
Once again…. these issues are shown using FireFox (188.8.131.52), Netscape Navigator 9, and Mozilla, but many other browsers are affected as well. It’s time to take a good look at the registered URI handlers and how browsers interact with those registered URI handlers!
Developers who intend to (or have already) registered URIs for their applications MUST UNDERSTAND that registering a URI handler exponentially increases the attack surface for that application. Please review your registered URI handling mechanisms and audit the functionality called by those URIs…
NOTE: If another program (outlook, notes…etc) has modified the registered URI handlers on your machine, these examples may not work…
Friday, July 20th, 2007
The resource (res://) protocol is built into Internet Explorer 4.0 and later. Typically, the resource protocol is used to pull resources like images, html, xsl… etc from DLLs and executables. You’ve probably seen the resource protocol in use and didn’t even realize it (take a look at the properties for the images on a typical IE error page). The resource URI (like other URIs) has access to software on YOUR local file system. So, it’s possible to call the resource URI from a remote web page, use the resource URI to check for the presence of certain executables and DLLs, then report back to a remote server whether that file exists or not. So in essence, an attacker can use the resource URI to:
- Enumerate the software on your machine
- In many cases, determine the exact version of software enumerated
- Use the enumerated software list to target specific exploits and attacks
The software doesn’t have to be “installed” for this to work… simply having the executable on your system can also allow for enumeration. I’ve posted a proof of concept HERE. The PoC should work for pretty much all versions of IE (including IE7). If you want more information about using the resource URI, check out our paper – URI Use and Abuse.
Now, before Firefox users start snickering, Firefox had a similar issue which was fixed recently. Their issue involved the “resource:” URI supported by Firefox browsers. Besides… FireFox has other URI handling vulnerabilities they should be worried about….
Tuesday, July 17th, 2007
When certain versions of Firefox are installed, the Firefoxurl URI handler is registered in the Windows Registry. I’m sure everyone has seen the various PoCs where Internet Explorer basically forces Firefox to execute an arbitrary command using the Firefoxurl URI… its pretty cool. Although I reported this to Mozilla shortly before Thor released his PoC on his blog page, my research was based off his original Safari exploit, so I think he should get full credz for this one!
Now… a few people have asked me whether I consider this an IE flaw or a Firefox flaw… and the answer is BOTH. Problems with URI handlers will not be fixed until BOTH the browser (in this case, IE) and the registered application (in this case, FF) change how URI handlers are used. Before you start accusing me of fence sitting, let me explain my stance and maybe give you some insight as to why I feel this way.
- IE doesn‘t properly sanitize parameters passed to URI handlers. There are a lot of different exploits that can be pulled off because of this lack of sanitization… everyone knows about the Firefoxurl example, but did you know about Netscape Navigator, or Trillian? Bad IE…
- Firefox registers the URI handler in the Windows registry. None of this would even be possible if Firefox didn‘t register their URI handler. Know that when you register a URI handler in Windows, that URI can (and will) be remotely called by web pages through the browser (including IE). Maybe the Firefox devs should have known a little more about how URI handlers are called before they registered their URI on my machine. Bad Firefox…
This is just the tip of the iceberg… really. Some colleagues and I have been looking into URI handler vulnerabilities for quite some time now and I can tell you this…. IE isn‘t the only browser that has problems sanitizing parameters passed to URI handlers… remote command execution can be initiated from other browsers as well. To make matters worse, EVEN IF the browser did its job and sanitized malicious characters, URI handlers can still allow attackers to pass argument values to applications on YOUR system. If there are flaws in the software that registered the URI, you are still vulnerable (as evidenced by the 2nd Trillian exploit). URI Handlers should be used with caution, browsers should sanitize, devs should understand the dangers of URI handlers before registering them, and anything dealing with URI handlers should be audited on a regular basis (as registering URI handlers greatly increases your attack surface)….more URI handler vulnerabilities to come… stay tuned. In the meantime, here’s a whitepaper about various URI uses and Abuses.