Video Booby-trapped archive files can exploit vulnerabilities in a swath of software to overwrite documents and data elsewhere on a computer's file system – and potentially execute malicious code.

Specifically, the flaws, dubbed "Zip Slip" by its discoverers at security outfit Snyk, are path traversals that can potentially be exploited to perform arbitrary code execution attacks. It affects certain tools that handle .zip, .tar, .war, .cpio, and .7z formats.

The programming blunders are present in developer libraries made by Apache, Oracle, and others, which are used by thousands of applications. Patches are available for the libraries, and products and programs using the insecure code should be updated to bring in the fixes and then pushed out to the public so people can install them and be safe.

Opening a maliciously crafted archive using a vulnerable application could lead to data being overwritten, and commands executed that bring in and install further malware.

The bugs, according to Snyk, lie in code that unpacks compressed archives, hence the "Zip Slip" title. When software does not properly check and sanitize file names within the archive, attackers can set the destination path for an unpacked file to an existing folder or file elsewhere on a system. When that file is extracted, it will overwrite the existing data in that same path.

In practice, this could allow an attacker to get a file into a system directory or other area it would normally not have access. That would allow a miscreant to inject arbitrary commands in script files, or change executables, to do nefarious things. Of course, it depends on the level of access permissions the unarchiver has – unpacking files as an administrator is dangerous in this case as it could allow any data to be overwritten.

Here's a video demonstrating the flaw:

Youtube Video

"The premise of the directory traversal vulnerability is that an attacker can gain access to parts of the file system outside of the target folder in which they should reside," Snyk said in its summary of the bug.

"This could happen on both the server side or client side and can lead to sensitive files being written, or overwritten. If an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue."

Unfortunately, the failure to check file names is rather common, and as a result multiple widely used libraries are vulnerable. Snyk said it has been coordinating with vendors to patch their tools.

Here's an example of potentially vulnerable Java code to look out for:

1: Enumeration<ZipEntry>entries = zip.getEntries(); 2: while(entries.hasMoreElements()){ 3: ZipEntry e = entries.nextElement(); 4: File f = new File(dir, e.getName()); 5: InputStream input = zip.getInputStream(e); 6: IOUtils.copy(input, write(f)); 7: }

Among the products and services using libraries that contain the flaw are Google Cloud platform, Oracle's suite of software, Amazon CodePipeline, IBM's DataPower, Alibaba JStorm, and Twitter Heron.

"It affects thousands of projects across many ecosystems but is especially prevalent in Java, where there is no central library offering high level processing of archive (e.g. zip) files," Team Snyk explained.

"This leads to vulnerable code snippets being hand crafted and shared among developer communities."

Among the vulnerable developer libraries were Oracle's java.util.zip, Apache commons-compress (patched in version 1.17), Apache ant (patched in version 1.9.12), and Codehaus Plexus-archiver (patched in version 3.6.0). JavaScript package manager npm has already patched both Unzipper (in version 0.8.13) and Adm-zip (version 0.4.9).

Over in .NET land, the bug was only found in NuGet's DotNetZip (the core .NET library is not vulnerable). While DotNetZip itself remains vulnerable, the bug was patched for DotNetZip.Semverd (in version 1.11.0) and in SharpCompress (0.21.0).

Python and Ruby libraries do not have any vulnerable components, while Go's mholt archiver tool was vulnerable and has been patched on GitHub.

Team Snyk said any developer who uses one of the vulnerable libraries should update their code to use the latest patched version, where available, and make sure users are updated, too – and also check their own code to make sure file names and paths are validated before extraction. ®