beans Statement package accessibility checks
Mark Wielaard
mjw at redhat.com
Wed Aug 29 03:24:13 PDT 2012
Hi,
I was looking at some public exploit in metasploit that apparently is
being actively used.
https://raw.github.com/rapid7/metasploit-framework/master/external/source/exploits/CVE-2012-4681/Exploit.java
It is a cute, but evil exploit. It abuses
java.beans.Statement/Expression to get a reference to a method in a
restricted package and then uses that method
(sun.awt.SunToolkit.getField) to get and set the access control context
field of the Statement itself. After which it can just use the Statement
to disable the SecurityManager.
The reason this works is because Statement used to guard against getting
access to Methods, Fields and Constructors of restricted packages, but
with the following change: 6788531: java.beans.Statement imposes
excessive access control (revision e02f2d591cd5)
http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/e02f2d591cd5
these checks seem to have been forgotten in the rewrite. The old
FieldUtil, MethodUtil and ContructorUtil code had them, while the new
ConstructorFinder, FieldFinder and MethodFinder don't.
The following patch (against icedtea7, sorry Andrew I still haven't
figured out the forest stuff, but it should apply cleanly against the
openjdk 7 forest too) reintroduces the PackageAccessible checks.
diff -r 727519ab8096 Makefile.am
--- a/Makefile.am Fri Aug 24 01:53:20 2012 +0100
+++ b/Makefile.am Wed Aug 29 11:23:11 2012 +0200
@@ -245,7 +245,8 @@
patches/werror-langtools.patch \
patches/werror-hotspot.patch \
patches/no_diz_files.patch \
- patches/7192804-jvisualvm.patch
+ patches/7192804-jvisualvm.patch \
+ patches/beans-isPackageAccessible.patch
# Conditional patches
Also attached is a small adaptation of the metasploit testcase that can
be run with: java -Djava.security.manager Exploit
Which shows the issue when a security manager is installed and that it
is back to the old behavior of denying access after the patch. We should
probably turn that into a jtreg testcase.
I have only very lightly tested it but this code is somewhat hairy, so
some extra pair of eyes and some more testing would not be a bad thing.
I do think it makes sense to try to do an icedtea/openjdk release with
this (or some other/better) fix ASAP because it seems to be actively
exploited in the wild.
Cheers,
Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: beans-isPackageAccessible.patch
Type: text/x-patch
Size: 3101 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120829/62d2057d/beans-isPackageAccessible.patch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Exploit.java
Type: text/x-java
Size: 2376 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120829/62d2057d/Exploit.java
More information about the distro-pkg-dev
mailing list