February 04, 2004

The IE Patch (MS04-004) demystified

Michael has written a post demystifying what went into the latest IE patch. He also pointed out Microsoft's knowledge base article on the subject, with a registry setting to renable this "feature".

Interesting to note that in his first book entitled "Designing Secure Web-Based Applications for Microsoft Windows 2000", he even talked about the fact that developers should not rely on this functionality. Guess those scambling to deal with a work around to the fix should have listened more closely. More interesting is the fact he points to the exact reference in which the RFC specs do NOT support this hacked format... which means Microsoft was right in removing it. (Although they should never have had it in there to begin with... but thats another story)

Posted by SilverStr at February 4, 2004 04:56 PM | TrackBack
Comments

Dana you have a less-than sign before 'knowledge' that broke up your page. Feel free to delete this comment when you have it fixed :)

Thanks for the link btw.

Posted by: Gareth Lewin at February 5, 2004 12:42 AM

Ahhh, thanks Gareth! Duely noted... and fixed.

Posted by: SilverStr at February 5, 2004 08:34 AM

When I first heard MS was removing the login/password from HTTP url support for IE, I was incensed. How dare they remove something that is so obviously defined in an RFC!! I even went so far as to compose a posting for Cryptonomicon.Net about how Microsoft was "embracing and extending" the URL RFC.

But then I actually read the RFC, and sure enough, it doesn't say anything about requiring username and password on HTTP. FTP is a different matter, however.

So I have to agree with you on this one... MS probably shouldn't have introducted the functionality (at least not without posting an Internet Draft about it.)

From a standards perspective, what MS is doing is totally in the clear. There aren't any RFCs that explicitly require username:password in an HTTP URL. (though I think I saw an RFC that implied that username and password as a general scheme should be supported. I can't find that reference now, so maybe I was dreaming it...) From a developer relations perspective, they're taking the easy way out and are removing functionality that some customers have come to rely on.

The problem appears to be the way things are represented internally in IE. The issue with having a %00 in your URL is that the display code handles the decoded URL differently than the code that fetches the page. The display code clearly views the zero character as a null terminator while the fetching code does not. Doesn't give me a warm fuzzy feeling about how IE is put together.

In the end, though, MS is doing the right thing by putting security concerns above "functionality" concerns. In an ideal world, MS would do the fix right and provide both security and functionality, but clearly they're having some staffing resourcing problems and can't get sufficient internal staff to post a "correct" fix. So, in my book, MS gets a passing grade on how they handled this. Maybe a C+ or a B-. They would have gotten an F if they didn't remove the vulnerability...

Posted by: Matt Hamrick at February 5, 2004 09:07 AM

Check out rfc2396.
http://www.faqs.org/rfcs/rfc2396.html

Altough it is not recommended to use it (because passing creds on a url is unsafe), this format is documented there.

Posted by: Dumky at February 5, 2004 10:16 AM

Not sure this is the right place…

The display code for the Address bar was fixed. The display code for the Status bar was not fixed, and the status bar displays the truncated URL if the URL contains %00. But that’s not very important, as we all know the status bar text can be spoofed using client-side scripting.

What’s worse, the display code for the Properties dialog (which opens via the last item of the link context menu) also displays the truncated URL.

In the light of the change that disables the use of the userinfo@ part, the bug can only be exploited to conceal the query string and/or part of the path within one host, but that’s bad enough. I already envision the upcoming slew of spam that contains URLs with concealed parts like %00?validate_email=your@ema.il. By the time the user sees this part in the address bar, it is too late — the request has been sent to the server, which marked the your@ema.il as valid and alive.

(Of course, this means “Never click links in email”, “Never allow client-side scripting in email” and “Never have your mail reader automatically download images, stylesheets, inline frames and other linked files in mail”. Better yet, “Never read email in HTML”.)

Posted by: Centaur at February 6, 2004 12:55 AM