java security issue after update from 1.8.0_25 to 1.8.0_31

Question

Running JRE 8 32-bit on Windows Server 2016.

Not having problems running 1.8.0_25.

After updating to 1.8.0_31, one security exception reveals:

java.security.AccessControlException: access denied ("java.lang.reflect.ReflectPermission" "suppressAccessChecks")

Additional information after -Djava.security.debug=access,failure:

access: domain that failed ProtectionDomain  null
 null
 <no principals>
 java.security.Permissions@107f848 (
)


access: access denied ("java.lang.reflect.ReflectPermission" "suppressAccessChecks")
java.lang.Exception: Stack trace
    at java.lang.Thread.dumpStack(Thread.java:1329)
    at java.security.AccessControlContext.checkPermission(AccessControlContext.java:447)
    at java.security.AccessController.checkPermission(AccessController.java:884)
    at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
    at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:95)
    at org.apache.commons.lang.builder.HashCodeBuilder.reflectionAppend(HashCodeBuilder.java:165)
    at org.apache.commons.lang.builder.HashCodeBuilder.reflectionHashCode(HashCodeBuilder.java:348)
    at org.apache.commons.lang.builder.HashCodeBuilder.reflectionHashCode(HashCodeBuilder.java:387)
    at 
...
sun.security.ssl.ServerHandshaker.setupPrivateKeyAndChain(ServerHandshaker.java:1403)
    at sun.security.ssl.ServerHandshaker.trySetCipherSuite(ServerHandshaker.java:1215)
    at sun.security.ssl.ServerHandshaker.chooseCipherSuite(ServerHandshaker.java:1009)
    at sun.security.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:731)
    at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:213)
    at sun.security.ssl.Handshaker.processLoop(Handshaker.java:957)
    at sun.security.ssl.Handshaker.process_record(Handshaker.java:892)
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1050)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363)
    at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:916)
    at sun.security.ssl.AppInputStream.read(AppInputStream.java:105)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
    at java.io.DataInputStream.readInt(DataInputStream.java:387)
    at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:722)
    at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$240(TCPTransport.java:683)
    at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$1/26915897.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

Also, from the debug log, one can see multiple

access: access allowed ("java.lang.reflect.ReflectPermission" "suppressAccessChecks")

, before and after the denied occurrence.

Tried 1.8.0_192 without success.

Some help would be appreciated.

If you enable Java security, such that only secured code can use reflection, and your code then does reflection (by using Commons Lang's `HashCodeBuilder`) without establishing a security context, why are you confused that it fails? — Andreas, Dec 04 '18 at 17:38
Your usage (either direct or transient) of https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/builder/HashCodeBuilder.html is the problem. Specifically `Alternatively, there is a method that uses reflection to determine the fields to test. Because these fields are usually private, the method, reflectionHashCode, uses AccessibleObject.setAccessible to change the visibility of the fields. This will fail under a security manager, unless the appropriate permissions are set up correctly. It is also slower than testing explicitly.` — Taylor, Dec 04 '18 at 17:38
This is only going to get worse, since Java 9+ has stringent restrictions on reflection. Expect “clever” hacks that rely on reflection to fail a lot more. Instead of [HashCodeBuilder](https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/builder/HashCodeBuilder.html), why not just use Java SE’s [Objects.hash](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Objects.html#hash(java.lang.Object...)) instead? — VGR, Dec 04 '18 at 17:40
@Andreas There is a policy file granting permissions to all!? — rjesus, Dec 05 '18 at 08:37
@Taylor Reflection seems not to be the only problem here! Other "access denied" are show, like "access: access denied ("java.util.PropertyPermission" "org.bouncycastle.pkcs1.strict" "read")", also after ans before the corresponding "access allowed". — rjesus, Dec 05 '18 at 08:44
@rjesus Is there a policy file granting permissions to all? The default policy file, that is installed with Java, wouldn't do that, and your question doesn't mention anything about *you* changing the policy file, — Andreas, Dec 05 '18 at 15:33
@Andreas Yes, as I wrote before. You seem surprised, lust like me, and that is why I ended the statement with exclamation and question marks! — rjesus, Dec 06 '18 at 08:10

java security issue after update from 1.8.0_25 to 1.8.0_31

0 Answers0