Fix directory traversal in bsdcpio

[ghedo]

This fixes a directory traversal issue in the cpio tool that was originally reported by Alexander Cherepanov.

The patch adds a new option ARCHIVE_EXTRACT_SECURE_NOABSOLUTEPATHS that disables extraction of absolute paths. It also provides a test case and updates the documentation.

Note that I only implemented this for posix, because I don't have a windows machine to test this on.

Also, a CVE id was requested for this issue but none has been assigned yet.

[kientzle]

You should include a check here to verify that /tmp/abs was actually created in this case. I think the following is sufficient:

assert_file_exists("/tmp/abs")

It would be better, of course, to generate a filename that does not exist before this test, then check that it does not exist after this test.

[kientzle]

This is a nice start. The tests need a few more checks to verify that the security check really does prevent or not prevent the file creation. (Right now, you're just verifying that the security check returns an error.)

[ghedo]

Should be fixed now. I use assertFileExists("/tmp/abs"), then unlink("/tmp/abs") in the test without the flag, and assertFileNotExists("/tmp/abs") in the one with the flag.

Not sure if using unlink() is ok though.

[kientzle]

If we're going to use a fixed name, we need to use one that is reasonably certain to not interfere with any other user of /tmp. How about
/tmp/libarchive_test-test_write_disk_secure-absolute_path.tmp

[ghedo]

Sounds good to me. I just updated the PR.

[kientzle]

Thank you. I'll merge this now; we will of course need to update this logic soon to identify absolute paths on Windows as well.

[attritionorg]

CVE-2015-2304 was assigned for this at some point.OSVDB 117148 corresponds to this entry as well.

[melvyn-sopacua]

I'm wondering if this fix is correct for the cpio -dumpl <abspath> case, used in quite a few scripts (FreeBSD ports's macro ${COPY_TREE_SHARE} as a prime example) to hardlink something from place a to b, falling back top copy if no hardlink is possible.

The error is thrown on the path that is the combination of the argument and the relative path provided by stdin. So if input path is verified to be relative and abspath argument is identical to it's realpath, there is no issue and the error thrown is a false positive. Please correct me if I'm missing something here.