Firefox 2 crash exploit and IE7 address spoofing flaw surfaces
After all the media inflated flap over a minor Outlook Express flaw surfaced over Internet Explorer 7, a minor but true IE7 address bar spoofing weakness was found. At the same time, bug tracking mailing lists have been talking about a flaw affecting the just released Firefox 2. Bugtraq called the flaw "critical" though Mozilla's security chief Window Snyder insisted the report is wrong and that the problem was already "fixed" but admitted a crash condition remained.
Note: Secunia which lists both the Outlook Express flaw and the address spoofing flaw under IE7 made no mention of the Firefox 2.0 crash condition as of 10/26/2006 days after the Bugtraq reports.
The address bar spoofing weakness against IE7 happens when a small popup is spawned and a URL shows up with trailing spaces. The trailing spaces pushed the URL to the left and partially out of site which hides the actual domain and shows you a fake domain. If you click anywhere on the popup page or click on the background window, the left side of the URL and the actual domain name is revealed but the initial spoofing condition might be useful in a phishing attack to the unsuspecting user. This condition is repeatable when you click on the address bar and that is probably what is being exploited since the popup first shows up with the address bar in focus. The possible solution to this would be to strip out the trailing spaces (since spaces aren't supported in URLs anyways) when popping up browser windows or not allow it to start with the address bar in focus.
The Firefox bug was considered critical and "fixed" last month but it seems strange that Mozilla would leave a crash condition in Firefox 2.0. Any kind of flaw that can cause an application to crash has to be alarming because it might be exploitable. It sounds like some modifications were made to make the exploit condition less exploitable but a crash condition still exists. When I spoke with Window Snyder last month on the phone, she made it very clear to me that Mozilla would not argue about what is a flaw and what isn't a flaw and that they would simply just fix it. It's understandable that Mozilla is being defensive (like Microsoft and the Outlook Express IE7 issue) about the characterization of this flaw being labeled as "critical", but surely Mozilla will have to admit this may or may not still be a serious flaw since the exploit still crashes Firefox 2.0. At some point Mozilla would have to admit this is a problem and really fix it so that the browser doesn't crash at all.
Some in the blogsphere and tech media are blowing these exploits way out of proportion (mostly towards Microsoft) and are drawing hasty and inaccurate conclusions. They all need to calm down because neither next-generation browser from Microsoft or Mozilla have had any critical flaws yet and it's simply too soon to tell which one will end up more secure. Even if there is a critical flaw found in either new product, we need to remember that Firefox 1.x averaged 5.15 highly/extremely critical flaws per month in the previous 12 months while IE6 averaged 2.6 highly/extremely critical flaws per month within the same time period. These less critical issues in IE7 and FF2 so far don't even register as remotely exploitable conditions.
To give some proper historical perspective based on Secunia data, here is a chart of IE6 versus FF1 flaws. Note that this only includes flaws that are ranked above moderately critical or a 3 on a scale of 5.
Before anyone complains that the numbers are way too high and that Secunia's own advisories stats are way lower than the ones I show, please remember that a single advisory with 9 highly critical flaws is counted as 9 highly critical flaws and that Secunia's stats based only on the number of advisories is highly misleading.
Note that any highly or extremely critical flaw is remotely exploitable and can allow a hacker to commandeer the browser process. When the browser is run under an administrator user, the compromised browser can lead to total system compromise. When the browser is run under a limited user context, a compromised browser can steal, delete, or encrypt user files for ransom.