it's just too hard for microsoft to fix security bugs

| 32 Comments

There's been some back and forth on this URI protocol handler issue over the last week. It's been interesting to watch and I think it says a lot about how different organizations approach security.

Today, just as we've updated Firefox to help mitigate IE's URL handling flaw, Markellos Diorinos, a Product Manager for IE, says essentially "it's too hard for us to fix this."

The limitless variety of applications and their unique capabilities make it very difficult to have any meaningful automated parameter validation by the hosting (caller) application.

It's just too hard to get this 100% fixed so we're not even going to try. Is that the attitude you want from the people making your software?

At Mozilla, we were able to address the biggest part of this problem in Firefox ages ago by simply escaping quotes in URLs before handing them off.

When you're surfing the web in Firefox and a website wants to send an address to some other application like AIM or Skype or Acrobat Reader, Firefox packages up that address before handing it off to another application. We think it's Firefox's job to ensure that users are protected from malicious websites when they're surfing the web in Firefox. Apparently Microsoft doesn't think the same for IE.

update: Apparently there are cases where we don't escape quotes in URLs. We're working on it.

Saying it's too hard is not a justification for failing to take even the bare minimum steps to protect users. Microsoft needs to reconsider here and do what's right for the millions of IE users at risk instead of trying to shift the responsibility to "limitless variety of applications" that users have installed.

Making good software is hard. Making good software secure can be even harder. At Mozilla, we vigorously take up that challenge. We don't use it as an excuse for inaction.

32 Comments

Escaping out quotes doesn't make the FF solution any more secure. You can still buffer overrun an application with a custom protocol handler and there are lots of these out there: (ITunes, Outlook, Netmeeting, etc, etc.)

Escaping the quotes is just one vector each application needs to be responsible for it's own implementation. The assertion that FF is more secure or that Microsoft is less secure on this issue just isn't accurate.

Anon, so you agree with Microsoft Product Manager Markellos Diorinos that it's just too hard to stop every vector so Microsoft shouldn't bother trying to stop the most obvious one, the one that's well understood now, the one that's been fixed in other browsers for ages, the one that's responsible for several publicly known exploits today, the one that will undoubtedly be used to craft many more exploits in the coming days and weeks. Excellent.

"Because we can't fix this other, more difficult problem, we're going to ignore the one right here in front of us." That's definitely smart thinking. I like it.

- A

well this one bug was perhaps the most confusing browser exploit ever unlike other exploits you need ie and Firefox but you must use ie to exploit the flaw

It feels to me a little like instead of focusing on the specific issue, you decided to play politics. Maybe, let the facts and the experts do more of the talking. Humble is good.

Lloyd, the "experts" don't have any fuller understanding of this issue than I do. It's a bit complex, but not nearly complicated enough to require deferring to "experts" - especially when some of the experts are pushing what is clearly a marketing-driven message rather than a technical line.

Yes, humble is good, but humble often gets steamrolled by high-paid spin doctors from super-wealthy companies.

Microsoft and some of the tech reporters and experts would have the wold believe that that since Mozilla patched this flaw, every thing's fixed when that's far from true. The flaw still exists and millions of IE users are still critically vulnerable. And while these users sit exposed, MS is sitting on its hands or blaming everyone but themselves.

Sometimes taking care of users is more important than humility.

- A

I read somewhere that the exploit was made by using a Firefox URL handling component (registered as a Windows component) from IE. Whether this is true or false, it is obvious that Microsoft wants us to believe it and won't fix the problem because this time it sort of helps them to discredit Firefox.

Thus I see Asa's concern to take a part on this "expert's" discussion (by the way I used both ' and " in this post, awesome!!). I for one would never underestimate any body's expertise on anything, for I don't have any science titles of my own.

Regarding the issue about repairing a bug that encompasses infinite case scenarios: My web company deals with it every day, it is virtually impossible to develop web sites compatible with just every browser. But we deal with all 95.5% of the browser market, and we are happy with that. Who is going to use Browser-x anyway?

Thanks for the additional context. I have not been following this issue in the media, and your message makes more sense now.

Fixing this in issue in IE would not have solved your problem. And your problem was: Any appliction could use the protocol handler, you have written, to cause problems with your software. And why? Because you did not handle the input correctly.

