Ghidra: Project handling is susceptible to XXE

[sghctoma]

Describe the bug
Project open/restore is susceptible to XML External Entity Expansion attacks. This can be exploited in various ways by getting someone to open/restore a project prepared by attacker.

To Reproduce
Steps to reproduce the behavior:

1. Create a project, and close it.
2. Put an XXE payload in any of the XML files in the project directory (see screenshot for example).
3. Open the project.
4. Observe your payload doing its thing.

The same concept works with archived projects (.gar files) too.

Expected behavior
The XML parser should ignore external entities. For bonus points, it should give an error/warning when they are present.

Screenshots
The following screenshot was made of a proof of concept that only issues an HTTP GET request to localhost.

Environment (please complete the following information):

• OS: Kali Linux Rolling
• JDK Version: OpenJDK 11.0.2 (11.0.2+9-Debian-3)
• Ghidra Version 9.0

[nsadeveloper789]

Good find! Thanks. Looks like a pretty straightforward configuration fix.

[sghctoma]

You're welcome.

Out of curiosity: are you sure there is a config fix for this? I.e. can external entity processing be disabled globally for JDOM/SAXBuilder? I was under the impression you have to turn it off for every SAXBuilder instance individually. If there is no global way, please make sure to fix this everywhere, because this issue is not restricted to projects; e.g. Tool import is also affected.

[nsadeveloper789]

Yeah. We're on the same page. When I said "configure" I didn't mean to imply there's some system property or whatever you set. I made factory methods to create properly configured SAXParsers and SAXBuilders, and refactored everything to use them.

[attritionorg]

@nsadeveloper789 Can you link to the fixing commit please?

[kant2002]

@attritionorg you could see it here: https://github.com/kant2002/Ghidra/pull/9/commits/19302d466a58974b88bc07a7ab4ff745c4e5520f
I go as far as I can in attempt to properly capture the appropriate changes.

[nsadeveloper789]

Unfortunately, no. Since our source repo is not yet published, there is no commit to link to. Additionally, the commit history up to the source release will not likely be present.
It looks like folks are tracking the 9.0 to 9.0.1 changes by unpacking the source .jars, though, and that should capture the relevant patches, albeit squashed with others.

[attritionorg]

@nsadeveloper789 thanks. @kant2002 linked to his fix which gives the additional info I am after. appreciate it!

[vernieri]

Thx alot.