Bug#267040: gcjwebplugin runs untrusted code without sandbox

[Ben Hutchings]

On Tue, Sep 09, 2008 at 03:12:54PM +0200, Robert Millan wrote:
> 
> [ whoops, resending again...]
> 
> On Mon, Sep 08, 2008 at 11:51:55PM +0100, Ben Hutchings wrote:
> > > 
> > > How is this different from the multitude of interfaces in the system in
> > > which data is assumed to be trusted?
> > 
> > Data from the network is generally treated as untrusted;
> 
> The user is in charge.  Data from the network becomes trusted when the user
> decides so.  This applies to a lot of different situations, I assume it's not
> necessary for me to give examples?

When a user navigates to a web page, they want to see that page.  Any
prompts on the way tend to be interpreted as "do you want to see this
web page or not?", to which the answer is "yes of course".  If the
question is really "do you want to trust this web site with full control
over your account?" then it's leading the user into a trap.  This is why
the major browsers now use an information bar to notify the user that
some potentially insecure feature is not active and can be manually
activated, rather than forcing the user to make a decision before the
page will appear.

If the plugin was changed to use the information bar and provide a
whitelisting mechanism for trusted sites, I think that would satisfy
the requirement for an explicit choice by the user.  But it still
wouldn't be nearly as good as a proper sandbox.

> > They can use the Sun Java plugin.
> 
> I can't believe you're actually arguing that the solution against blindly
> trusting a website is blindly trusting a binary blob.

I would rather use a secure free plugin than a secure non-free plugin,
but apparently that doesn't exist.  Since the choice is between a secure
non-free plugin and an insecure free plugin, them I'm afraid I'd go for
the former because I trust Sun much more than I trust many of the web
sites I visit.  I'd be very surprised if you can honestly say the
opposite.

> Here's my advice: If you don't like gcjwebplugin, don't use it.  If you like
> binary blobs, go use them.  If you don't care about Java, don't use either.

As it happens, I have no need for Java applets; Flash seems to have
taken their place.  (And yes I know there's a similar problem there,
though AFAIK the free implementations are sufficiently sandboxed.)

> Just don't impose your view on everyone else by requesting arbitrary removal
> of a package.
 
It's not arbitrary.  As it stands, this package is a security hole
just waiting to be exploited if it gets released.

Ben.

-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had thought.
... I realized that a large part of my life from then on was going to be spent
in finding mistakes in my own programs. - Maurice Wilkes, 1949
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20080909/ae0cbae7/attachment.pgp