In this specific case, encoding or adding quotes or whatever you make up, is just a workaround.

By not fixing this in IE, you are forced by MS to move, like it or not. And now the whole Web is a better place, instead of just IE.

Let me paraphrase the above...

"Microsoft should break an arbitrary and unknown number of applications to protect the Firefox developers from themselves... or, heaven forfend, from having to read the fucking API documentation"

because had they done so they'd have noticed that nowhere does it say "if the shell intuits that the application that this handler is tied to is incapable of processing input correctly, it will magically alter the data passed to the handler such that any current or future vulnerabilities will be mitigated"

Coming up next, OMG!!!!1!1!!1!n t3h Winblow$ haz a MA551Ve $3curity h01e: when I type del %USERPROFILE%, Winblow$ doesn't realise that I don't mean it... M$ is t3h SuXXoR... FF 4 EVAH!

I did a little bit of further research on this subject. I'm not sure if I am allowed to cite the sources in this blog, but to be short: IE has a terrible problem in not escaping quotes in it's URLs, no matter what kind of protocol they belong to.

This key issue (which would allow a whole lot of different exploits on different applications, and we are not talking about buffer overflow AT ALL, that is a completely different subject), is complemented by the fact that Firefox accepts (or accepted, since as of today I got the 2.0.0.5) some potentially dangerous parameters on its handler that might have led to execute javascript with chrome privileges. Hope I haven't been too technical.

Thing is: command line parameters are NOT supposed to exist, but since IE does NOT escape quotes, they are injected (this is technical, sorry) into the URI by clever use of quoting. Now that is a dangerous browser... lol

Am I clear enough?

It's pretty easy to go into this in non-technical terms, here are three easy steps to understanding the security flaw:

1. IE can currently be used as a vector for passing arbitrary code to any application that has a registered URI handler.

2. Firefox was putting users at risk because it could run that code as if the code were part of Firefox (i.e. it would have full access to your system).

3. Firefox, by changing it's URI handling, now no longer puts users at risk in this way. IE still passes arbitrary code to any application that has a registered URI handler.

This is one of those rare cases where Microsoft's response simply isn't even technically acceptable. The risk of breaking applications that actually tie-in with links in web pages should not ever outweigh the potential for computer hijacking.

If URI handling is broken, the worst that can realistically happen is that when you click a link, something on your computer doesn't start up when it used to. Hardly the end of the world and easily fixable assuming that the application is still in development.

It's all very well to say that application developers should follow APIs to the letter, but it's naive to rely on that actually happening, and is hardly an excuse for allowing an unsafe mechanism to exist as it currently stands.

You expose an interface, you have to handle it correctly.
You overlook something, your fault.
Relying on callers app in order to have only "clean" and "acceptable" input parameters is nonsense, 'cause only your module knows what is clean and acceptable.
It's called efficient distribution of responsability, and it's based on common sense.
So i think it would be nice to stop all this useless "yes we were bugged but look at that m$ attitude!" stuff...

You expose an interface, you have to handle it correctly.
You overlook something, your fault.
Relying on callers app in order to have only "clean" and "acceptable" input parameters is nonsense, 'cause only your module knows what is clean and acceptable.
It's called efficient distribution of responsability, and it's based on... common sense.
So i think it would be nice to stop all this useless "yes we were bugged but look at that m$ attitude!" stuff...

"It's just too hard to get this 100% fixed so we're not even going to try. Is that the attitude you want from the people making your software?"

I want non-ignorant developers.

First, Mozilla has plenty of problems where they say this same thing -- for example, handling of xml-stylesheet's media attribute (something Opera and IE both handle correctly).

Second, this was Mozilla's fault, not Microsoft's.

You have a public interface that is a boundary between code you own (trusted code from here on) and code you don't (untrusted code). You are assuming, first, that Microsoft is the only user of the interface -- that assumption is invalid. You are assuming that other processes are going through Microsoft's API -- which is again invalid.

On that boundary between untrusted code and trusted code, you failed to validate input.

This is no different than if you trusted that when you asked for a JPEG file, the web server was going to enforce that the JPEG file was actually valid, and did not contain any buffer overruns, etc. and it is a symptom of how Mozilla handles security, in general, and application architecture specificly.

