The “Zip Slip” vulnerability

Sometimes my reaction to a story is “Wait, are they saying someone was that dumb? … No one could be that dumb! … Oh, gods, they were that dumb!” Naked Security’s account of the Zip Slip vulnerability is just such a story.

The article starts with a fair warning that the vulnerability is “so simple you’ll need to put a cushion on your desk before you read any further (in case of involuntary headdesk injury).” It explains that because of the coding mistake called “Zip Slip,” “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.” This is where I started to suspect.

The vulnerability isn’t in the Zip format as such, but in bad coding found in some of the zillion ad hoc pieces of software written to unpack Zip files. Have you figured it out yet? I’ll put the cut here to give you a chance to think…

Yes, it is that dumb

Yes, that’s really what a bunch of coders have done They didn’t check if the path goes outside the directory you’re unzipping to. I refrained from banging my head against the desk, mostly because I’m writing this in a library where they don’t like loud noises and screams of anguish. If the file path starts with “../”, these pieces of … er, code, will gladly follow the path wherever it leads.

Here’s a list of software that has the Zip Slip problem. I was hoping it would all be obscure libraries I’d never heard of, but I see Oracle’s, Maven, Hadoop, and Apache’s commons-compress in the list. Most of them have had the problem fixed in a recent release.

The issue could affect any files in the Zip format. This includes not only files with the extension .ZIP, but JAR, Open Document, Office Open XML, and EPUB.

In some cases, the problem is that only a low-level library is provided, and people writing code on top of it assume it provides protections which it doesn’t. This is what’s happening with A sensible-looking loop through the results of a getEntries() call leaves the code wide open to paths outside the target directory.

What to do

Nothing bad will happen unless you open a malicious Zip file, but a lot of people assume that opening one is safe as long as you don’t open the files it contains. It’s never a good idea to treat a file from a potentially malicious source as safe. I’m not even 100% sure about text files.

Keeping your software up to date is important. I don’t know how it took so long for people to think about this issue, but now that it’s been pointed out, it’s an easy fix. If you’re using someone’s (your own?) ad hoc code, you’d better take a look at it to make sure it performs sanity checks on the file path.

Comments are closed.