Java: Query for detecting unsafe deserialization with Spring exporters

[artem-smotrakov]

CVE ID(s)

Not yet.

Report

Spring Framework provides an abstract base class RemoteInvocationSerializingExporter for defining remote service exporters. A Spring exporter, which is based on this class, deserializes incoming data using ObjectInputStream. Deserializing untrusted data (CWE-502) is easily exploitable and in many cases allows an attacker to execute arbitrary code. Spring Framework also provides two classes that extend RemoteInvocationSerializingExporter:

• HttpInvokerServiceExporter
• SimpleHttpInvokerServiceExporter

CVE-2016-1000027 has been assigned to this issue in Spring Framework. There is no fix for that.

I'd like to propose a new experimental query that looks for unsafe deserialization with Spring exporters:

github/codeql#5260

Many projects have received alerts about CVE-2016-1000027 from security scanners. Since Spring Framework didn't address the issue, they can't just update Spring Framework. Instead, they have to understand the issue and check their code. This query can make their life easier and help them check the code. Moreover, the query can detect unsafe exporters even without scanners that look for known vulnerabilities.

• Are you planning to discuss this vulnerability submission publicly? (Blog Post, social networks, etc). We would love to have you spread the word about the good work you are doing

I wrote a blog post about detecting unsafe deserialization with Spring exporters with CodeQL.

Result(s)

• Unsafe deserialization in HELIX-GR/lab: The server has a endpoint that uses a vulnerable exporter which can lead to RCE in the worst case (depends on a gadget).
• Unsafe deserialization in YAMJ/yamj-v3: The server has a endpoint that uses a vulnerable exporter which can lead to RCE in the worst case (depends on a gadget).

[ghsecuritylab]

Your submission is now in status SecLab review.

For information, the evaluation workflow is the following:
CodeQL initial assessment > SecLab review > CodeQL review > SecLab finalize > Pay > Closed

[pwntester]

Thanks for the submission @artem-smotrakov!

The query as is is only returning two results in LGTM. I think it is mostly due to these exporters being mostly used in XML-based configurations. Can you please extend the submission to account for XML declared exporters?

[artem-smotrakov]

That would be a good improvement but I thought CodeQL can't parse XML files. I'll look into it. Meanwhile, please let me know if you have an example of a query that checks XML files.

[pwntester]

There are probably better examples but one using SpringBean class is UnusedBean

[artem-smotrakov]

Thanks @pwntester !

[artem-smotrakov]

@pwntester I've updated the query to detect vulnerable exporters in XML configs -- thanks for the suggestion! I realized it is not possible to use both Method and SpringBean in select, and it is not possible to cast XMLElement to Element. To overcome this, I use File in select. I am not sure whether this is the best solution or not. Another option is just to write two separate queries. Please let me know if you have a better idea.

[pwntester]

I think that reporting on the File can be confusing for users, so it would be better to split it into two separate queries. But I leave that to the CodeQL experts /cc @smowton

[smowton]

Two queries sounds right to me in this case

[artem-smotrakov]

I'll split the query then. If I understand correctly, each query needs its own qhelp file as well.

[artem-smotrakov]

@pwntester @smowton I've split the query. One selects Method, another one selects SpringBean. Please let me know what you think.

[ghsecuritylab]

Your submission is now in status CodeQL review.

For information, the evaluation workflow is the following:
CodeQL initial assessment > SecLab review > CodeQL review > SecLab finalize > Pay > Closed

[ghsecuritylab]

Your submission is now in status SecLab finalize.

For information, the evaluation workflow is the following:
CodeQL initial assessment > SecLab review > CodeQL review > SecLab finalize > Pay > Closed

[artem-smotrakov]

Just FYI I wrote a blog post about detecting unsafe Spring service exporters with CodeQL.

[xcorail]

Hey @artem-smotrakov let me know when you tweet about your blog post ;-)

[artem-smotrakov]

Hey @xcorail Just created a tweet :)

[ghsecuritylab]

Your submission is now in status Pay.

For information, the evaluation workflow is the following:
CodeQL initial assessment > SecLab review > CodeQL review > SecLab finalize > Pay > Closed

[ghsecuritylab]

Your submission is now in status Closed.

For information, the evaluation workflow is the following:
CodeQL initial assessment > SecLab review > CodeQL review > SecLab finalize > Pay > Closed