Fix zipslip for jar #448
Fix zipslip for jar #448
Conversation
| @@ -131,12 +133,14 @@ public void save(final Function<String, StructClass> loader) throws IOException | |||
|
|
|||
| // directory entries | |||
| for (String dirEntry : dirEntries) { | |||
| if (dirEntry.contains("..")) { continue; } | |||
There was a problem hiding this comment.
So hot take, with VF's goals as an analysis tool, our hazards are a bit non-traditional. While there's some concerns about an untrusted archive being able to write outside of the output directory (more difficult to do anything with when the working dir is unknown), the probably more pertinent one would be overwriting class files within the tree to mask the behaviour of the application. You don't want to ignore those entries but between emitting a warning or finding some directory to put them in, there's a few options.
This is probably too far up the abstractions to filter things -- I'm thinking DirectoryResultSaver would be better, basically where files go from being in a jar to being extracted to the outside FS to be a bit more defensive, but there's more work to square the output generated from VF with the way the JVM does class resolution (i.e. what files in the jar are actually loaded when a certain named class/resource is requested), while ensuring that even incorrectly located resources can be decompiled and analyzed.
VF's handling of malformed archives is pretty piecemeal, it deserves a more thorough look through to avoid hazards to operators' systems while still making sure they have visibility into any pecularities the archives they're analyzing might have.
There was a problem hiding this comment.
, but there's more work to square the output generated from VF with the way the JVM does class resolution (i.e. what files in the jar are actually loaded when a certain named class/resource is requested), while ensuring that even incorrectly located resources can be decompiled and analyzed.
Are you saying vineflower does dynamic resolution of java classes and is not only vulnerable to zipslip but loading malicious classes?
There was a problem hiding this comment.
no, i'm referring to the way classloading in the analyzed jar would behave if the jar were to actually be executed
There was a problem hiding this comment.
OK I've gone ahead and move the changes to DirectoryResultSaver instead. Not sure if you wanted to add any additional reporting if you see shenangians here. But I did add a defensive check to make certain any files written indeed start with the expected root path after normalization.
Suggested fix for zipslip when handling jars directly. I didn't check any other locations for similar issues. Also the directory handling seems a bit suspect on lines 135~137 in ContextUnit.java.