[Grothendank]

Is ghidra safe to use if you consider the NSA an adversary?

Every person I've asked this question has had their noses so far up the NSA's pooper that they could not imagine considering the NSA an adversary.

But suppose you were running a malware honeypot operation for the CCP. Would you still use Ghidra? Why or why not?

And please don't pass the buck and say, "I probably wouldn't be allowed to use ghidra" or "I'd probably use whatever my CCP handler told me to use" or "I wouldn't be working for the CCP in the first place." That does not inform me about the security risks of using ghidra with the NSA as an adversary.

[mumbel]

It's pretty dumb this continues to come up years later. You're the NSA delivering source code to the cyber security community. The exact community that: doesn't immediately trust NSA, knows how to find bugs, would love to find any sort of bug in their code (regardless if malicious), people you want to apply for your jobs, people you partner with (academia/other govt orgs/other country cyber security groups).

So your thinking is: yes, this is the crowd we'll attempt to insert backdoor java code.

Okay fine you still don't trust them? Run in a VM without network connection. What security risks/threat are you even talking about?

And yes people have heavily audited the source. You either trust the community catches thing or not. I'm the end of your still tin foil about it, don't use, nobody cares.

[Grothendank]

Here's my basic position:

1. The risk and threats are published

2. The audits I've seen don't evaluate the threats

3. Link me to the audits if you want to convince me

I. The risks - airgapping is not enough

1. If the software has zeroday beacons in it, it can communicate with zeroday beacon repeaters embedded in VM, OS, or hardware (see: cache side channels: https://dl.acm.org/doi/abs/10.1145/3133956.3136064 )

2. The beacons wouldn't have to look like exploit code, they could just be timing bugs sprinkled into the codebase at random. There are plenty of random little warnings and defects in the code that nobody is ever going to check or fix, see this audit: https://github.com/NationalSecurityAgency/ghidra/issues/382

3. Airgaps may be broken by ultrasound side channels; communication to compromised devices like smartphones is possible (see: speaker-to-gyroscope communication https://ieeexplore.ieee.org/abstract/document/9647842/ ; speaker-to-speaker communication https://arxiv.org/pdf/1803.03422.pdf)

4. Low bitrate data leaks, like "ghidra is running in this org, decompiling files named....." may be accumulated by the NSA

This is just zero-day warehousing and passive signals collection with embedded zerodays. It would be hard for security researchers to detect this. I'd happily change my mind if you showed me an audit that looks for beacons and other side channels.

II. The audits

Here is the one audit I could find

https://github.com/NationalSecurityAgency/ghidra/issues/382

This audit tells us that the code is janky, but doesn't tell us if it's secure. It's just a dump of thousands upon thousands of static analysis errors.

There's no threat anaylsis in this audit. But it does suggest the code has so many defects that a serious audit would be very expensive.

III. Change my mind with evidence

Please link me to the heavy audits of the code. If you can.

tldr;; I think the code is less heavily audited than you can support

[lovetocode]

Code is right there -- just look at it.

[Grothendank]

I'm looking at it. It's very beautiful code. 2,049,616 lines of it.

Okay. I have looked at the code. Now what? Has that made me more secure?

[lionkor]

Yes https://github.com/NationalSecurityAgency/ghidra

[Grothendank]

I'm not trying to be flippant here, but how many of ghidra's 2 million lines of code have you audited?