Tests fail with 'possible traversal attack'

[craftyguy]

I'm trying to build/test unshield on Alpine Linux (with musl libc), and all of the bundled tests fail. I've included the output from running the following manually (as found in the baldur gate test sh script):

./build/src/unshield -D 3 -d extract1 x data1.cab

Output:

unshield_fail.log

[twogood]

Seems we use some GNU extension to realpath that probably is not available in Alpine:

  /* use GNU extension to return non-existing files to real_output_directory */
  realpath(output_directory, real_output_directory);
  realpath(filename, real_filename);
  if (real_filename == NULL || strncmp(real_filename,
                                       real_output_directory,
                                       strlen(real_output_directory)) != 0)
  {
    fprintf(stderr, "\n\nExtraction failed.\n");
    fprintf(stderr, "Possible directory traversal attack for: %s\n", filename);
    fprintf(stderr, "To be placed at: %s\n\n", real_filename);
    success = false;
    goto exit;
  }

GNU extensions
If the call fails with either EACCES or ENOENT and resolved_path is not NULL, then the prefix of path that is not readable or does not exist is returned in resolved_path.

[twogood]

Please try with the latest master @craftyguy !

[craftyguy]

@twogood works great, thanks for the quick fix!

I'm packaging this for Alpine Linux, is there any chance you could tag a new release so I can package a specific release rather than 'master'?

[craftyguy]

Oof, spoke too soon. One test is failing and referencing #42

/home/pmos/build/src/twogood-unshield-f097b07 # UNSHIELD=$(pwd)/build/src/unshield bash run-tests.sh
Running test ./test/v0/wireplay.sh...succeeded
Running test ./test/v0/the-feeble-files-spanish.sh...succeeded
Running test ./test/v0/baldurs_gate_patch_v1_1_4315_international.sh...succeeded
Running test ./test/v0/avigomanager.sh...succeeded
Running test ./test/v5/CVE-2015-1386/CVE-2015-1386.sh...Cabinet: /home/pmos/build/src/twogood-unshield-f097b07/test/v5/CVE-2015-1386/data1.cab
  extracting: extract1/Bovine_Files/../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../tmp/moo
 --------  -------
          1 files
unshield vulnerable to CVE-2015-1386
See https://github.com/twogood/unshield/issues/42
FAILED with code 2

That issue seems to indicate this was resolved for debian on some earlier version of unshield, but since it has to do with some traversal stuff maybe it's not fully resolved for Alpine/musl libc?

[craftyguy]

FWIW, realpath does appear to be in POSIX (and therefore supported by musl): https://pubs.opengroup.org/onlinepubs/9699919799/

A simple 'hello world' compiles/runs with musl:

#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
int main(void) {
    char b[PATH_MAX];
    char *r = realpath("test.c", b);
    if (r) {
        printf("%s.\n", b);
    } else {
        perror("realpath");
        exit(EXIT_FAILURE);
    }
    return 0;
}

~ $ gcc test.c -o test
~ $ ldd test
        /lib/ld-musl-aarch64.so.1 (0)
        libc.musl-aarch64.so.1 => /lib/ld-musl-aarch64.so.1 (0)
~ $ ./test
/home/pmos/test.c.

[twogood]

Yes, realpath() is POSIX but there is a GNU extension to support files that do not exist, see bottom of my comment #99 (comment)

[craftyguy]

@twogood oops, I missed that somehow when I first read your comment, sorry about that!

So there must be something else causing that test to fail when built with musl?

[twogood]

Well on master I disabled the path traversal check unless you are on GNU libc. "Damned if you, damned if you don't..." ;)

[twogood]

I will create a proper release when we have sorted this out. I want a path traversal check but I don't want to reimplement realpath :)

[craftyguy]

I see. There was a patch submitted for #42 that doesn't appear to rely on GNU extensions to realpath (1027922), but comment in that merge request seems to suggest that approach doesn't work. I don't know enough about this stuff to be able to help much, and definitely don't want to re-introduce a CVE into this project by recommending the wrong thing :(

[twogood]

Unfortunately it still seems to rely on the GNU extension to realpath but this must have been an issue on Alpine for much bigger projects than unshield...

[craftyguy]

@twogood I thought about this some more, and talked with some folks on the #musl IRC channel to see what they thought such a check would look like ¹

Are there any cases where having a '..' in the path for an object in a .cab is valid? If there's no case for that, then it seems like 1) checking that the directory to extract into is writable for the current user, and 2) that the file path of the file to extract does not contain any '..'

¹ A (somewhat biased) response was along the lines of "using realpath this way is clearly not the intended purpose of realpath, in glibc or otherwise" (paraphrasing is mine), but I'd rather focus on solving the issue and not derailing the discussion to focus on that bit :)