Re: Further Defenses for the Security Manager

2015-01-15 Thread Michael Maass
Is there a standard corpus of applets that Oracle would use to test this kind of feature? I am need of an applet corpus and I am wondering if there is something out there already that you folks use. Michael On 12/19/2014 07:47 PM, Jeff Nisewanger wrote: Thank you for contacting us and sharing

Re: Further Defenses for the Security Manager

2015-01-08 Thread Michael Maass
Hello Jeff, Sorry for the delayed response. Regarding privilege escalation and class loading, our observation was that many Java exploits have an exploit class and a separate payload class. The exploit class typically attacks a vulnerability with the outcome that the payload class is loaded w

Re: Further Defenses for the Security Manager

2014-12-19 Thread Jeff Nisewanger
Thank you for contacting us and sharing the initial results of your research. You raised two basic topics. First, you discussed the possibility of adding additional restrictions on the ability to change the system Security Manager multiple times during application execution. This is normally al

Re: Further Defenses for the Security Manager

2014-10-30 Thread Michael Maass
>Since java.security.Security properties are themselves protected by permission, why not "cut out the middleman" and just have a permission type which grants permission to load such a class directly? Or is this what you're trying to avoid? (If so, then it seems you need to add a: 1a. If a sel

Re: Further Defenses for the Security Manager

2014-10-29 Thread David M. Lloyd
On 10/29/2014 08:35 AM, Michael Maass wrote: Hello All, I've spent the last 6 months working with some colleagues on a project that aimed to stop an exploitation avenue that has been popular with recent Java exploits: disabling the security manager. We think that what ended up with may be worthy

Further Defenses for the Security Manager

2014-10-29 Thread Michael Maass
Hello All, I've spent the last 6 months working with some colleagues on a project that aimed to stop an exploitation avenue that has been popular with recent Java exploits: disabling the security manager. We think that what ended up with may be worthy of a JEP and/or a prototype implementation