Slashdot Log In
Microsoft Flip-Flops On URI Protocol Handing Flaw
Posted by
kdawson
on Thu Oct 11, 2007 06:46 PM
from the so-it's-a-bug dept.
from the so-it's-a-bug dept.
a-twitter writes "After months of insisting there is nothing to patch, Microsoft has done a complete 180 on the URI protocol handling vulnerability, announcing in a security advisory that a Windows update will be released to revise URI handling code within ShellExecute() to be more strict. The MSRC blog explains the background and offers more details on this issue."
Related Stories
Submission: Microsoft Does 180 on URI Protocol Handing Flaw by Anonymous Coward
[+]
Unofficial Patch For Windows URI Hole 85 comments
dg2fer writes "For more than two months, the vulnerability of parsing URIs has been known for a number of Windows programs, including Outlook, Adobe Reader, IRC clients, and many more. Microsoft admitted the vulnerability only last week. The latest Microsoft patches published on October's Patch Tuesday did not include a solution, so hackers have taken on the problem themselves. One, KJK::Hyperion, has published (as open source) an unofficial patch that cleans up the critical parameters of URI system calls before calling the vulnerable Windows system function."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
like a dervish, they are (Score:5, Funny)
If it took them that many months, it sounds like they did a 1260.
Re:like a dervish, they are (Score:4, Funny)
And here I'm still saving to buy the 360...
Sigh...
Parent
Re:like a dervish, they are (Score:4, Funny)
Parent
Re: (Score:2)
Re: (Score:2, Funny)
Good. (Score:5, Insightful)
Re: (Score:3, Insightful)
Who's gonna be held accountable for that?
Re:Good. (Score:4, Funny)
Parent
Re:Good. (Score:4, Informative)
Parent
Re: (Score:3, Insightful)
Re:Good. (Score:5, Interesting)
Be afraid. Be very afraid.
[1] OB
Parent
Only a problem if you omit the http: (Score:3, Informative)
Visiting www.slashdot.org [slashdot.org] is broken
Visiting http://www.slashdot.org/ [slashdot.org] works fine
IE seems to store the http: in favorites etc., so it's not much of a problem.
Also it doesn't affect Firefox so almost nobody will notice.
Re: (Score:3, Informative)
www.slashdot.org is the name of a file in a location that IE searches for named shortcuts.
What IE is doing in this case is preferring an exact match over an autoguess.
The only arguement here is if IE should be searching the desktop for URL shortcuts, and considering how many people use their desktop in lieu of the favourites menu, I don't think that it's
Re:Firefox? (Score:5, Informative)
The mistake made by the GP (and potentially yourself, as you refer to the "blame cast" with the Firefox team which from memory only occurred with the issue in June with a malicious URIs terminating the quoted string and including Chrome parameters) is that they assume the second option is the one which is being fixed. It is not. This will potentially still be a problem if applications don't continue to validate their URIs appropriately, as Windows doesn't know exactly what your application does to escape quotes.
One of these is a vulnerability. The other is third party applications violating a basic tenet of development (no input is trusted).
Parent
Re: (Score:2, Informative)
OK, let's break down the steps to executing a program here. Now, I know Microsoft has their way of doing it, but really, it's exactly the same fucking thing with the same fucking array of arguments as parameters to the main function.
1) program A decides it wants to run program B with some arguments
2) program A assembles the argument list, and selects a member of t
Re: (Score:2)
What's exec()? Windows has ShellExecute(). ShellExecute for parameters accepts a single blind string. With this string, it passes it straight to an app to decide how it wants to interpret it. In your example, it's because it doesn't need to escape quotes to open "C:\Program Files\Somewhere" - which is good, because it has no idea how your application escapes quotes anyway. Does it use C syntax? Does it use BASIC syntax? Does it use Pascal syntax? Since it doesn't know these, i
Re: (Score:3, Insightful)
OT: Your last blog entry (Score:2)
Re: (Score:2)
which is good, because it has no idea how your application escapes quotes anyway.
Well, for a filename (your "C:\Program Files\somewhere" example is not a URL), this issue is mitigated by the fact that filenames cannot contain quotes.
It would not, though, be out of line for applications passing URLs into shellexec to escape quotes (at the very least, double quotes) with URI escaping syntax, in order to guarantee that _they_ do not contain quotes. They should already be escaping spaces, anyway, so this shouldn't have happened regardless
Re:Firefox? (Score:4, Informative)
Rubbish.
There's a whole shopping list of apps, including IE7 [secunia.com] itself that were exposed to this vulnerability. Firefox was just the first to be accused.
Microsoft's only changed it's tune because Adobe's on the case with the Acrobat vulnerability. It's one thing to force a FOSS competitor to unnecessarily patch, but they'll have no luck with trying to force Adobe to fix every PDF reader out there.
Parent
Re: (Score:3, Interesting)
Yes it does.
This is from the Technet mea culpa blog posting by MSRC's Jonathan.
With Internet Explorer 7 installed, the flow is a bit different. IE7 began to do more validation up front to reject malformed URI's. When this malformed URI with a % was rejected by IE7, ShellExecute() tries to "fix up" the URI to be usable. During this process, the URI is not safely handled. IE7 rejects the URI, and on Windows Vista ShellExecute() gracefully rejects the URI. That's not the case on the older versions of Windows like Windows XP and Windows Server 2003 when IE7 is installed.
Spin the facts as much as you like here, but anyone with a clue knows it is Microsoft's vulnerability. That's why they're the only ones who can fix it.
Re: (Score:2)
Most people (yourself included, apparently) don't understand that this is a two-way street. Microsoft can fix errors in their code, but they can do fuck all about what Firefox or Adobe Reader do with the input passed to them. But then it's so much fun to spin that part, isn't it?
Re: (Score:2)
Ooooh, that's so clever. Well, that does it for me. I won't bother you anymore, since surely there are other minions of the evil empire you must do battle with?
Good luck!
Re:Fanboy Bullshit at it's Finest. (Score:5, Insightful)
You must have slept through that whole anti-trust thing, where the Federal government proved that M$ did everything in it's power to break Netscape.
Psst. Netscape is not a competitor to Windows. Never was.
MS cripples themselves when they try and lean on Windows to get IE, or Office, or Visual Studio more market share. But Windows itself -- well, there's been to date, what, four serious attempts at competting with MS, and they haven't even managed to get half the market between them?
BeOS, UNIX et al, OS/2, and the Mac. All told, maybe 30% of the worldwide userbase. Microsoft is doing something right -- or else the "here, you can have this for free" crowd is doing something even worse than MS.
Parent
Re: (Score:2, Insightful)
Psst. Netscape is not a competitor to Windows. Never was...
MS cripples themselves when they try and lean on Windows...
Well, the grandparent never said that Netscape was a competitor to Windows, but it sure was a competitor with Internet Explorer. Considering that Internet Explorer completely crushed Netscape due to it being free and bundled with Windows (and, eventually, a better product), I think that Microsoft's plan of leaning on their Windows dominance to sell their other products seems like a pretty successful one. Of course, of these, only IE is "bundled". For Office and Visual Studio, it's really a two-way stre
Re: (Score:2, Insightful)
Re: (Score:2)
The Point: They're Still Missing It. (Score:5, Insightful)
> For traditionally "safe" protocols like mailto: or http:
And that's where my co-workers heard the cry of "You dumb motherfuckers".
It's been a few years since Microsoft boxes were out-of-the-box exploitable through anything other than rendering HTML content from either a web page or from within an email client.
While the planet is grateful for the lack of uPnP and DCOM/RPC worms of late, it also means that "things that have to do with email or web browsing" are among the least safe things you can ask a computer to do.
If you're at Microsoft, and you still think of "http://" as "safe", you're still part of the problem, not part of the solution.
Re:The Point: They're Still Missing It. (Score:5, Insightful)
And that's where my co-workers heard the cry of "You dumb motherfuckers".
Maybe you should have kept reading (or you're just quoting out of context to sensationalise):
And that's where my co-workers heard the cry of "You dumb motherfuckers".
It's pretty clear from context that the implication is other applications consider those prefixes as "traditionally safe", and not that Microsoft does.
Parent
Re: (Score:2)
Umm...no. Your interpretation, while literal, doesn't parse because applications have neither traditions nor opinions on safety, nor do they write themselves. When you expand the original sentence's subject appropriately, it reads like this:
Re: (Score:2)
Umm...no. Your interpretation, while literal, doesn't parse because applications have neither traditions nor opinions on safety, nor do they write themselves. When you expand the original sentence's subject appropriately, it reads like this:
And when you expand my sentence appropriately, you get:
At that point, it re
Re: (Score:3, Insightful)
While the planet is grateful for the lack of uPnP and DCOM/RPC worms of late, it also means that "things that have to do with email or web browsing" are among the least safe things you can ask a computer to do.
Which is really ridiculous, that normal users have come to expect (or should expect) that there are exploit-ridden websites which you should never visit, or else your system may get exploited and spyware/other crap gets installed behind the user's back.
One could pass a web-server ANYTHING as a URI, and the server basically returns you a 'page', consisting of a number of elements which are then rendered for your viewing pleasure. From a conceptual point of view, that's pretty much a READ action, and
Re:The Point: They're Still Missing It. (Score:4, Insightful)
Personally I'd point the finger at the idea of using ShellExecute on inadequately filtered data from the Internet.
Parent
Damn you, Microsoft. (Score:2, Insightful)
Re: (Score:2)
The "New" Microsoft (Score:3, Funny)
Simple (Score:4, Interesting)
Re: (Score:2)
That would work if you didn't have to make an exception for the Outlook Web Access Client for exchange. That has all sorts of invalid URL's in it that should never be accepted by a web browser.
Worst thing Netscape and Microsoft ever did is allow their browsers to render
Re: (Score:2)
I cannot remember what the issue is exactly but it has (had? I have been mercifully spared from exchange 2005) to do with % signs in email subjects or file names.
My Flaw (Score:2)
My flaw is much more personal
Pay attention (Score:5, Informative)
Re:Pay attention (Score:5, Interesting)
Though I can't think of a reason why Microsoft would WANT to fix a problem in Firefox, unless IE's market share has dropped below 1% ;-)
Parent
Re: (Score:3, Insightful)
So uhmm what was the point of this post at all? Anyone in Microsoft's position wouldn't want to fix their competitors' software, it being OSS or not.
Firefox isn't just a browser competing to IE on Windows. It's a browser on Windows that works the same on Mac and Linux. That's horrible for MS as the browser becomes th
Nothing new here (Score:2, Interesting)
Re: (Score:2)
Welcome to reality. If you made a mail daemon that worked according to spec nobody would be able to use it.
If you saw the errors in SSL browsers ignoered just to they look like they're working you'd shit.
Did the submitter read the links they included? (Score:4, Informative)
1) an exploit in firefox URI protocol handler
2) an exploit related to how explorer handles rejected URIs from IE7 on XP/Win2k3
Apparently the submitter isn't able to differentiate #2 from #1.
The advisory is for item #2. Item #2 is going to get fixed. The advisory does not cover item #1. Item #1 will need to be fixed in the protocol handler itself.
Re: (Score:3, Informative)
Whole thing reminds me of PHP XSS attacks... (Score:2)
This is the exact same situation. There are problems with un-escaped data and Microsoft doesn't want to bother much like the PHP team did before they changed their minds about the situation.
The only difference here is the way the code executes. I personally think it's not Microsoft's fault but they should fix it anyway.
Re: (Score:2)
Re: (Score:2)