The Zip Slip vulnerability – what you need to know

Research by security firm Snyk has revealed that thousands of projects may be affected by a serious vulnerability, one so simple you’ll need to put a cushion on your desk before you read any further (in case of involuntary headdesk injury).
As you might guess from its fancy name – Zip Slip – the vulnerability is all about Zip files.
In a nutshell, attackers can create Zip archives that use path traversal to overwrite important files on affected systems, either destroying them or replacing them with malicious alternatives.
Attackers might use that ability to target files they can execute remotely, such as parts of a website, or files that a computer or user are likely to run anyway, like popular applications or system files.
Zip Slip isn’t a problem with the Zip file format though, it’s a bit of bad programming that’s been repeated over and over and over again, in lots of different projects:

The vulnerability has been found in multiple ecosystems, including JavaScript, Ruby, .NET and Go, but is especially prevalent in Java, where there is no central library offering high level processing of archive (e.g. zip) files. The lack of such a library led to vulnerable code snippets being hand crafted and shared among developer communities such as StackOverflow .
… [it] can affect numerous archive formats, including tar, jar, war, cpio, apk, rar and 7z.

Unfortunately, that coding faux pas has been committed in multiple software libraries, in multiple languages, which has the affect of spreading it far and wide whilst making it harder to fix.
Software libraries are bits of code that are designed to be included in other software projects. So, not only do the vulnerable libraries need to be fixed, but so does the software that uses those libraries. And, of course, a patch is no good until it’s deployed.
Snyk is maintaining lists of affected projects and libraries on GitHub.

Here we go a BWAIN

The bug was responsibly disclosed, meaning that projects known to be vulnerable were told a few months ago so they had to time to create and deploy fixes, before potential attackers were tipped off.
The convenient pause between discovery and disclosure created by responsible behaviour makes marketing and PR departments positively giddy with excitement – it gives them months, months, to turn their researchers’ bug hunting skills into a flashy campaign, or what we like to call a BWAIN (a Bug With An Interesting Name).
So, here it is, in all its unnecessary glory: the fancy logo; the blog post; the, um… other blog post; the video; that useful GitHub post, the whitepaper and the book tour.
OK, I lied about the book tour, sorry.

How it works

An attacker would start by finding a system they suspect might be vulnerable – perhaps a website or online application that allows them to upload zip files.
They create a zip file that contains malicious versions of the files they want to overwrite. They’ll need to be reasonably confident that the files they’re targeting are on the system, and where on the system they’re located.
The Zip file format allows files to be stored with paths that specify where those files should be placed when the archive is unzipped. Crucially, the paths can be relative paths like ../ (in the word of Unix-like operating systems, such as Linux or macOS, dot-dot-slash means “the next directory above the current working directory”).
If an attacker knows the location of both the target file and the current working directory of the application they’re exploiting, they can work out the right relative path to unzip a malicious file right on top of a target file.
Alternatively, they can attempt to target a file even if they don’t know the location of the current working directory simply by adding a whole bunch of extraneous dot-dot-slashes to the path.
Why? Because you can’t traverse any further up the filesystem than the root, /.
So, on a filesystem that’s, let’s say, only six directories deep, these paths all mean the same thing, from anywhere on the filesystem:

../[five or more dot-dot-slashes]etc/passwd
../../../../../../etc/passwd
/etc/passwd.

Now, if you’re in the business of writing code I hope you set out that desk cushion I mentioned at the start. If you didn’t I expect you’ve got a pounding headache by now.
Sure, you’re saying to yourself in lucid moments between desk-head impacts, Zip archives can unzip files to arbitrary places in the filesystem in theory… but you don’t have to let them!
The file paths in the zip archive are user-supplied content and as every self-respecting programmer will tell you, you can’t trust user-supplied content. No matter if it’s the contents of the files themselves or metadata, such as file paths.
Or, as Snyk puts it:

The vulnerability exists when the extraction code omits validation on the file paths in the archive.

They might also question why these poorly-coded applications are running as users that are allowed to overwrite arbitrary files, why they aren’t operating in some kind of sandboxed context – such as a chroot “jail” – that prevents access to other parts of the system, or why it is that important files are vulnerable to being overwritten.

What to do

Panic. Flee. It’s the end of civilisation!
No, not really, it’s just another software bug. It’s got a logo with great production values, it’s interesting, and for some people it’s serious, but, as ever, fix it and move on.
Snyk has posted lists of the projects and libraries with known vulnerabilities on GitHub. Start there and check to see if you’re using vulnerable software – updates are available for most of the items listed so get your systems fixed.
If you maintain software that does its own unzipping you should test it to see if it’s vulnerable. Now might also be a good time to look at whether or not a standard library would be a better option, whether your systems are configured with defence in depth in mind, and if your applications are operating in accordance with the principle of least privilege.