Why do all the serialized payloads contain java.lang.Override? about ysoserial HOT 3 CLOSED

The Groovy1 payload and any other that depends on an AnnotationInvocationHandler instance will require some annotation class to be present in the stream to work properly. java.lang.Override was arbitrary chosen because it was a parameter-less annotation class that was present in the JRE itself since annotations were introduced in Java 1.5.

I don't have specific experience with elasticsearch, but looking at some source code it looks like it uses a slightly modified deserialization stream format and behavior via ThrowableObjectOutputStream and ThrowableObjectInputStream that:

• omits the STREAM_MAGIC (0xACED) bytes in writeStreamHeader()/readStreamHeader()
• prefixes class descriptions with additional TYPE_EXCEPTION (0x2), TYPE_STACKTRACE_ELEMENT (0x3), TYPE_FAT_DESCRIPTOR (0x0), TYPE_THIN_DESCRIPTOR (0x1) bytes in writeClassDescriptor()/readClassDescriptor()
• has a custom loadClass() method that may load a custom classloader with fewer classes available

In this scenario, it seems likely that the last of these customizations may be getting in the way of it working, but it's hard to say for sure without more information about which path it's following through the readClassDescriptor() and loadClass() and what it's classpath environment looks like.

It may also be worth asking in the gitter chat to see if anyone else has come across this specific vector and/or issue before.

from ysoserial.

Thank you for the reply @frohoff. I will try and look into the issue further with your feedback in mind.

from ysoserial.

Closing after resolution via gitter chat.

from ysoserial.