Security of the Java software platform

The Java software platform provides a number of features designed for improving the security of Java applications. This includes enforcing runtime constraints through the use of the Java Virtual Machine (JVM), a security manager that sandboxes untrusted code from the rest of the operating system, and a suite of security APIs that Java developers can utilise. Despite this, criticism has been directed at the programming language, and Oracle, due to an increase in malicious programs that revealed security vulnerabilities in the JVM, which were subsequently not properly addressed by Oracle in a timely manner.

staticUnsafegetUnsafe();: retrieves the Unsafe instance. It uses sun.reflect.Reflection to do so.

nativeObjectgetObject(Objecto,longoffset);: fetches a reference value from an object at the given offset.

nativevoidputInt(longaddress,intx);: stores a value into the given address. (There are corresponding putBoolean(), putByte(), putShort(), putChar(), putLong(), putFloat(), and putDouble() methods as well.)

nativelongallocateMemory(longbytes);: allocates a block of native memory of the given size (similar to realloc()).

memset()).

memcpy()).

nativelongstaticFieldOffset(Fieldf);: obtains the location of a given field in the storage allocation of its class.

nativevoidensureClassInitialized(Class<?>c);: ensures the given class has been initialized.

arrayClass);"},"parts":[{"template":{"target":{"wt":"java","href":"./Template:Java"},"params":{"1":{"wt":"native int arrayBaseOffset(Class<?> arrayClass);"}},"i":0}}]}'>nativeintarrayBaseOffset(Class<?>arrayClass);: obtains the offset of the first element in the storage allocation of a given array class.

arrayClass);"},"parts":[{"template":{"target":{"wt":"java","href":"./Template:Java"},"params":{"1":{"wt":"native int arrayIndexScale(Class<?> arrayClass);"}},"i":0}}]}'>nativeintarrayIndexScale(Class<?>arrayClass);: obtains the scale factor for addressing elements in the storage allocation of a given array class.

nativeClass<?>defineClass(Stringname,byte[]b,intoff,intlen,ClassLoaderloader,ProtectionDomainprotectionDomain);: signals to the JVM to define a class without security checks.

defineAnonymousClass(Class<?> hostClass, byte[] data, Object[] cpPatches);"},"parts":[{"template":{"target":{"wt":"java","href":"./Template:Java"},"params":{"1":{"wt":"native Class<?> defineAnonymousClass(Class<?> hostClass, byte[] data, Object[] cpPatches);"}},"i":0}}]}'>nativeClass<?>defineAnonymousClass(Class<?>hostClass,byte[]data,Object[]cpPatches);: signals to the JVM to define a class but do not make it known to the class loader or system directory.

cls) throws InstantiationException;"},"parts":[{"template":{"target":{"wt":"java","href":"./Template:Java"},"params":{"1":{"wt":"native Object allocateInstance(Class<?> cls) throws InstantiationException;"}},"i":0}}]}'>nativeObjectallocateInstance(Class<?>cls)throwsInstantiationException;: allocates an instance of a class without running its constructor.

nativebooleantryMonitorEnter(Objecto);: tries to lock an object, returning whether the lock succeeded.

nativeintgetIntVolatile(Objecto,longoffset);: volatile version of getInt(). (There are corresponding getBooleanVolatile(), getByteVolatile(), getShortVolatile(), getCharVolatile(), getLongVolatile(), getFloatVolatile(), getDoubleVolatile(), and getObjectVolatile() methods as well.)

nativevoidunpark(Objectthread);: unblocks a thread.

nativevoidinvokeCleaner(ByteBufferdirectBuffer);: invokes the given direct byte buffer's cleaner.

nativevoidstoreFence();: ensures loads and stores before the fence will not be reordered with stores after the fence.

An example usage the following:

There are a number of possible sources of security vulnerabilities in Java applications, some of which are common to non-Java applications and some of which are specific to the Java platform. (Note that these refer to potential sources of vulnerabilities which need to be kept in mind by security-conscious programmers: this is not intended as a list of actual vulnerabilities.)

Examples of potential sources of vulnerability common to Java and non-Java applications are:

• Vulnerabilities in the protection mechanisms provided by the hardware or operating system which the application relies upon for its security
• Vulnerabilities in native libraries, such as the C standard library, which may be used to implement the application and/or runtime
• Vulnerabilities caused purely by errors in user programs (for example improper construction of SQL queries leading to SQL injection vulnerabilities)

However, much discussion of Java security focusses on potential sources of vulnerability specific to the Java platform. These include:

• Vulnerabilities in the sandboxing mechanism which allow untrusted bytecode to circumvent the restrictions imposed by the security manager
• Vulnerabilities in the Java class library which an application relies upon for its security

A vulnerability in the Java platform will not necessarily make all Java applications vulnerable. When vulnerabilities and patches are announced, for example by Oracle, the announcement will normally contain a breakdown of which types of application are affected (example).

For example, a hypothetical security flaw which affects only the security manager sandboxing mechanism of a particular JVM implementation would mean that only Java applications which run arbitrary untrusted bytecode would be compromised: applications where the user fully trusts and controls all bytecode being executed would not. This would mean that, say, a web browser plugin based on that JVM would be vulnerable to malicious applets downloaded from public websites, but a server-side web application running on the same version of the JVM where the administrator has full control over the classpath would be unaffected. As with non-Java applications, security vulnerabilities can stem from parts of the platform which may not initially appear to be security-related. For example, in 2011, Oracle issued a security fix for a bug in the "sun.misc: Unsafe.java". docjar.com. Archived from the original on September 30, 2016.

↑ Geuss, Megan (April 14, 2012). "Flashback malware removal tool arrives for Java-less Mac users". Ars Technica. Retrieved February 18, 2014.

↑ Cheng, Jacqui (December 23, 2012). "Where OS X security stands after a volatile 2012". Ars Technica. Retrieved February 18, 2014.

↑ Foresman, Chris (January 11, 2013). "Apple blacklists Java on OS X to prevent latest "critical" exploits". Ars Technica. Retrieved February 18, 2014.

↑ Goodin, Dan (January 15, 2013). "Red October relied on Java exploit to infect PCs". Ars Technica. Retrieved February 18, 2014.

↑ Goodin, Dan (January 18, 2013). "Critical Java vulnerabilities confirmed in latest version". Ars Technica. Retrieved February 18, 2014.

↑ Foresman, Chris (January 31, 2013). "For second time in a month, Apple blacklists Java Web plugin". Ars Technica. Retrieved February 18, 2014.

↑ Cheng, Jacqui (February 19, 2013). "Apple HQ also targeted by hackers, will release tool to protect customers". Ars Technica. Retrieved February 18, 2014.

↑ Brodkin, Jon (February 25, 2013). "Java's latest security problems: New flaw identified, old one attacked". Ars Technica. Retrieved February 18, 2014.

↑