search

logpresso / CVE-2021-44228-Scanner

Vulnerability scanner and mitigation patch for Log4j2 CVE-2021-44228
Apache License 2.0
852 stars 173 forks source link

tar.gz support #171

Open arykov opened 2 years ago

arykov commented 2 years ago

Would be good to add tar.gz support at least for scanning at least at the top level.

xeraph commented 2 years ago

Hmm.. Someone may implement this issue. However I don't want any additional dependency. Scanner will get complicated to support nested scanning and patching.

pinacoelho commented 2 years ago

Since tar.gz isn't usable by a java application, this would add complexity without identifying vulnerable applications. We should keep the focus on the directly usable formarts (JAR/EAR/WAR).

arykov commented 2 years ago

@pinacoelho, agreed on complexity(relative to zip). But disagree on value. There frequently are cases when software is distributed or backed up this way. So there is a risk of reintroduction of the problem. I assume you had the same rationale when implementing zip support and deciding not to limit "nesting" at 3 ear->war->jar

pinacoelho commented 2 years ago

So there is a risk of reintroduction of the problem.

There's always a risk, but while going down tar.gz's would cover that, it doesn't cover off-machine backups (Veritas NetBackup, IBM TSM, etc...). Also, backups are sacred: as a sysadmin, whatever I've put in a backup, I expect to be there when I restore (for whatever reason), and that's non-negotiable from sysadmin and audit PoVs.

I assume you had the same rationale when implementing zip support and deciding not to limit "nesting" at 3 ear->war->jar

Not my rationale, but in my opinion a valid one. EARs/WARs are archives of archives, so to find the JAR that you're running, you have to go inside.

This is Xeraph's brainchild, it would be up to him to decide.