Java runs with different integrity level in Internet Explo. vs. low integrity Firefox

You know what, sorry my mistake. It looks like the recommendation is to disable the Java plugin and not Javascript, the latter of which is what I thought was meant. I reacted too quickly. Sorry about that

 

I don't really like websites that require Java, but sometimes it is required if you want to use what they offer.

More often though I only need Java for other things, like my NAS box can utilize it for one specific feature, and it is a good feature. I also have a server that allows remote console, and it uses Java to view the console (this is a dedicated remote port, where you can change bios, power up/down, etc with, not like remote desktop).

I used to install Java in one of my sandboxed browsers, so when I needed to go to a web page that needed Java it would be in a contained environment.

Sul.

 

Well that makes more sense

 

I work in IT and while I'm not a fan of Java, I'm glad the above quote was mentioned. Most people I run into NEVER update their Java Runtime. As we can see, this leads to serious problems in the Internet. I see it on a daily basis.

 

Well, you did have a good point, though. If a user needs Java (The IRS on-line service also requires it, here) and doesn't have it or is disabled, it will cripple experience. It all depends when the experience will be crippled. Just because xyz person accesses one website requiring it and it's disabled/doesn't have it, it won't make it not be a crippled browsing experience. Just my view of things, of course.

 

SRP/AppLocker don't block Java, as far as I know. SRP/AppLocker, however, can block any executables that Java malware tries to run.

 

Yes, that's right, the executable.

 

From “Perfect” Client-Side Vulnerabilities:

 

It's all about preventing the exploit from happening, in the first place. If the exploit can't start, then it can't execute anything, even if Protected Mode/Chrome's sandbox are useless.

As you previously have shown EMET is no guarantee it will be able to mitigate all exploits, hence the need to prevent the exploit to the maximum.

The way I see it:

1. Prevent the exploit;
2. Mitigate the exploit;
3. Contain the exploit.

If these three fail, better eat some hot-dog. Hot-dogs are tastier.

Exercise to the mind: What prevention/mitigation/containment solutions do you know? (This is intended to the general audience as well. I'm leaving aside disabling plugins, and all that stuff, because there's a larger scenario out there, who need to have Java on their systems. Let's also leave SRP/AppLocker aside, as many don't have them, nor do they know how to set it up.)

 

Prevention - NoScript (for Firefox users)
Mitigation/containment - run Java processes launched from browser as low integrity so that a limited number of locations can be modified; use standard account; use sandboxing or virtualization technology; encrypt sensitive data

Unfortunately, EMET cannot protect against the type of Java exploits discussed in the article that I referenced in my last post.

 

NoScript is a great measure, but unfortunately it does put some burden on the user. He/She must know exactly what not to allow. Not to mention, only works with Firefox.

What are IE, Chrome and Opera users left with? Messing with IE ILs, I'm not so confident about it, as it would need a proper testing to see what would stop functioning. It's also a whole different matter in regards how it interacts with the O.S itself, unlike other web browsers.

Standard accounts do provide the extra containment, for those aware of such accounts.

