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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.