"Bypassing type safety attack" doesn't work (anymore?)

[jfkimmes]

Hi,
thanks alot for your blogpost that I just discovered. I tried to follow along with the examples in this repository. Everything worked well up until the illegal method call deserialization attack.

I successfully ran your server (from the previous examples) and the client with the additional parameters and the YouDebug debugger attached.

Loaded...
[+] java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod() is called
[+] Argument 0: 123456
[+] Needle 12345 found, replacing String with payload
[+] Done..

The client, however, fails with a java.lang.ClassCastException().

Listening for transport dt_socket at address: 8000
Calling bsides.register()
java.lang.ClassCastException: Cannot cast an object to java.lang.String
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1623)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:465)
        at java.io.ObjectInputStream.readString(ObjectInputStream.java:435)
        at sun.rmi.server.UnicastRef.unmarshalValue(UnicastRef.java:325)
        at sun.rmi.server.UnicastServerRef.unmarshalParametersUnchecked(UnicastServerRef.java:629)
        at sun.rmi.server.UnicastServerRef.unmarshalParameters(UnicastServerRef.java:617)
        at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:338)
        at sun.rmi.transport.Transport$1.run(Transport.java:200)
        at sun.rmi.transport.Transport$1.run(Transport.java:197)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
        at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
        at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:303)
        at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:279)
        at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164)
        at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:235)
        at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:180)
        at com.sun.proxy.$Proxy0.register(Unknown Source)
        at de.mogwailabs.BSidesRMIService.BSidesClient.main(BSidesClient.java:20)

I had a look at the OpenJDK commit history and it seems to me that no security patches have been applied since your blog post (?)
Can you confirm that the attack still works? What Java Distribution were you using?

openjdk version "1.8.0_242"
OpenJDK Runtime Environment (build 1.8.0_242-b08)
OpenJDK 64-Bit Server VM (build 25.242-b08, mixed mode)

Best regards!

[jfkimmes]

I had a second look at the JDK commits. Turns out I missed this commit when I first looked into this.

Strings seem to be handled as an extra case now in unmarshalValue().

I didn't look into bypassing this. Just thought I'd let you know.

[Hug0Vincent]

Hello, I have the same issue. Do you think It's possible to bypass these checks ?