Microsoft Blames Add-Ons For Browser Woes 307
darthcamaro writes "Running IE and been hacked? Don't blame Microsoft — at least that's what their security types are now arguing. 'One of the things we've seen in the last two years is that attackers aren't even going after the browser itself anymore,' Eric Lawrence, Security Program Manager on Microsoft's Internet Explorer team, said. 'The browser is becoming a harder target and there are many more browsers. So attackers are targeting add-ons.'
This kinda makes sense since whether you're running IE, Firefox, Safari or Chrome you could still be at risk if there is a vulnerability in Flash, PDF, QuickTime or another popular add-on. Or does it?"
Re:Permissions (Score:5, Interesting)
Re:Bullshit. Plain utter bullshit. (Score:3, Interesting)
Can anyone point to an add-on that has more users than ANY brand of browser?
Sun Java? Adobe Flash? Not sure about the former does, but the latter has a much bigger installed-base than IE.
Re:Permissions (Score:5, Interesting)
IE7 is set to run in sandbox mode by default. If a user decides to take it out of that by force or installing addons, then I would gather they would be to blame directly or indirectly for the end result. Im not MS fanboy, but can they really be blamed for shoddy coding done by third parties?
Re:Permissions (Score:5, Interesting)
What is needed is better warning messages (Score:1, Interesting)
I see people trying to install the free "Spyware Removal" and "Registry Scanner" all the time on our Citrix servers. They fail, of course, but it doesn't stop them from trying. And what warning does the OS give you when a site is trying to install something?
A yellow bar that suggest you click here to proceed. It might mention that some content may be harmful.
It should say something like: "This web site is trying to crap on your computer. If you enjoy getting crapped on and ripped off in your personal life, click here to proceed." If they do click, then it should say: "People like you are why syphilis is still a common disease".
Largely yes and largely ignorance (mitigation) (Score:5, Interesting)
Exploits for specific document types make compromising people's machines an issue. However, what 99.9% of people that revel in schadenfreude with IE's woes miss or fail to understand (yeah including many people on Slashdot) is that most Windows XP users (which are most Windows users, Vista is only 20%) run as as "root"!!! ("administrator" in the Windows vernacular)
I wrote a utility called RemoveAdmin available on Download.com that leverages an API in Windows (CreateRestrictedToken) that strips administrative rights:
http://www.download.com/RemoveAdmin/3000-2381_4-10824971.html?tag=mncol&cdlPid=10835515
The installer will create shortcuts for IE and Fifrefox but if you look carefully it's really a program with the browser .EXE passed as an argument.
Which means you can strip administrative rights on anything you run... in fact that's exactly what I do. I don't run *anything* that talks on the Net without this.
This means if you stumble across rigged .PDFs, Word documents, etc., etc., you won't suddenly have a keyboard logger installed because ignorant you is running with admin rights.
(Some caveats)
This is version 0.1. What would 1.0 have? A FAQ and user guide for starters. Also, I've seen this version not work in some cases, largely situations where AD is in play (probably because a user has multiple admin credentials).
If you need to run ActiveX controls on a site (poor you if you use IE), just quit IE, go to the site, have the controls installed. Quit IE and re-run IE with the secure link. Likewise this is what you would do before going to WindowsUpate.
And finally, to convince yourself the utility does something useful. Go to any site, "View Source" after you run your browser with the secure link and try to save the resultant .HTML/JavaScript to C:\Windows. You'll find you can't.... since your browser process doesn't have administrative rights (root) and thus any process it launches doesn't either (think of this as a plug-in scenario).
Maybe I'll educate some % of the IT world yet...
Respectfully,
-M
Re:Bullshit. Plain utter bullshit. (Score:3, Interesting)
Many non-power-users don't use addons at all.
If what was being said were true, only us techies would be affected. ...and if that were true no one would care (including us techies) because we know how to protect ourselves.
Many power-users install only a minimal number of addons to do what we want. Stuff like flash-block along with flash. We don't need a dozen fool-bars or huge numbers of widgets.
Re:I'll still blame you for everything else. (Score:2, Interesting)
Re:Permissions (Score:5, Interesting)
IE7 is set to run in sandbox mode by default. If a user decides to take it out of that by force or installing addons, then I would gather they would be to blame directly or indirectly for the end result. Im not MS fanboy, but can they really be blamed for shoddy coding done by third parties?
Should it even be possible for add-ons to do this? Should we really expect the average user to understand that allowing the add-ons to turn off sandbox mode isn't a good idea? At the very least, if an add-on wishes to turn off sandbox mode, a stern but CLEAR warning should be given to the user, and they should have to supply an administrator password. Of course, since vista bugs users for permission so much, most users would just click through the warning thoughtlessly.
I bought my mother a Mac. When she used to use a PC, she would always get caught by trojans. Now I just tell her to never enter her admin password unless performing updates. Problem solved. Because OS X rarely asks for an admin password, when it does, users know that the program wants to do something serious.
Re:Plugin model (Score:2, Interesting)
Yes, they are responsible for the plug-in architecture. However, the architecture only provides the mechanism through which the plug-ins are loaded and communicate with the browser, they don't provide any further facility. The plug-ins are simply binaries which are loaded into the process space of the browser. The browser process dictates the security context under which the plug-in will execute. In all browsers on all platforms if the plug-in has a vulnerability exploiting that vulnerability gains the attacker the same privileges as exploiting the browser itself, which is generally the privileges of the current user.
The best route is to run the entire browser within a constrained security context. Internet Explorer 7.0 running on Vista with Protected Mode enabled, which is the default, runs under such a constrained context. It may be possible to exploit the browser or a plug-in but that exploit will be severely limited. For example, not long after Vista was released a vulnerability was identified in the library responsible for loading animated cursor files. The vulnerability could be successfully exploited on Windows XP and Windows Vista, but if protected mode was enabled the exploit was unable to deliver it's payload on Vista.
What Chrome attempts to do is to load the plug-ins into child processes of the browser. This is done for reliability purposes, not security. Unlike the renderer child processes, the plug-in child processes are not constrained using the Windows job API. A vulnerable plug-in would be just as exploitable. The reason Google did not lock down the plug-in child process is because the plug-ins do not expect to be hosted outside of the browser process. This by itself has caused a lot of problems and the Chrome code has hard-coded a number of behaviors specific to certain plug-ins simply to ensure that they work. Flash, for example, is still rendered within a window handle owned by the browser process. Chrome has taken a novel approach, but it is not sustainable.
In my opinion there needs to be a collaborative effort in order to design a new plug-in architecture and framework under which it is assumed that the plug-in will be loaded outside of the browser process as well as executed within an extremely tight sandbox. All interaction between the plug-in will be carried out by a specific API and any action the plug-in attempts to make outside of the sandbox must be negotiated through a broker API. This would effectively combine the approaches taken by Google and Microsoft. However, I don't think that either company has the ability to pull off such a change alone, which is why I call for a collaborative effort which would include at least Microsoft, Apple, Google and the Mozilla Foundation, perhaps under the supervision of a standards body such as ECMA.
Re:Permissions (Score:3, Interesting)
What everyday task does Vista bug you about authorizing?
I've heard this a number of times how it nags people and that the initial release was rough but since SP1 I only see allow or deny when its something I'm doing intentionally that administrative related like installing an update to a program.
I'm genuinely interested in this since I manage a lot of Windows machines and sooner or later I'll have to deal with common complaints or face turning UAC off.
Re:Permissions (Score:4, Interesting)
Are you sure?
Are you really sure?
Positive?
Ok
Re:Permissions (Score:5, Interesting)
can they really be blamed for shoddy coding done by third parties?
Yes they can and here is why:
If a program is going to allow addons then the communications between the addons and the main application should be conducted entirely through interfaces [microsoft.com] in order to preserve abstraction and enforce Design by Contract [wikipedia.org] principles. In this way addons are allowed to plug into the application at precise locations controlled by the main application and to interact with the main application abstractly and in precisely defined and limited ways. Some people might argue that this is too limiting, but it has been my experience in developing software in this style that well designed interface contracts can support a wealth of valuable features while maintaining plug-ability and abstraction throughout the software stack. So I don't buy "It's the addons fault" since the addons, ultimately, can only do things which the main application framework has allowed them to do whether intentionally, through good abstraction, or unintentionally from poor addon framework design.
Listen to his comments for the full story (Score:3, Interesting)
Quick note: This article is a spin off of what Eric had to say during the most recent Black Hat Webcast, where Jeremiah Grossman was talking about clickjacking and other related browser issues. Eric made a lot of sense talking about plug ins and addons being the cross platform low hanging fruit.
Listen and watch the webinar to hear what he had to say and keep everything in context:
http://w.on24.com/r.htm?e=122494&s=1&k=05ED21C1734D531D2D84CA56F4ADB0F2 [on24.com]
Or download the .m4b audio file when we get it online next week here:
https://www.blackhat.com/html/webinars/webinars-index.html [blackhat.com]