Deserialization issue in Ghidra Server

[ChrisJoinEngine]

Describe the bug https://github.com/adrianbn and I are security researches. While doing some work on RMI, we discovered Ghidra Server is vulnerable to a deserialization attack via RMI that leads to SSRF. This is a partially blind SSRF, but requires no authentication.

To Reproduce We have a proof of concept we can share. In the interest of responsible disclosure, we didn't want to make our github page public just yet, but please let us know if you'd like access, it's currently at https://github.com/ChrisJoinEngine/CVE-2021-40821 (private github as of posting this, we'll add you as collaborators).

1. The getRepositoryServer method in the GhidraServerHandle class takes unvalidated serialized objects
2. While these objects are not the trivial case of Java Deserialization, a proxy can be used to provide arbitrary objects to this method
3. A gadget chain exists in Ghidra that culminates in SSRF
4. By passing in a malicious object that invokes this gadget chain, Ghidra Server can be made to make an arbitrary request to a file or URL. This is mostly blind, but some stack traces can give some information to an attacker

Expected behavior The easiest way is to use our proof of concept, and point the script to a Burp Collaborator instance. When you run the script against a Ghidra Server instance, you will see an HTTP request in your collaborator from the Ghidra Server. You can also request a file that is present, and one that is not on the Server's filesystem (e.g. /etc/passwd and /etc/notreal); while you won't be able to view the files, you will see corresponding error messages.

Environment (please complete the following information):

• OS: Tested on an up to date OSX, as well as Windows 10 box. As it's Java it probably works on any OS
• Java Version: 11.0.12
• Ghidra Version: Pulled from master, 10.0.3 development. Probably other versions before that as well
• Ghidra Origin: build from https://github.com/NationalSecurityAgency/ghidra

Additional context Let us know who we give access to the proof of concept, or if there is a better way to report security issues. The PoC has additional details and walkthrough of the exploit.

[ryanmkurtz]

Thanks for sharing this with us. Can you please give access to @ghidra1?

[ChrisJoinEngine]

• Of course, collaborator invite has been sent

[ChrisJoinEngine]

Hi @ryanmkurtz,

I just wanted to follow up on this and see if you had any issues replicating or if any additional details were needed.

We usually follow Google's disclosure guidelines, and would like to make the proof of concept public in 90 days.

[ryanmkurtz]

Apologies for the delay...we'll have some feedback for you tomorrow. Thanks for your patience.

[ryanmkurtz]

Can you please invite me again?

[ChrisJoinEngine]

Sure thing, I sent you a new invite. Please don't hesitate to ask if the PoC gives you any issues at all. Thanks

[ghidra1]

@ChrisJoinEngine While we were unable to demonstrate SSRF with your test code we have added a serialization filter to the Ghidra Server which has been merged for both patch and master: edbad325084c237b8ffa82e399e884ed42e6358c

See related discussion here: https://github.com/ChrisJoinEngine/CVE-2021-40821/issues/1

Please let us know your disposition of CVE-2021-40821

[ChrisJoinEngine]

Yea, I think it is fair to close this one. Thanks for your time, and looking into it

[ryanmkurtz]

Thanks for bringing our attention to the potential issue.