Slashdot Mirror
Microsoft Security Patch Fixes URL Security Flaw
loteck writes "Microsoft has just released Security Update 832894. According to their official information, it affects all NT kernel versions of Windows and most versions of Internet Explorer. Here's a rundown of the important fixes, notably 'A vulnerability that involves the incorrect parsing of URLs that contain special characters' in Internet Explorer, as previously discussed on Slashdot."
I was under the impression that their fix was simply make http(s)://user:password@www.address.net invalid. If so, that's not so much a fix, as just deciding to break some functionality. Can someone confirm that this is what the "fix" actually is?
Jedidiah
Craft Beer Programming T-shirts
Seriously, though - I think one of the bigger changes in this release is that IE no longer support username/password in the URL (http://me:you@whatever.com). No more easy pr0n surfing.
Cemil.
Reality is, Mozilla is a far way from replacing I.E.
Perhaps so, but I use the web for business and recreation on average 6 hours a day, and have never in the last three years had to resort to IE.
Except, that is, for ensuring that web pages I write render correctly on the lowest common denominator.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
ftpaddress
login
hostport
Turns out this behaviour is specified in RFC 1738 (Uniform Reasource Locator), where it defines a URL as being of the form:
//<user>:<password>@<host>:<port>/<url-pa th>
Although the RFC does go on to stipulate that "[s]ome or all of the parts '<user>:<password>@', ':<password>', ':<port>', and '/<url-path>' may be excluded." Oddly enough, this form is broadly defined as being the general form of URLs, but is not the form of HTTP URLs (which lack the username and password). The RFC seems to indicate that this functionality was designed with FTP in mind - anyone know if MS disabled it for all URLs, or just http ones?
Cue The Sun...
You can read the details here and here (original thread). It was caused by an update released back in November 2003.
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
Exactly what Opera does
My university uses an Exchange 2003 server for its e-mail. Well apparently this patch breaks logon using Outlook Web Access on that server. Turns out the username and password is in the URL being sent to the server, the same thing this patch kills.
Not sure if this is the way it is with every Exchange server or if it is how my university's server is configured, but if you use OWA you might want to be careful with this patch.
...is the text of the update on Microsoft's Software Update Services service...
"...For example, an attacker could run programs on your computer while you view a Web page. This affects all computers with Internet Explorer installed (even if you don't run Internet Explorer as your Web browser)..."
although there's no mention of that in the KB article.
No for http requests the username and password are NOT allowed.
RFC 1738 - Page 8
3.3. HTTP
The HTTP URL scheme is used to designate Internet resources accessible using HTTP (HyperText Transfer Protocol).
The HTTP protocol is specified elsewhere. This specification only describes the syntax of HTTP URLs. An HTTP URL takes the form:
http://(host>):(port)/(path)?(searchpart)
where and are as described in Section 3.1. If : is omitted, the port defaults to 80. No user name or password is allowed.
Sorry, teleporters just kill you and then make a copy. A perfect, soul-less copy.
For starters, the MS page does not list Windows Me at all in the list of supported operating systems. But checking on my parents' machine (WinMe), that very cumulative IE update is listed on WindowsUpdate. I installed the update and here's how IE now behaves.
When going to *any* URL with an "@" in it, IE will come up with an error page titled "Invalid Syntax Error" with the content:
The page cannot be displayed
The page you are looking for might have been removed or had its name changed.
Once that error message is on the screen, any attempt to go to another URL with an "@" in the screen (by clicking on the URLBar and pressing enter, or typing in a different URL with an "@" in it) will cause IE to clear the page area to go blank and the throbber will continue spinning indefinately.
This makes it appear that there is some sort of network connectivity problem, or that IE is somehow hung up. Typing in a normal URL will show that everything is fine.
Also, this update doesn't fix the bug where IE displays an incorrect value in the status bar, such as this one: this one.
(Though clicking the link on that page will fail with the above described error page)
The security problem was spotted back in 1993 or 1994.
The problem was that the URI group was way out in hyperspace by then and not doing what people needed. There was an inordinate amount of effort went in to gopher URLs, the gopher losers wanted to have / be a normal character because it could appear in a Mac filename. The point about escape characters was lost.
Most browsers killed gopher because the protocol was so insecure, you could use a gopher URL to send any string you wanted to any port you wanted, ditto for finger.
The URIs that got used in practice were mostly the ones defined in Netscape. They did not give a wetslap for standards from the IETF or W3C, as far as they were concerned they defined the standard. They did not care much about security either, well not until it started to go embarrasingly wrong.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
2. You say that RFC 2396 supercedes RFC 1738, but you fail to mention whether this RFC is considered mandatory or not.
3. Even though RFC 2396 supercedes RFC 1738, it still doesn't allow the user:pass@host scheme for http://-URLs. Excerpt from RFC 2396:
The "some URL schemes" are those defined in RFC 1738 (since there are no definitions of specific URL schemes in this RFC 2396). So user:pass@host is STILL NOT ALLOWED or even mandatory by RFC 2396.