RSSIE7/Firefox URI Handling Bug Caused by Windows After All
By Scott M. Fulton, III | Published July 30, 2007, 12:02 PM
An exploitable bug discovered earlier this month that was first believed to have been caused by Internet Explorer 7.0, before Mozilla was forced to admit that it afflicted Firefox as well, has apparently been traced back to a Windows API function.
The discovery may have been first revealed through the US-CERT Web site of the Dept. of Homeland Security, which now classifies it as a "Microsoft Windows URI protocol handling vulnerability." The function in question is an old favorite of malware writers: ShellExecute(), which was the subject of a notorious Windows 2000 exploit four years ago.
While Microsoft has yet to issue an official statement or bulletin making this discovery clear, it probably advised US-CERT with regard to its existence. The official government site this morning reads, "We are currently unaware of a practical solution to this problem."
While it awaits such a solution, the finger-pointing over who's responsible may continue to precede any rational discussion over who gets to fix it, as well as the impractical solution of working together to fix it.
The problem, as it now stands, seems to be this: After IE7 is installed on a system, or when a new operating system is installed with IE7 present, the ShellExecute() API function is handled differently. This is the call (or one of the calls) that a Windows application would place when it wishes to launch another application.
When a Web browser receives a URI that contains a resource identifier that obviously isn't http://, it searches the Registry for the external application associated with that identifier. It then launches the application that the Registry reports back, and passes it parameters supplied from inside the URI.
Intentionally malforming the URI is what opens up a browser to the execution of unchecked, remote binary code. Last week, Billy Rios, a senior security consultant for VeriSign , posted on his personal blog that he and a colleague were able to use the exploit to cause remote code execution in Firefox. Once IE7 is installed on a system, Firefox becomes vulnerable, as does Netscape Navigator 9 and the Mozilla open-source browser.
"It's time to take a good look at the registered URI handlers and how browsers interact with those registered URI handlers!" Rios wrote.
This caused Windows security expert and former Microsoft employee Jesper Johannson to take Rios to task for publishing news of the exploit prior to giving Mozilla an opportunity to patch the problem first. His implication there is, of course, that Mozilla is responsible for the problem...a responsibility which its security chief, Window Snyder, ended up assuming last week, with notable regret.
This week, Mozilla's internal bug tracker reports the issue Rios discovered with handling the malformed URI has already been fixed. If that's accurate, another patch may soon be issued, this time disabling Firefox's ability to process a malformed URI that ends up taking a null argument, and thus opening up the browser for remote code execution.
But even if Firefox emerges from this fracas patched -- albeit with its tail tucked between its legs -- will the root of the problem go unchecked? In other words, will the Windows API function that passed the malformed URI to Firefox in the first place be allowed to remain, if both IE7 and Firefox are capable of filtering out the null-argument malformation?
If not, could that bug perhaps be exploited in another way? Or with Microsoft maybe winning this round of finger-wagging, will it go on about its business?
"We are currently unaware of a practical solution to this problem."
Translation:
Basically, we didn't know that we weren't perfect and there couldn't be any way it was us. We don't have any idea as how to fix it and probably never will.
Score: 0
|Note to IE fanboys in previous thread...
SEE.
Score: 0
|This is utter rubbish. ShellExecuteEx wasn't updated with IE 7.0. It is a core OS feature - on Windows XP SP2 systems the most recent update was in the MS07-006 security update.
All this function does is look up the URL protocol handler in the registry - for example, http: is at HKEY_CLASSES_ROOT\http - and look for the shell\open key. If a ddeexec key is found under that key, it uses DDE to send the URL to the registered program. If not, it runs the command under the command key, replacing the %1 in the command line with the URL to be processed.
IE uses ShellExecuteEx whenever it encounters a URL protocol it does not handle internally - basically only http:, https: and ftp:. The Windows Explorer 'Run' dialog calls ShellExecuteEx when you enter a URL into the dialog (in fact, when you enter *anything* into the dialog). It's how Explorer locates a program when you double-click a document file.
The question here is a difference of opinion over whether certain characters should be escaped in the command line or not. The behaviour of ShellExecute[Ex] has not changed. Microsoft are simply saying that Firefox has to cope with whatever it's presented with; Mozilla are saying it would be nice if certain characters were escaped.
[UPDATE:] I have since discovered that Internet Explorer decodes URL-encoded (%-encoded) characters and passes the decoded version to ShellExecuteEx. This allows an attacker to inject " characters into the command line, terminating the URL argument, and allowing further command line options to be specified.
The simplest workaround is to place a special command line option in first position (included in the command line in the registry, before "%1") that indicates that the rest of the command line came from a URL protocol handler and should be treated with caution.
Score: 0
|I'm sure Microsoft will eventually get a fix on this. Whether Mozilla should also provide a fix is another question, since the root of problem is the choice of API. If not using ShellExecute() it'll limit the functionarity of Firefox, which I don't think the problem is this severe.
Score: 0
|DOH!!!:-)
Score: 0
|wherever the bug came from (no one really knows if its been 4 weeks and companies are passing blame on each other) it will still be fixed so im not worried.
Score: 0
|Since Microsoft fixes most problems with third party incompatibilities anyway, they'll likely issue a patch (unless Mozilla does it first).
My guess is that since FF for Windows is written...for Windows, and IE7 behaves different from IE6, FF has the bug because they rely on Windows's IE6 API to handle the request. When it changed, Mozilla didn't.
Yes, IE7 rewrites APIs that nearly EVERY WINDOWS PROGRAM uses for certain functions. That's why it is so hard to truley and completely uninstall IE. Unchecking the box just disables the iexplore.exe and such but the API's remain.
Score: 0
|"While it awaits such a solution, the finger-pointing over who's responsible may continue to precede any rational discussion over who gets to fix it"
Actually, Mozilla's been working on fixing this since it first surfaced. Our first fix, which already shipped to all of our users, prevents Firefox from being exploited from IE. Now we're testing our fixes to the second problem so that other apps cannot be exploited from Firefox.
- A
Score: 0
|"While it awaits such a solution, the finger-pointing over who's responsible may continue to precede any rational discussion over who gets to fix it"
Actually, Mozilla's been working on fixing this since it first surfaced. Our first fix, which already shipped to all of our users, prevents Firefox from being exploited from IE. Now we're testing our fixes to the second problem so that other apps cannot be exploited from Firefox.
- A
Score: 0
|Not having any 3rd party apps installed that use URI calls, can anyone out there tell us if UAC catches this or not?
Score: 0
|Jeebus, get your tech support somewhere else (or get a better OS).
Score: 0
|Thanks for nothing...
Score: 0
|Windows itself installs several URI calls, and you may be surprised what programs install calls. Check out the registry under HKEY_CLASSES_ROOT and search for a Value named "URL Protocol".
To answer your question, no. IE7 automatically invokes the program that handles the URI. Firefox will at least prompt you first.
However the program run will have the same access as programs normally have under your user account. Any elevation that program would normally request will prompt as normal.
Score: 0
|Thank you.
Much better than the first reply.
Score: 0
|You're useless.
This wasn't tech support. This was a question regarding the ability of such calls to wreak havoc within the UAC "sandbox" of Windows Vista.
Quite on topic and very relevant to the situation. Thus, completely unlike 99% of your posts, and your utterly pointless reply.
Score: 0
|Zaine, I have all sorts of respect for you from donationcoder.com, however, this comment was uncalled for. The comment he posted was asking if anyone could tell if this tripped vista's UAC since he doesnt have 3rd party stuff installed.
Score: 0
|Protected Mode in IE7 in Windows Vista provides some additional protection when a user clicks on Application URL Protocol links by notifying the user that “A website wants to open web content using this program on your computer” and requiring user approval before invoking the actual application.
http://blogs.msdn.com/ie...-protocol-handlers.aspx
Score: 0
|...and the flaming shall set you free.
Score: 0
|