Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Generic)  >   Oracle Java SE Vendors:   IBM
IBM Java Insecure Method Lets Remote Users Execute Arbitrary Code on the Target System
SecurityTracker Alert ID:  1035507
SecurityTracker URL:
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Apr 7 2016
Impact:   Execution of arbitrary code via network, User access via network
Vendor Confirmed:  Yes  Exploit Included:  Yes  

Description:   A vulnerability was reported in IBM Java. A remote user can execute arbitrary code on the target system outside of the Java sandbox.

A remote user can use the invoke method of 'java.lang.reflect.Method' to call the 'setSecurityManager' method of 'java.lang.System' and execute arbitrary code on the target system outside of the Java security sandbox.

[Editor's note: The vulnerability was originally reported and fixed in May 2013. However, the fix moved the vulnerable function, which can still be accessed via another path.]

The original advisory is available at:

Some demonstration exploit code is available at:

Adam Gowdiak of Security Explorations reported this vulnerability.

Impact:   A remote user can execute arbitrary code on the target system outside of the Java sandbox.
Solution:   No solution was available at the time of this entry.

The vendor is working on a fix.

The vendor's advisory is available at:

Vendor URL: (Links to External Site)
Cause:   Access control error
Underlying OS:  Linux (Any), UNIX (AIX), UNIX (Solaris - SunOS), Windows (Any)

Message History:   None.

 Source Message Contents

Subject:  [SE-2012-01] Broken security fix in IBM Java 7/8

Hello All,

Those concerned about security of IBM Java [1] may find this post

We discovered that a fix for a security vulnerability (Issue 67)
[2] we reported to the company in May 2013 didn't address the
problem properly.

This is the 6th instance of a broken patch we encountered from
IBM. Previously, the company failed to address 4 other issues
(with one of them improperly patched for two times in a row).

Similarly to previous cases, the fix for Issue 67 addressed the
scenario illustrated by a Proof of Concept code. The actual root
cause of the issue hasn't been addressed at all. There were no
security checks introduced anywhere in the code. The patch relied
solely on the idea that hiding the vulnerable method deep in the
code and behind a Proxy class would be sufficient to address the

Breaking IBM patch for Issue 67 requires only several minor changes
to our original Proof of Concept code published in Jul 2013.

Full technical details of IBM fix bypass can be found in our technical

Along with the report, we have also published a Proof of Concept code
to illustrate the broken fix:

The POC was successfully tested in a 32-bit Linux OS environment and
with the following versions of IBM Java:
- IBM SDK, Java Technology Edition, Version 7.1 for Linux (32-bit x86)
   released on 2016-01-26 (build pxi3270_27sr3fp30-20160112_01(SR3 FP30))
- IBM SDK, Java Technology Edition, Version 8.0 for Linux (32-bit x86)
   released on 2016-01-26 (build pxi3280sr2fp10-20160108_01(SR2 FP10))

We verified that, a complete Java security sandbox escape could be
achieved with it.

Thank you.

Best Regards,
Adam Gowdiak

Security Explorations
"We bring security research to the new level"

[1] IBM developer kits
[2] SE-2012-01-IBM-2, Issues 62-68


Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2019, LLC