[icedtea-web] Idea - do not start ITW applets automatically

[Adam Domurad]

On 01/16/2013 02:09 PM, Jiri Vanek wrote:
> On 01/16/2013 07:59 PM, Adam Domurad wrote:
>> On 11/15/2012 03:30 PM, Adam Domurad wrote:
>>> So in lieu of requests such as [1] and the potential for unsigned 
>>> code escaping the sandbox (eg,
>>> the recent 0day) it could be worth looking into a feature that has 
>>> applets not start
>>> automatically, but rather require a user confirmation (click?) to 
>>> begin. Additionally a more
>>> strict setting could not allow This could be controlled via 
>>> itweb-settings/environment and
>>> distributions might want it as the default.
>>>
>>> There should be some way to opt-in normal execution of signed 
>>> applets based on certificate. When
>>> an applet's certificates are all opted in, it will start 
>>> automatically. (Note that we do not need
>>> to handle mixed signed + unsigned code specially, it already 
>>> requires a confirmation.) Unsigned
>>> applets, if we choose to allow them being opted in, can be opted in 
>>> on a full domain name basis.
>>>
>>> The main motivation I have for proposing this feature is that many 
>>> applet users only use a handful
>>> of applets, and having other applets automatically start is mostly 
>>> an unnecessary attack surface.
>>> I have seen "Disable java in browser, and turn it on for any applets 
>>> you need to use only" giving
>>> as advice following the 0day, and this would be a superior option.
>>>
>>> [1] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1211
>>>
>>> Thoughts?
>>> -Adam
>>
>> So hey, yet another 0day since this, good times.
>>
>> So something like this now has become default in Oracle's plugin. 
>> Starting with the most recent
>> Oracle Java release (the recent 0day fix) applets in the browser run 
>> in 'high security' setting by
>> default. This setting requires explicitly allowing unsigned content 
>> to run.
>>
>> Oracle implements this via a pop-up window: A 'Do not show this again 
>> for this app' checkbox allows
>> the option of running/not running to be remembered.
>> Example of the new default behaviour for unsigned applets: 
>> http://i.imgur.com/RZWIG.png
>
> Blah. I would rather stay without popups! I think spalshscreen (as 
> something "before laod") have prepared way for this. However for 
> branches there should be different approach :(
>>
>>
>> The pressure is on us to do the same for icedtea-web for applets 
>> (JNLP launched programs will not be
>> affected).
>>
>> Jiri mentioned the implementation should probably be done in at least 
>> two parts, here is how it
>> could be done:
>>
>> 1.) In icedtea-web settings panel, have a High/Medium switch for 
>> security, defaulted to High.
>> Require user confirmation for all unsigned applets on Medium.
>>
>> [The name Medium here corresponds to the related Oracle security 
>> level. We do not really need to
>> implement Very High (no unsigned applets running) nor Low (all 
>> applets run automatically).]
> in part two I would defintely like to see definitely Low and maybe 
> also ExtraHigh.
>
>>
>> 2.) Implement whitelist/blacklist similar to how Oracle does this -- 
>> ie, always/never option while
>> confirming unsigned applet running, and a way to manage this in 
>> icedtea-web.
> Yes, whitelista and balicklist are a must.  So buttons like yes, no, 
> always, never are also necessary. And dont forget regexes for manual 
> editation ;)

I kind of like how Oracle handled this, with a checkbox 'remember this 
option'. So yes + check = always, no + check = never.

>
>>
>>
>> Open questions:
>>   - Click-to-play, vs pop-up ? (Funny result of click to play is, 
>> when used with browser click to
> +1 for Click-to-play in head
> For branchesd.. hmm probably dialogue will serve better :(
>
>> play, unsigned applets need double-click. Not worse than 
>> click+pop-up, though)
>>   - How to implement always/never options?
>
> BUttons ?o) and then to "itweb-settings managbale/sahred  file(?)"
>>
>
> J.

Off-list follow-up appended:

>
> few more ideas to delayed launch. I´m afraid we cannot live without 
> the popup dialogue. Sometimes the applet is *just too small*. I think 
> in first iteration, for all branches, we should have one big button 
> "details" with tooltip "this is applet, click for details". After 
> click dialogue apper, with as much detail as we can provide and 
> buttons run/dont/always/never/thisOne/domain/... in next iteration we 
> should move all the body of this dialogue (keep it in mind during 
> first desing :O) to the applet itself but only if both its sides are 
> eg greater then 100px {otherwise nasty button will remains}). For 
> head, errorsplash is ready to handle "post no run" appearence pretty 
> well :O) just my 0,02$ for brain storming.
>
> J.

Yes - I came to similar conclusions; I'm working on a pop-up similar to 
Oracle's currently.

Can't applets be smaller than a comfortable button size (and potentially 
hidden somewhere) ?
If we do go the route of having a details button in the applet, I think 
we'll have to still implement a size threshold. For small applets I 
think we shouldn't risk cramming in detail.

I think for applets big enough having the confirmation details on the 
applet itself would be great -- in fact this would be an improvement 
even for accepting applet signatures in my opinion (although we may risk 
dropping important details). But, small applets (<100px) should always 
have a pop-up I think.

Since a page can have many small applets, I think we should add a site 
to a 'temporary whitelist' once you accept an applet can run, and all 
applets on the page run. They will continue to run if you enter the site 
in the same session (a malicious applet will immediately do something 
nasty the first time -- no significant further risk I'd think of running 
it twice). Same way if you reject an applet, it will reject all applets 
on this page in the current session (possibly with message on applet 
"Applet denied for current session".)

-Adam