java version “1.6.0_11”
Java™ SE Runtime Environment (build 1.6.0_11-b03)
Java HotSpot™ Client VM (build 11.0-b16, mixed mode, sharing)
on Vista Home Basic (SP1, x86, ITA)
How to reproduce the crash:
a. Activate DEP in 32bit IE7 (must be admin): go to ‘Internet options>Advanced>Security’, check Enable memory protection to help mitigate online attacks.
b. go to http://www.java.com/it/download/help/testvm.xml
c. IE7 will be forced to close
By reading on suns homepage, its may or may not be a bug in IE and its built in DEP.
They described it as a bug in ie and and the way it handle this update of java with a not the default setting of IE.
Maby it gets missed by CMF due to its not really a bufferowerflow attack preformed by the java uppdate but rather a bug in IE misstaking it to be a bufferoverflow while in fact its not.
But CMF only claims to protect against 90% and more of BO attacks, maby this is one that it misses.
Good that you got IEs built in memory protection too then!
Hope comodo fixes this if its in fact is a bug in the memoryfirewall.
But I know they will (V) comodo don’t accept leaks in the firewall, and I dubt they will allow their memory firewall to leak/miss things like this either.
The issue is triggered by Sun Java activex control which was built with old Microsoft Compiler that used techniques that are now prevented by DEP.
Older versions of ATL, and by older I mean pre-Visual C++ 2005, used dynamically generated code in small isolated cases. Obviously, without the appropriate APIs this is going to cause problems on a DEP-enabled computer, because you can't execute data. This code is referred to as a "thunk" and versions of ATL in VC++ 2005 and later work correctly with DEP.
The comment above is correct except for the suggestion that we could fix the Java Plug-In by adding one line of code. Our discussions with Microsoft have indicated that only they can fix the problem with IE 7. Making the API call in our ActiveX control would have no effect from what they have told us. They have also said that IE 8 will contain this API call, meaning that ActiveX controls like ours compiled with older compilers will work again.
ActiveX plugins which trigger this issue have to be ported to more recent Miscrosoft Compilers
[b]Developer Call to Action [/b]
If you build Internet Explorer add-ons, you can help ensure users enjoy a smooth upgrade to IE8 by taking the following steps today:
If your code depends on older versions of ATL, please rebuild it with ATL v7.1 SP1 or later (Visual Studio 2005 includes ATL 8.0)
Set the /NXCompat linker option to indicate that your extension is compatible with DEP/NX
Test your code with DEP/NX enabled using IE8 Beta 1 on Windows Vista SP1. (Alternatively, test with IE7 on Windows Vista after enabling the DEP/NX option. To enable DEP/NX for IE7: Run IE as an administrator, then set the appropriate checkbox in the Tools > Internet Options > Advanced tab)
Opt your code into other available defenses like stack defense (/GS), safe exception handling (/SafeSEH), and ASLR (/DynamicBase)
It is likely that Comodo BO Prevention engine featured by Safesurf or Comodo Memory Firewall was designed to minimize the chances users will not able to run legitimate application or plugins thus continuing to offer protection in scenarios like this where the users are supposed to disable DEP for Internet Explorer in order to use Java plugin.
For those interested… Sun has finally fixed this annoying problem with IE7’s DEP! IE7 won’t crash anymore when its DEP is enabled and you load a Java applet.
You can download Java JRE 6u12b03 from http://download.java.net/jdk6/
