fastjar contains the following security problem: When a JAR archive is extracted with filenames with "../" inside, it can extract files outside of the current directory (a so called directory traversal). Unconspicious users unpacking such files could overwrite their own files, or even system files when being root. I am attaching a sample "cups.jar" from an earlier CUPS tarball, which exposes this problem.
Created attachment 11868 [details] cups.jar sample file with ../ paths inside.
Created attachment 11869 [details] fix.patch i would propose this patch to fix this problem.
Confirmed.
Created attachment 11870 [details] different fix
I have applied the 2nd fix to the upstream (savannah) fastjar CVS.
Fastjar no longer is included with GCC so closing as will not fix.
Well... maybe the RM has an opinion on this.
yes, this could still be fixed for release branches ;)
There's certainly no reason not to fix this on release branches.
Reopening then...
...to assign myself.
The patch in #4 is insufficient. Consider paths like ././../.././../etc/passwd which satisfies the depth tests, yet clearly escapes the current dir tree. Another question is about symlinks, if there is a foo -> ../../../../etc symlink in the current tree, then I believe fastjar will happily store foo/passwd into ../../../../etc/passwd, is that something that can be declared as user's fault or should fastjar always canonicalize the filename and don't allow leaving the current directory tree in any way?
CVE-2006-3619
Indeed. Now for symlinks it is only a problem if you can package them like foo -> ../../ foo/x i.e., if uncompressing a zip archive can _create_ symlinks. On unix it can, but it seems to "defer" their creation. Archive: ../t.zip creating: b/ linking: b/foo -> ../ checkdir error: b/foo exists but is not directory unable to process b/foo/bar. finishing deferred symbolic links: b/foo -> ../
Created attachment 11904 [details] fixed patch Version of the patch that doesn't count "." parts in the filename as depth.
Subject: Bug 28359 Author: doko Date: Sat Aug 5 09:27:11 2006 New Revision: 115945 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115945 Log: PR fastjar/28359 / CVE-2006-3619 2006-07-17 Richard Guenther <rguenther@suse.de> * jartool.c (extract_jar): Do not allow directory traversal to parents of the extraction root. Modified: branches/gcc-4_1-branch/fastjar/ChangeLog branches/gcc-4_1-branch/fastjar/jartool.c
Subject: Bug 28359 Author: doko Date: Sat Aug 5 09:43:02 2006 New Revision: 115946 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115946 Log: PR fastjar/28359 / CVE-2006-3619 2006-07-17 Richard Guenther <rguenther@suse.de> * jartool.c (extract_jar): Do not allow directory traversal to parents of the extraction root. Modified: branches/gcc-4_0-branch/fastjar/ChangeLog branches/gcc-4_0-branch/fastjar/jartool.c
I think this is now fixed.
Created attachment 20874 [details] CVE-2010-0831.patch Just for the record, the patch that went in leaves fastjar still vulnerable. The main issue is that tmp_buff isn't the current directory component, but current directory component with all previous directory component, so the .. and . tests will match only for the first component. https://launchpad.net/bugs/540575 has some patch, but it is very ugly and inefficient.
Jakubs patch looks good to me.