GuardDog Only Scans "setup.py" For Code Execution

[cedricvanrompay-datadog]

guarddog/guarddog/analyzer/sourcecode/code-execution.yml

Line 1 in e49bf32

# Only searches in setup.py to reduce false positives!

guarddog/guarddog/analyzer/sourcecode/code-execution.yml

Lines 113 to 116 in e49bf32

	paths:
	include:
	- "*/setup.py"
	- "*/code-execution.py"

This causes a lot of malicious packages not to be detected because they perform code execution in other files.

It's true that reporting every single code execution would result in a lot of noise though.

We should at least make this limitation clear, because a lot of people are surprised that GuardDog does not report some malicious packages. See:

• Identify new malicious pypi packages #306
• New pypi exploits #311

[ColdHeat]

Hello! if possible I think this limitation should be removed or given a way to bypass it. Or perhaps non-setup.py hits should be shown as warnings.

To properly review a package I don't think it's enough to just look at setup.py, as evidenced by malicious packages that aren't being flagged by GuardDog.

[sobregosodd]

Hello @ColdHeat , thank you reaching out.
We are considering this enhancement, personally I consider than malware is more prone to running executions in the setup.py but executions by themselves (In any other part of the program) might not be as correlated to malicious behaviour thus yielding lots of false positives.

But we're analyzing the path forward.

[ColdHeat]

@sobregosodd Yes setup.py is going to be an easier place to get quick RCE since it will run on package install but the exploitation path would merely require that the user then run the package which is not unreasonable given that they just installed it.

The way I see it, Guarddog needs the ability to scan across an entire package and also to have the ability to keep a seperate list of allowed "unsafe" executions.

I see a similar project being worked on that analyzes the whole package, analyzes differences between versions, and I think could possibly get to the point where findings could be allowed/rejected.

https://github.com/ancat/whiskers
https://github.com/ancat/whiskers/blob/f091b36f51f080f55b63a5348b5d3a290beaccec/cmd/gem_diff_scan.go#L19-L24
https://github.com/ancat/whiskers/blob/f091b36f51f080f55b63a5348b5d3a290beaccec/cmd/gem_diff_scan.go#L109-L123

At the very least, I think guarddog should have a way via CLI or config to scan all files for rule hits instead of just specific files. Perhaps this means that the user would need to have their own rule but I do think this is something Guarddog should provide out of the box.