[Java]: Delayed unsafe deserialization

[artem-smotrakov]

Query PR

github/codeql#8501

Language

Java

CVE(s) ID list

CVE-2016-6194

CWE

CWE-502

Report

Deserialization can sometimes be implemented in two steps. An untrusted serialized object can be stored in a field but actual deserialization happens only when the object is necessary. CVE-2016-6194 in RabbitMQ is an example of such scenario (GitHub issue). Untrusted data that comes from a response is stored in RMQObjectMessage.buf field. Then, deserialization happens when getObject() method is called. Currently, java/unsafe-deserialization query doesn't catch this. I've suggested several updates to the query that allows detecting it.

Are you planning to discuss this vulnerability submission publicly? (Blog Post, social networks, etc).

• Yes
• No

Blog post link

No response

[pwntester]

Hi @artem-smotrakov thanks for your submission!

Im evaluating the scope of your submission and wondering if you would be interested in extending it to other JMS implementations

[artem-smotrakov]

Hi @pwntester Looks like the PR is going to be split. I'll cover both RabbitMQ and JMS in a separate PR. There are two versions of JMS: 1.x and 2.x. I guess it makes sense to cover both unless there is a reason against it.

I am not sure whether the update to java/unsafe-deserialization for delayed deserialization is going to be accepted. We'll discuss it in a separate PR. Without that update, the query wouldn't catch CVE-2016-6194. Not sure if this submission could be accepted without this. We'll see how it goes.

[pwntester]

@artem-smotrakov Supporting both JMS 1.x and JMS 2.x is ok and it will raise the scope rating.
The CVE will be accepted no matter if we decide to split that taintstep into a new PR (check a comment I just left in the PR in case its possible to model that step with a framework-specific taintstep)

[artem-smotrakov]

hey @pwntester Sounds good. I'll try to cover at least JMS 1.x and 2.x. That should cover a good part of all JMS implementations. There may be some implementation-specific API. I'll try to look at the most popular implementations and see what can be modeled there.

[artem-smotrakov]

The original PR has been split to two

github/codeql#8765 Adds new flow sources and steps for JMS API versions 1 and 2, RabbitMQ, and a few for Java I/O
github/codeql#8766 Adds a new experimental query for delayed unsafe deserialization

[ghsecuritylab]

Your submission is now in status Closed.

For information, the evaluation workflow is the following:
Initial triage > Test run > Results analysis > Query review > Final decision > Pay > Closed

[artem-smotrakov]

Hi @pwntester Could you please re-open this? I just split the original PR to two and covered JMS. Or, should a new issue be opened?

[pwntester]

My fault, reopening

UPDATE: use this one for the "Delayed deserialization" one but please open a new one for the JMS improvements

[artem-smotrakov]

UPDATE: use this one for the "Delayed deserialization" one but please open a new one for the JMS improvements

Sounds good, I've opened #666