Slashdot Mirror
Several Critical MSIE Flaws Uncovered
An anonymous reader writes "Several flaws have been uncovered by security firm eEye in Microsoft's Internet Explorer. The flaws allow remote compromise of computers running Windows Operating Systems and affect IE, Outlook and possibly other MS software. With the next MS Windows security bulletin release scheduled for June 14, 2005 news sources are reporting that in comparison with the Mozilla Foundation's prompt fix for the recently reported Mozilla 1.0.3 vulnerabilities MS appear to be leaving a large window for the possible malicious exploitation of these flaws."
I know some people around the Mozilla camp were a bit afraid of how the media would cover their recent security problems. But, once again, Microsoft's really come through by offering problems of their own to take the spotlight off Firefox.
Is this story a dupe?
I could swear I read about security problems in MSIE before...
People taking advantage of Microsoft's upgrade release cycle to discover security flaws when there's a month to go to the next upgrade!
I hereby demand that everyone only look for security flaws the week before the scheduled security update so that Microsoft can continue to claim it patches all their flaws in a timely manner!
There's no rush cause we've got something to sell!
m spx
http://www.microsoft.com/windows/onecare/default.
lisa bonet ate no basil
IE lite? You mean less features than IE already has? I think that's called telnet isn't it?
who came up with the clever design idea of making eEye's slogan "Vulnerabilty Is Over" and then pasting it at the bottom of each vulnerability report as if it's a status message?
/. stuff.
reminds me of the Simpsons scene where someone is reporting a crime via a radio and says "over" at the end of the transmission. then Wiggum says "thank god that's over". karma for the first person to find the quote, but I only have the real kind not the
I have often also wondered about all those flaws that have been discovered and not declared, just quitely made use of. At least with open source the oppurtunity for discovery as well as a rapid fix has become obvious.
Chaos - everything, everywhere, everywhen
Go easy on him, he must be new around here.
If you don't know what AltaVista is (was), get off my lawn.
By your logic, a program written by a first year student who didn't pay any attention to any security would have as many flaws discovered as a program written by an expert who tested for vulnerabilities
As long as both of them had the same number of users.
In other words, the flaws aren't errors in code writing, the flaws magically spaw when a certain number of people use it.
It has been working OK, except for some thrid-party software. One example, Kodak's EasyShare. Everytime a user logs into their account, EasyShare puts up a modal dialog box stating that some features may not be available unless the user account is raised to admin privilege.
This causes two problems: I get questions about the presence of the dialog box, and I get questions about the missing features.
While it is often correct to blame Microsoft, Kodak is the problem in this instance, not Microsoft.
Yes, all the Linux, UNIX, OS/2, Solaris, etc. etc. users are going to dump Firefox and switch their systems to Windows so they can use IE7 and then Firefox will die.
Let's pretend for a moment that this would actually work. It's not possible to get people to implement it.
It's hard enough to get any of the browser teams to commit to implementing a complete sandbox, even though that could be done without inconveniencing the users.
It's hard enough to get users to adjust the sandbox that they're already using so that it's as complete as possible, even though doing so imposes very little invenvenience.
Getting users to go through a lot of inconvenience to create a new account to run their browser in, that's really tough.
But even if you could do it, it wouldn't be effective.
A restricted account could still be used to compromise their privacy, it could still be used to destroy data they consider important... their bookmarks, information maintained on websites they connect to, and so on.
And that's assuming it would remain restricted: once I can run native code on your machine, getting out of a restricted environment is just a matter of time. It's easiest on Windows, of course, but even your typical UNIX or Mac OS X box has all kinds of mechanisms that a restricted account can use to extract information from your "real" account, or launch code (directly or through a boobytrap) into the "real" environment.
The only "restricted environments" I have used that I would consider secure enough to not treat malware running in that account as an immediate threat, apart from physically separate boxes, are FreeBSD Jails or completely emulated systems (VMware, Virtual PC, etc).
But we do know one thing that does work very well. And that's having a sandbox that has no holes in its design. That means there's no holes that the developer's reluctant to close, and no holes that users are reluctant to see closed. That means that any holes that do occur are bugs, and as such can be quickly fixed without embarassment and without discouraging users from applying them.
It's not perfect, but it works much better than a whole sandboxed account, and it's much easier to implement and MUCH more convenient.
So: the first absolute requirement for building a secure web is for the browser manufacturers to commit to a completely closed sandbox. That means there is no mechanism inside the sandbox to get outside the sandbox even as far as to see information stored about other websites. That means: no XPI installers, no ActiveX or Active Scripting, no "open safe files after download", no use of "Desktop" applications to open documents (even if you think the document is local), nothing. Any application you hand off a document to has to be one that has an equal commitment to maintaining that sandbox. If the user wants to do anything like that, they have to explicitly download the document and so move it outside the sandbox, and THEN explicitly open it in the unsandboxed environment. Those two steps must never be shortchanged.
What does that mean to the user, then?
Not much, in most cases. For Firefox users that means they'll have to download XPI files and then load them from the menu or their desktop file manager. For Safari users, no more "open safe files", and no more warnings the first time they open an app because the browser won't ever be opening apps behind their back. For Windows, there would be a bigger impact: a few tools like Software Update would be separate applications, but the bigger impact is that some third-party applications would need to be redesigned to use the new safe API.
Windows, I can see their reluctance. The rest? I don't get it... they're not gaining all that much by having a leaky sandbox, and the fact that even such small leaks can be exploited is sure a good argument for having at the very least no designed-in holes at all.