Sandboxie (I know you didn't necessarily mention it.) could be a solution, but it would require the user to know what processes are and which ones to add.

This could leave us with something more automatic, instead.

By the way, if you want more links to test, I'll provide you. Most of them do exploit Java.

 

Opera and Firefox - run as low integrity if possible
Chrome - use the safe-plugins switch mentioned earlier in thread
IE - no idea

Also, I should have mentioned anti-executable software. Faronics Anti-Executable v3.6 blocks writing of .jar files. AppLocker/SRP can block executable files but not Java code.

 

From QuickJava Firefox extension:

QuickJava for Google Chrome?

 

ActiveX filtering - thought saying that is somewhat useless as it's unique to IE9. It's probably a little friendlier than NoScript though, in regards that if the user suddenly hits a websites trying to exploit the vulnerability I highly doubt the first thing he/she will think of doing is allowing the site. Where as NS would probably make the site look crippled, and trigger the user to allow.

 

There is a setting in NoScript options under Embeddings "Apply these restrictions to whitelisted sites too" which blocks plug-ins even if a site is allowed.

Btw, Chrome has built-in support for plug-in blocking.

 

Unfortunately that's true.

Both Chrome and Opera has some built-in capabilities to handle plug-ins on per-site basis (but the working differs from NoScript which works on per-domain basis)

There are also NoScript-like forks for those 2 browsers. Again, the question of usability (for most folks) may arise.

IE9 has ActiveX filtering...but I'm not fully sure how it holds up to Java exploits.

Could but atm, I see nothing. The best thing is to remove Java if you can afford it - just like what elapsed recommended. Otherwise, disable the plug-in within the browser until you need to use it on specific sites that needs it.

The older IE versions has Internet Options>Security settings though

 

What you say all valid, but I'm not concerned about me... I don't even use it. I'm merely trying that others have a debate on what possible protections they could deploy, without having to disable Java, because they need it.

OK. So, what I say still stands: Prevention and mitigation/containment, without putting the burden of decision to the user.

Leaving aside the likes of NoScript, what is out there? Let's also consider all major web browsers.

OK. Chrome and Opera do offer the option to allow plugins on a per-site/per-domain basis. I don't know about Opera, but with Chromium/Chrome you allow the domain and not sub-domain. Then again, if the user allows is, believing the web site does need Java, what could there be to protect users?

I already mentioned Sandboxie, but it won't do it on its own. The user has to know what a process is and what processes should be sandboxed.

We have a mitigation tool, EMET, but as demonstrated by MrBrian, it won't be bulletproof against all exploits. *

Do you know any prevention tool/preventive measure of easy use, that any user could install and forget and wouldn't put the burden on his/her shoulders, and that would do its best to protect them against exploits, coming via web browser (which could also lead to Java exploits)?

-edit-

* Not to mention, that alike Sandboxie, the user would need to know what a process is and what processes to protect. It would require trial and error, if some problem arises and see what protection needs to be disabled.

 

For Internet Explorer, I set the integrity level of Java's jp2launcher.exe (the Java plugin launcher) to low integrity with icacls. Java in the browser seemed to work properly, and with low integrity. Then, as a test case, I installed a program that requires standalone Java to function properly. Java ran with medium integrity in this case, which is what I hoped for.

The expected consequence of running Java as low integrity in the browser is that signed Java applets that need to write to non-low integrity locations will not work, unless they are manually made low integrity.

If somebody tries this, please report your experiences. I might consider doing this on my real system, even though I don't use Internet Explorer as my main browser. For the record, I do run Java as low integrity in my main browser, Firefox.

 

Outpost Firewall can apparently allow or block Java applets per site.

 

For Internet Explorer, there are apparently three Java-related security zone settings, two of which (1605-Run Java and 1C00-Java permissions) do not appear in the IE user interface. One could allow Java only in the Trusted sites zone.

 

In the Java Control Panel > Advanced > Security > General

there is a setting checked by default 'Allow user to grant permissions to content from an untrusted authority'

I presume this refers to settings that would normally be sandboxed, not trusted, so would unchecking this option cripple privilege escalations (perhaps with a few other certificate options altered so they always prompt, in case of self-signed ones)?

I'm not familiar at all with how the JRE works, but I would have thought any exploit prevention would be easiest to apply at the source and exhaust those options, rather than leave it at defaults and looks for OS or 3rd party workarounds/containment.

 

That setting is for signed applets (which operate outside of the Java sandbox) with an untrusted signature. The link in post #68 explains further.

 

Very interesting!

 

I don't use Java, so I can't really check it out, but today while looking - more like peeking - at a relative's computer that does, when looking at Internet Explorer's add-on manager, I right-clicked Java's plugin and picked the option that provides more information about the plugin, and if I'm not mistaken it's possible to allow Java on a per-site basis. One only needs to remove * from the list.

Can anyone confirm this?

 

The latest Chrome by default disables certain outdated plugins; the user can still choose to run the outdated plugin if desired though. Java is one of the plugins that Chrome will now disable by default if it's outdated.