Hi all
while looking into https://bz.apache.org/bugzilla/show_bug.cgi?id=62502
I realized that I had a false expectation of what normalize would do in
a certain edge case.
If you feed into it a path with more "../" segments than can be
travelled up, like
FileUtils.normalize("/tmp/dest/../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../Temp/evil.txt")
it will realize it would go outside of the file system root and returns
a new File instance with the original path. I'm not sure what I had
expected (an exception maybe) but this is now what I had assumed, my
fault.
Then isLeadingPath calls normalize for both its arguments and ends up
seeing "/tmp/dest/" is a prefix of
"/tmp/dest/../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../Temp/evil.txt"
and unzip allows the file to escape.
It seems to depend on the OS what it makes of the path, on Linux I
receive an exception but apparently Windows just swallows the excess ../
segments.
I'm not 100% sure how to fix this properly.
Is normalize doing the right thing? If so, we need to fix isLeadingPath
for example by simply always returning false if either normalized path
contains "../" segments (because that means the path cannot exist on
disk at all).
Or should the behavior of normalize change? This unit test snippet
assertEquals("will not go outside FS root (but will not throw an
exception either)",
new File(localize("/1/../../b")),
FILE_UTILS.normalize(localize("/1/../../b")));
makes me think we better leave it as is as it seems to be by design (and
I just have forgotten about it).
In either case, once we agree on the fix I propose to cut new releases
immediately.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
