Slashdot Mirror
MSN, Word Vulnerable To Shell: URI Exploit
LnxAddct writes "InfoWorld is reporting that a few Microsoft products are also vulnerable to the "shell:" scheme vulnerability found in Mozilla last week. These applications include Microsoft Word and MSN Messenger."
Anyone know if Word 2004 for OSX is safe from the URI exploit? I know that the macs have been having trouble with the URI exploit over the past few months based on some articles I've read at macslash.
Aj
GroupShares Inc. - A Free and Interactive Stock Market Community
-------
artlu.net
According to the article "Malicious hackers could launch programs associated with specific extensions using links embedded in Word documents or instant messages sent using MSN. However, the vulnerability does not allow attackers to pass instructions to the programs..." Now call me crazy, and I know i'll probably piss off the microsoft hating people here, but what harm is there really? What's some "hacker" gonna do, open up Acdsee and show my porn collection to well...me? Maybe pop open a few dozen IE windows or programs to force me to reboot? If there's nothing else being transferred it's really just more of a nuisance than something major. Or am I just reading this wrong?
(Score: -1, Troll)
I find it interesting how they talk about "no exposure to malicious attackers", as if their products are magically invulnerable until someone discloses the hole to the public.
(that subject is a great way to get modded down)
I created a shell link inside Office Word 2003 and when I clicked it I was warned that the hyperlink contained a potentially dangerous target and that I should only proceed if I trusted the source of the document. This warning does not appear for http, https, ftp, or other common "safe" protocols.
I do not have MSN available for testing.
http://brandonbloom.name
It seems logical that the solution to many of these browser exploits is to run the browser with a separate set of OS permissions, i.e. as a separate user. This could be done using setuid under Unix. I don't know how it's accomplished on Windows.
The special user would have greatly reduced permissions, which would prevent these exploits from being useful. This user could not execute anything but designated plugins, and could not save files except to a designated area.
Why has this not been tried?
Maybe someone should check to see if IE has this "bug" as well. ....
Thats very probable since this is more a "metabug" in Windows - that might get fixed in SP2.
So, perhaps Mozilla should have "bug fixes" for every windows flaw that they uncover?
No. They should just disable unsecure stuff by default. Thats one of the strong points of Mozilla. They did write code at some point that passes some unfiltered, unchecked data from the web on to some external handler. That action is shouting "security hazard" all the way
Wouldn't that introduce quite a bit of bloat?
If you are fighting bloat, Moz shouldnt include this "feature" at all. But if someone writes code for this (rarely useful, but dangerous) feature, you better disable it by default.
The origional bug relating to handing off unhandled URI's to the OS goes back that far. It kept getting marked as "will not fix" because it was a stupid architectural decision that some of the guys at Netscape made.
It was hardly a stupid decision. Passing unhandled URIs to the OS is a perfectly acceptable thing to do. Unless you think that handling things like ed2k: URIs and other yet-to-be-invented URIs is a bad thing.
Perhaps the URI handler built into the OS needs a local versus foreign flag..
How about this one...
http://secunia.com/advisories/12043/
It starts out as a "Sun Java Predictable File Location Weakness"
Then, further down in the advisory....
A PoC (Proof of Concept) exploit has been published, which:
1) Uses the weakness in Sun Java to create a temporary file.
2) Exploits a file enumeration vulnerability to find the name of the temporary file (100,000 possible combinations).
SA10820
3) Exploits a Cross-Zone vulnerability and uses the inherently insecure Windows "shell:" functionality:
SA11793
Solution:
Use another browser than Microsoft Internet Explorer.
Alternatively disable Active Scripting in Internet Explorer.
If you do not use Internet Explorer, this issue is not considered a security problem.
I suspect a great many apps have (until recently) just blithely passed commands that have user input into ShellExecute(). Obviously, you can't do that, a fairly clever user can figure out how to get someone else to run a command on their system without their explicit consent. Note that MSDN doesn't mention anything about the possible security implications of it, which is why MS is being blindsided by it. Now, a ton of apps use ShellExecute(), it is the recommended way to launch the correct web browser on a user's system. What I did in my app was before calling ShellExecute(), extract the protocol and compare it against a whitelist of allowed protocols. In my case, I only allowed http, https, mailto, and ftp. If it wasn't one of those four, I just didn't do anything.