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

[Jiri Vanek]

On 01/17/2013 03:53 PM, Adam Domurad wrote:
> 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.

Thanx for repost, and sorry for conversation fork, but above message come from my phone :)
>
> Yes - I came to similar conclusions; I'm working on a pop-up similar to Oracle's currently.

Yy, this pop up is definitely first step. (but imho it should be already accomapanied by always/never/ buttons and radio swithch  applet/page/domain
>
> Can't applets be smaller than a comfortable button size (and potentially hidden somewhere) ?

exactly - one of the reasons of this mechanism, that invisible appelt is not  launched without warning. Imho 0x0 size appelts  should be even more restricted (but 1x1 appelt is still in same way dangerous .. :-/ (so probably no op)
Maybe we can write size to the information dialogue;) 0x0 px should be saspicious to everybody (we can add explaining message also)

> 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.

Agree, What about three thresholds then? eg >100px - full info in applet's pane, 100-20 details button, lesser direct popup.
>
> 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.

Interesting idea :)

>
> 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".)

Also interesting - if first appelt will be ok for page/domain  then others really could be launched autoamticaly.
But what if there will be first, some nice animation/game, and lower will be some malicious invisible one?

Also I'm not sure if t will be possible to implement it correctly.


J.