Potential CVE?

[ibodrov]

A recently found vulnerability was fixed in another project similar to this one. It might potentially affect a similar implementation in PodOperationsImpl.

Ironically, it prints out the normalized path into stdout, but uses the original (potentially dangerous) path.

[manusa]

I finally managed to create a reproducer for this CVE.

I first created a Container Image which contains a poisoned tar binary.
Whenever this binary is executed with arguments -cf - [fileName] it will produce a tar with a single file containing a forged tar entry ../youve-been-hacked.

The following gist contains a JBang script that will exploit the vulnerability.
You should be able to invoke the script by running the following in your command line:

$ jbang https://gist.github.com/manusa/94b91311ee9af7267a8a7f659f594a82

This is an excerpt of the script:

final Path targetDirectory = Paths.get("", "target-directory");
targetDirectory.toFile().mkdirs();
kc.pods().withName(podName).dir("/var/lib").copy(targetDirectory);

According to this script, the contents of the container's /var/lib directory should be copied to the local ./target-directory.

However, when the script is executed, a file youve-been-hacked is created in the parent directory (since the tar entry is defined as ../youve-been-hacked, thus exploiting the exposed vulnerability).

If you were to extract this intermediate tar using the standard tar command, you would be greeted with the following error:

tar: Removing leading `../' from member names
tar: ../youve-been-hacked: Member name contains '..'
tar: Exiting with failure status due to previous errors

You would need to force the extraction using the -P/--absolute-names (don't strip leading '/'s from file names)
flag

[manusa]

Releases with fix:

• 5.1.0
• 5.0.2
• 4.13.2
• 4.11.2
• 4.7.2