Re: Dropping permissions and sandboxing a browserplugin.
Jon Watte <[email protected]>
| Newsgroups | gmane.games.devel.sweng |
|---|---|
| Message-ID | <[email protected]> |
> > What I don't understand is how plugins such as Unity or Flash protect their > userbase from exploits They do it by implementing a constrained API, that doesn't let outside code do anything "dangerous." It's up to each plugin to decide what "dangerous" means, and how to enforce that nothing "dangerous" is done through whatever external surface the plug-in provides to other configuration and script methods. For example, if a plug-in had a scriptable function "create_file_with_contents(path, data)" then it would be up to that plug-in to decide what kinds of arguments would be "safe," and how that would be implemented inside the plug-in. There is no protection from the point of view of the browser. Even the "sandboxed" Chrome and IE versions don't really sandbox the system itself from possible side effects of executing native code in a particular plug-in. If there is a code-exploitable buffer overflow or similar in a plug-in, then the machine will be available with the permissions of whatever user is executing the web page with the plug-in. What IE and Chrome have so far done is sandbox other web pages from a poorly behaved web page -- if one window locks up, the other windows should keep responding; if one window crashes, the other windows should stay on the screen; etc. Unix-style "chroot" and "setuid(nobody)" sandboxing isn't as available in the Windows browser native code plug-in world. From what I understand, there's tons of places in the Win32 API where you can pass a function pointer around, and the window wouldn't render correctly (or respond to keys, or whatever) if you didn't have local user permissions at that point. This is why managed sandboxes like Javascript, .NET, Java, Applets and Flash are intended to be safer -- the managed API, if implemented properly, has no way to "leak out" into the unmanaged API, and thus the plugin implementer has tighter control. As long as you trust the plug-in implementer. Sincerely, jw -- Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. On Fri, Mar 19, 2010 at 4:38 PM, Mark Watson <[email protected]> wrote: > The sandboxing is new to IE8 and Chrome, so yes other browsers > are vulnerable to this kind of problem. > > Guess if the user runs the browser as Admin, you can create a new user with > limited permissions, spawn a new process and use that as your sandbox to > load the bulk of your plugin :) maybe a case of the cure being worse than > the disease... > > On 19 March 2010 16:14, Juan Linietsky <[email protected]> wrote: > >> Yeah.. that's what I mean, so the question is what happens when a >> browser won't provide this security model? >> >> So, basically let's say, if a plugin such as Unity has a vulnerability >> in itself or in one of the many libraries it uses (such as mono, >> freetype, image loaders, etc), and the browser is firefox or IE (which >> as far as I know don't provide any sandboxing for plugins) the user is >> completely unsafe when visiting any page that uses the plugin? is it >> really like this? >> >> I mean, i find it difficult to believe that they would be place their >> userbase at risk, so i'm asking how do plugins protect from this >> dangerous scenario.. >> >> >> >> >> >> On Fri, Mar 19, 2010 at 7:12 PM, Mark Watson <[email protected]> wrote: >> > You mean like trying to avoid buffer overflows from network traffic in >> their >> > plugins? It's kind of up to the browser to provide sand boxing, since >> it >> > controls how your plugin is started and its permissions. >> > >> > On 19 March 2010 13:54, Juan Linietsky <[email protected]> wrote: >> >> >> >> So, basically.. What I don't understand is how plugins such as Unity or >> >> Flash protect their userbase from exploits.. I mean, I'm sure they do >> >> somehow (as I can imagine they want as little hacked users suing them >> as >> >> possible) so I was wondering what is the "right" way to do that.. >> >> -----Original Message----- >> >> From: Jon Watte <[email protected]> >> >> Date: Fri, 19 Mar 2010 14:11:20 >> >> To: <[email protected]> >> >> Subject: Re: [Sweng-Gamedev] Dropping permissions and sandboxing a >> browser >> >> plugin. >> >> >> >> _______________________________________________ >> >> Sweng-Gamedev mailing list >> >> [email protected] >> >> >> >> >> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com >> >> >> >> >> >> _______________________________________________ >> >> Sweng-Gamedev mailing list >> >> [email protected] >> >> >> >> >> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com >> > >> > >> > > > _______________________________________________ > Sweng-Gamedev mailing list > [email protected] > http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com > > _______________________________________________ Sweng-Gamedev mailing list [email protected] http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com