The use case is you have a URL arriving via bookmark, via address bar, or via a programatic interface. The URL may or may not be valid, and may or may not contain invalid characters, escape codes, etc.

There should be one point where, regardless of how the URL enters the system, the software goes to retrieve the document (lets call it document.retrieve). That single point should perform validation. It should not be possible to bring a URL into the system, without going through that single point.

Then, when you delegate to the protocol handlers for HTTP or whatever, you probably need to repeat the validation unless you encapsulate URL's in an object (ala Microsoft's System.Url class in .NET), and use factory to construct them (so that they can't be constructed directly by untrusted code).

The protocol handler (which includes the command line handler) that was added is entirely based on the MS documentation for adding handlers. In the case of http IE does escape urls... in the case of FirefoxURL it does not. Both of these are marked with "URL Protocol" in the registry and the URL specification states clearly that URLs are to be escaped which IE does not for FirefoxURL though it does for http, https, ftp, etc. and IE does not escape them for all other applications that register URL protocol handlers (the IE to Trillian exploit is one example). As in the past, Mozilla has taken a defense in depth approach with the fix for FirefoxURL. I do believe that the IE team should do so as well by escaping the urls it hands off to other applications. If there really is an issue with breaking other apps then a new reg entry could be made or a value can be added to the URL Protocol reg entry for apps to determine if an url should be escaped (even though the spec states it should be).

No, the documentation does not say the URL would be escaped; it actually says that for URL protocols, the URL is unescaped.

All claims that Firefox escapes URIs are also incorrect. Use the MSDN example and create a webpage with the following link:

Click meClick me

Visit in Firefox 2.0.0.5 and note the alert.exe application gets two parameters.

Firefox suffers from the same "flaw" that you are slamming IE about.

Cite: Hey Mozilla, quotes are not legal in a URL:

http://msinfluentials.com/blogs/jesper/archive/2007/07/20/hey-mozilla-quotes-are-not-legal-in-a-url.aspx

Cite - Firefox and IE - one and the same:

http://msmvps.com/blogs/spywaresucks/archive/2007/07/22/1046725.aspx

Now that it has been proven that Firefox does exactly the same thing when it comes to passing data to protocol handlers, would you like to reconsider your statement that "The flaw still exists and millions of IE users are still critically vulnerable. And while these users sit exposed, MS is sitting on its hands or blaming everyone but themselves."

Sam, if we have flaws, we'll fix them. That's the difference.

- A

I find it amazing that you still assert that this is something that FF and IE need to fix. It is the **called** application that must validate, not the **caller**.

To quote Markellos Diorinos of the IE team:

"The limitless variety of applications and their unique capabilities make it very difficult to have any meaningful automated parameter validation by the hosting (caller) application. It is the responsibility of the receiving (called) application to make sure it can safely process the incoming parameters"

Ah, welcome to the world of "Why Mozilla still don't get security." A fundamental tenet of secure coding is that all trust decisions must be made *within* trusted code. You can verify all you like externally, but it is absolutely the responsibilty of the called code to validate any input before using it. It has to work that way round because YOU DON'T KNOW WHO THE CALLER IS or what their motivation is.

Stop trying to push the blame elsewhere. Accept responsibilty, fix the bug in your protocol handler and do an immeadiate code review of any other similar avenues for exploit. If we are to believe that Mozilla are actually committed to security, then it might be a good idea if at least some of the developers got a clue....

AndyC, we fixed the bug in our protocol handler last week. We're now working on fixing the bug in Firefox that would allow us to send dangerous URIs to other programs, just what we've said Microsoft should do.

- A

I read at this blog that Mozilla's, or more precisely Window Snyder's stance, goes against her own recommendations in her book with regards to thread modelling:

http://blogs.msdn.com/david_leblanc/archive/2007/07/24/security-dependencies.aspx

"... Frank Swiderski and Window Snyder wrote a rather dry book entitled "Threat Modeling" which we've used as the core reference for a lot of the threat modeling work that goes on at Microsoft. ... It's pretty clear that a URL handler would be making mistakes if it assumed anything about how well formed its inputs were, given that there's no telling what sort of browser it might be interacting with. I'm surprised at Window, since her recent statements are clearly in conflict with her own book. ..."

Sam, did you not read the comment directly above yours or the posts I've made on this subject? If so, I don't understand what you're saying.

We agree with what Window wrote. There's no inconsistency, and that's why almost two weeks ago we started work fixing Firefox and last week we shipped an update to all Firefox users to make sure that as consumers of URIs from IE, we no longer trust IE to hand us safe content.

We still think that IE should clean up on its end -- just as Firefox should clean up URIs before we hand them to AIM, or email apps, or whatever (something we've just fixed and will be shipping shortly.)

There's no inconsistency here. Before we ever called on Microsoft to investigate and fix on their end, we'd already fixed Firefox as a consumer of URIs coming from IE.

- A

Asa, I find your attitude curious.

There is ample evidence MS is very serious about security. To imply that they are not appears opportunistic. MS's code was written many many years before FF and has implications beyond browser use. If IE's (or perhaps it is windows) URI protocol handler was to start encoding URI's (when there is no requirement for it to do so) it would break millions of third party apps including my own, and quite likely it would break windows as well.

I don't see how encoding URL's before they are passed on really helps in any meaningful way at all, especially given that it is the responsibility of the callee to decipher the parameters. But I may not fully understand the issue.

Andrew, as the actual piece of software between your computer to the web, Firefox (or IE) should be responsible for protecting you from dangerous web content. Protecting users from bad guys on the web is the job of the browser maker. At Mozilla, we take that very seriously.

- A

Asa,

I'm sure you do take it seriously. My issue is a likely ill-judged swipe at MS, when on the surface there seems to be no substance.

Please post some technical evidence to back up your claims that IE needs to make this change to URI protocol handling.

@Andrew Hilton - there are lots of *philosophical* reasons why FF say they (and IE) should make this change, but there are also lots of philosophical reasons why they should not. FF were forced into a corner when Window tried to shift blame on to IE back at the beginning of this debacle, when she said that IE was at fault for not validating data it was passing to FF, when in fact it was FF's fault for not validating the data it was accepting, so it's going to be a bit hard for them to back away from that stance.

@Asa,

To suggest, as the Mozilla camp have said, that IE and FF should accept responsibility for validating data on behalf of a called application as an intermediary undermines a basic premise of threat modelling and secure coding - that premise being that a *called* application MUST validate the data that it is receiving from whatever application.

Yes, FF and IE should be responsible for protecting users from dangerous web content, but only insofar as they are the called application, not the intermediary.

I can only refer you, once again, to David LeBlanc's comments, to Jesper's comments, to Alun Jones' comments, to the IE team's comment, to all the other commentary out there that is trying to get FF to see that yes, they are responsible for validating data when it is the called application, but it is cannot go down the path of making itself responsible for validating data that it passes on to a third party protocol handler - you're making a heck of a rod for your own backs, going against RFCs and risking breaking who knows how many applications.

To quote Alun:

"Okay, let's take a look at Mozilla's fix. They've added code to percent-encode double quotes, and after a little discussion, to also percent-encode spaces. Not a security-savvy way of addressing this problem - if you're going to start messing with that URL, then use the "known good" principle. [That means that, if you know that alphanumerics and a few symbols are 'good', and don't need to be encoded, then everything else should be encoded.]

It's also not, as I pointed out above, an RFC-compliant fix, because now the URI is doubly-encoded, and then singly-decoded. [Perhaps this is why the Mozilla team fixing this bug chose to only encode a couple of characters? To forestall possible backward compatibility issues?]

It's not minimally invasive, and it still doesn't address the issue that a protocol handler might be written by someone who forgot to think about the security implications of accepting third-party input. I've thought up dozens of ways in which you could write a dorky protocol handler that was open to attack, and none of them can be, or should be, addressed by the browser that calls them."

David:

"Something else that's worth pointing out since I do have to ship code here and there is that we can never consider security in a vacuum. We also have to worry about app compat, usability and performance. If a browser started munging things passed off to a URL handler, what happens when someone built the CriticalBusinessApp URL handler? What if that app happened to _need_ quotes coming in? If we look at things from the browser's point of view, there's no telling what a custom URL handler may or may not be doing, and if we go changing any of the inputs, who knows what could break? Murphy's Law says it would cripple a large financial customer who spends a lot of money with us and cause millions of dollars of losses per hour. You really don't want to be the support person to handle that one."

Jesper:

"Now, one could argue that it would be nice if IE put some more restrictions on what it passed to a protocol handler, but not only is it difficult for IE to make decisions regarding what third-party plug-ins get to see, to put those restrictions on third party developers after the fact is even worse. It also is quite clear in the documentation that IE, or urlmon.dll rather, will pass the entire string on to the application. If the handles will parse parameters that can cause problems, then the invocation method used by FF is unsafe."

"In the case of the Firefox input validation failure, urlmon.dll is simply passing on a string it received as a command. It does not know what the called application considers legal and has no way to find out. It could potentially attempt to make the URL conform to a legal URL, but as urlmon.dll does no processing on the URL at all, it really ought to be up to the application that processes it to make sure it conforms to whatever conventions and rules that application expects. You cannot blame a web server for a SQL injection bug as it merely passes the input data onto the middleware application. It is the same in the case at hand; urlmon is simply passing on the input data to the protocol handler."

IE team:

"The number of potential applications (and protocol handlers) is effectively limitless, allowing for many new and exciting ways to enrich the Web. However, as with many extension models, there are security implications. In this example, one potential threat is that the custom URL may have dangerous parameters, such as strings that are too long and might cause a buffer overflow. The limitless variety of applications and their unique capabilities make it very difficult to have any meaningful automated parameter validation by the hosting (caller) application. It is the responsibility of the receiving (called) application to make sure it can safely process the incoming parameters."

Yes, FF were in the wrong for accepting data from IE without validating - you've fixed that particular issue and all credit to FF for doing so - but I believe that the further changes being made so that FF will attempt to validate data before it passes it on to who knows what application, are being made primarily because certain statements have been made and FF now have to live with them, rather than because it is best security practice. It's sad, because I believe that FF are now in a position where they feel that they cannot change their stance without even more embarrassment than they have already undergone, and that is a real bad reason to continue down the chosen path.

Sam, you're free to keep referring me to people I disagree with and I'll keep disagreeing with them. We are the user's interface when bad guys are attempting to harm them. We are the entrypoint into the system. It is our responsibility to do everything we can to protect the user.

We've never disagreed on the point that it is a called applications responsibility to validate incoming data. We immediately fixed that problem in Firefox when it was discovered and reported. That fix shipped about 10 days ago. We simply don't disagree on that point and have never said otherwise.

We do disagree on one thing though. We believe that as the user's first and most capable line of defense, since all web content comes through us, that we should do everything in our power to keep the users safe, even if that means helping to cover for unsafe applications on their system. Firefox is the entrypoint for the web and the badguys on the web. We are gatekeepers and we should do what we can to protect our users.

There's no backed into corners on this. When those statements you're talking about were made, we thought this was long ago fixed in Firefox and when we found out that it wasn't, we went right to work fixing it. That fix was completed yesterday and will be rolling out to 100+ million users very soon. We weren't backed into anything or forced into anything.

- A

Since all web content comes through the TCP stack as well, how about we fix this problem there, too? Can we also get those ethernet card manufacturers to fix it in their firmware? Let's call on Linksys and Cisco to fix it in their routers, and get the ISPs to scan traffic coming through them.

Alun, that's almost all meaningless to users. Users have little understanding of or interaction with those vendors and little choice or ability to change vendors if they're unhappy with the one they've got. They will hold one and one vendor only responsible for the crap that gets on their machine, the vendor of the software they associate with going online and that's Mozilla and Microsoft. If Mozilla and Microsoft cannot convince other parties to protect the users from the dangers of the web, then Mozilla and Microsoft must take it on themselves. Since Microsoft won't (and I understand the reasons why) fix this at the OS level, then Firefox will fix it at the application level. In the end what matters is that our users are as safe as we can help them be.

- A

Here's my weblog entry about it

http://weblog.asisred.com.ar/2007/07/31/firefox-es-seguro-otra-vez/

sorry it's in spanish... you could google-translate it... :)

Monthly Archives