FreshPorts - VuXML

This page displays vulnerability information about FreeBSD Ports.

The last vuln.xml file processed by FreshPorts is:

Revision:  371119
Date:      2014-10-18
Time:      12:52:26Z
Committer: kwm

List all Vulnerabilities, by package

List all Vulnerabilities, by date

These are the vulnerabilities relating to the commit you have selected:

VuXML IDDescription
d5e0317e-5e45-11e2-a113-c48508086173java 7.x -- security manager bypass

US CERT reports:

Java 7 Update 10 and earlier versions of Java 7 contain a vulnerability that can allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable system.

The Java JRE plug-in provides its own Security Manager. Typically, a web applet runs with a security manager provided by the browser or Java Web Start plugin. Oracle's document states, "If there is a security manager already installed, this method first calls the security manager's checkPermission method with a RuntimePermission("setSecurityManager") permission to ensure it's safe to replace the existing security manager. This may result in throwing a SecurityException".

By leveraging the vulnerability in the Java Management Extensions (JMX) MBean components, unprivileged Java code can access restricted classes. By using that vulnerability in conjunction with a second vulnerability involving the Reflection API and the invokeWithArguments method of the MethodHandle class, an untrusted Java applet can escalate its privileges by calling the the setSecurityManager() function to allow full privileges, without requiring code signing. Oracle Java 7 update 10 and earlier Java 7 versions are affected. The invokeWithArguments method was introduced with Java 7, so therefore Java 6 is not affected.

This vulnerability is being attacked in the wild, and is reported to be incorporated into exploit kits. Exploit code for this vulnerability is also publicly available.

Esteban Guillardoy from Immunity Inc. additionally clarifies on the recursive reflection exploitation technique:

The real issue is in the native sun.reflect.Reflection.getCallerClass method.

We can see the following information in the Reflection source code:

Returns the class of the method realFramesToSkip frames up the stack (zero-based), ignoring frames associated with java.lang.reflect.Method.invoke() and its implementation.

So what is happening here is that they forgot to skip the frames related to the new Reflection API and only the old reflection API is taken into account.

This exploit does not only affect Java applets, but every piece of software that relies on the Java Security Manager for sandboxing executable code is affected: malicious code can totally disable Security Manager.

For users who are running native Web browsers with enabled Java plugin, the workaround is to remove the java/icedtea-web port and restart all browser instances.

For users who are running Linux Web browser flavors, the workaround is either to disable the Java plugin in browser or to upgrade linux-sun-* packages to the non-vulnerable version.

It is not recommended to run untrusted applets using appletviewer, since this may lead to the execution of the malicious code on vulnerable versions on JDK/JRE.


Discovery 2013-01-10
Entry 2013-01-14
openjdk7
gt 0

linux-sun-jdk
ge 7.0 lt 7.11

linux-sun-jre
ge 7.0 lt 7.11

CVE-2013-0433
625617
http://www.oracle.com/technetwork/topics/security/alert-cve-2013-0422-1896849.html
https://partners.immunityinc.com/idocs/Java%20MBeanInstantiator.findClass%200day%20Analysis.pdf
16846d1e-f1de-11e1-8bd8-0022156e8794Java 1.7 -- security manager bypass

US-CERT reports:

Oracle Java Runtime Environment (JRE) 1.7 contains a vulnerability that may allow an applet to call setSecurityManager in a way that allows setting of arbitrary permissions.

By leveraging the public, privileged getField() function, an untrusted Java applet can escalate its privileges by calling the setSecurityManager() function to allow full privileges, without requiring code signing.

This vulnerability is being actively exploited in the wild, and exploit code is publicly available.

This exploit does not only affect Java applets, but every piece of software that relies on the Java Security Manager for sandboxing executable code is affected: malicious code can totally disable Security Manager.


Discovery 2012-08-27
Entry 2012-08-30
Modified 2012-08-31
openjdk
ge 7.0 lt 7.6.24_1

linux-sun-jdk
ge 7.0 lt 7.7

linux-sun-jre
ge 7.0 lt 7.7

CVE-2012-4681
636312
http://www.deependresearch.org/2012/08/java-7-vulnerability-analysis.html
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-August/020065.html
http://www.oracle.com/technetwork/topics/security/alert-cve-2012-4681-1835715.html