Skip to content
Naked Security Naked Security

The Zip Slip vulnerability – what you need to know

Thousands of projects have been affected by a painful programming lapse.

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

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.


> “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”).”
Also DOS (2.0 and greater), OS/2, and all versions of Windows. (Windows uses “\” instead of “/” but I would expect the unzip routine may do the substitution.)


Windows API calls that take file or directory names accept “/“ as a path separator. (Actually, TBH I can’t be sure that this is always true but I am willing to say it’s almost always true.)
IIRC, the reason DOS and then Windows got stuck with “\” is that Microsoft chose the “/“ character as the prefix for command line qualifiers back before DOS even supported directories. Unices, of course, use “-“ for options and “/“ for directories.
Given that DOS was entirely command-line driven, the need for the command parser to split out options easily from filenames meant that a character other than “/“ was needed for the latter. I guess “\” was the closest choice.


Microsoft didn’t choose it, and it pre-dates DOS, going back to an earlier operating system called CP/M. DOS inherited most of CP/M’s (mis)features for backwards compatibility, and wasn’t created by Microsoft in any case; DOS was originally developed by Seattle Computer Products before Microsoft bought it and immediately licensed it to IBM, thus screwing Seattle Computer Products out of a lucrative licensing deal. But that’s another story.
DOS’s backwards compatibility with CP/M was its main selling point, as Microsoft also sold their version of Unix, called Xenix, for the IBM PC, but it proved unpopular because it couldn’t run WordStar. Many Windows misfeatures (such as drive letters starting from C:) are actually ancient fossils of CP/M which Microsoft had nothing to do with, except for painstakingly preserving them.


Microsoft did choose, in any reasonable sense of the word, to use “/“ as the command option marker, just as it chose “..” for go up a directory in Xenix.
When you adopt an artefact for your product in order to maintain some sort of compatibility, or because you like it, or because you don’t want to hassle of changing it, that is a “choice”.
There are lots of intriguing CP/Misms in DOS that I would consider a “Microsoft choice” to maintain. For example, the fact that zero is pushed on the stack when loading programs so you can exit with a RET, and the INT 20h that was placed at offset zero to make the RET work.
But I don’t think your suggestion that buying QDOS off SCP did *SCP* out of a massive licensing deal is quite right. Intergalactic Digital Research, makers of CP/M, not of QDOS, were as far as I know the only serious challengers for the IBM PC operating system deal that set Microsoft on the trajectory that made it a huge company. IIRC, the SCP company wasn’t trying to license software to IBM, it intendee to sell its own hardware in competition to the forthcoming IBM PC.
The most credible story I have heard of why Microsoft won the deal with IBM is that Gates and Allen immediately signed IBM’s non-disclosure agreement and thus jumped straight into negotiations. But Gary Kildall of Digital Research understandably wanted time to make sure the NDA wouldn’t do him out of business, and that delay left him too far behind in the race to close the deal to catch up.
(There’s a story that Kildall was out flying his plane when IBM showed up to talk and therefore missed out, but that seems unlikely. That alone surely wouldn’t have put him significantly behind Microsoft in the licensing race – if he didn’t care about the NDA he could have signed and been competing directly with Microsoft by the following day.)


On macOS, OS files are protected by Apple’s System Integrity Protection. They can’t be overwritten or modified by users. Not even with Sudo. Even if you login as root. Trying to modify anything in /Applications requires authentication by a user with admin rights.
And waxb was right. macOS is certified Unix. Describing it as “Unix-like” makes as much sense as describing Earth as “planet-like” or describing a Ford Mustang as “car-like.” Or describing “Mark Stockley” as being “like a writer for Sophos.”


There does not appear to be any good reason to allow ../ at the beginning of a file name in a Zip file.
To the best of my belief, CP/M got / as the option prefix from earlier operating systems from DEC, like RT-11, That tradition continued into TOPS-10, TOPS-20, and VMS, surviving in OpenVMS,


+1 to both your points.
I have always assumed, like you, that “/OPTION” came from the DEC universe, and therefore DOS didn’t so much copy CP/M as follow the non-Unix family tradition by copying what had already been copied. (You may need to read that sentence twice. I did, and I wrote it!)
OTOH, “-o” was the Unix way (now augmented by GNU’s “–option” option), and has ultimately flowed back into the Windows world.


Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!