Loose .zips sink chips: How poisoned archives can hack your computer

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 …

[Jacob's Elevator]

Neurosis ... Eternal chuffin' Neurosis.

That will be the legacy of the interweb.

[Waseem Alkurdi]

Another deja vu?

Isn't that the zip bomb of the early noughties?

[davidp231]

Re: Another deja vu?

Or tar bombs in *nix-land from before that.

[Rob Crawford]

Re: Another deja vu?

I remember zip bombs from the very early 90s, it really is annoying that nobody seems to learn.

[doublelayer]

Re: Another deja vu?

No, this isn't a zip bomb. Those are zip files or other archive files that decompress to a bunch of data. Sometimes they are also recursive so they decompress to multiple copies of themselves. The goal of an archive bomb is making the system run out of resources: memory or disk if the zips expand to a lot of data, processor if they are recursive. Thus, the program running them will crash or run into problems.

This file wouldn't cause a crash. Instead, it would write files to a location that isn't planned. For example, imagine that you unzip a file on windows in c:\Users\me\extract. Normally, all the contents will be under that folder. The zip file, however, can be constructed so that it also decompresses to c:\windows\system32\explorer.exe. This overwrites it with a different file that contains malware, and now running the formerly trusted explorer process will infect the system. The zip is not meant to crash the system, but to infect it.

[jake]

Re: Another deja vu?

All malicious archive files were known as "bombs" back in the day, regardless of payload intent.

[davidp231]

Re: Another deja vu?

"The zip file, however, can be constructed so that it also decompresses to c:\windows\system32\explorer.exe."

So long as the file isn't in use, of course...which it will be, unless you're using something else as SHELL. Unless it somehow manages to terminate the process when it reaches that point in the archive, overwrite it and when the shell reloads - that's when your'e in for a world of pain.

[stiine]

Re: Another deja vu?

It's not that they didn't learn, they just don't remember.

[Alistair]

unpack a compressed file and overwrite system files....

*sigh*

I have a ruby on rails app that has yet to be burnt to the ground. When I inherited it, it was running as root. It took me all of 20 minutes to fix it to run as other than root. Oddly, its using one of these libraries, and it cannot now write to system space. can bugger up it's own install but not the system.

Mine's the one with the flame thrower in the backpack. Looks like I'ma needin that ....

[Waseem Alkurdi]

My knowledge of Ruby on Rails is less than cursory, but can't you use (un)zip, the Info-ZIP binaries on any regular Linux install?

[Alistair]

Technically one can use the system installed zip binaries. Developers with attitude however frequently decide to do things that they *think* are better. I've now got someone looking at moving this to something far less flakey.

[teknopaul]

Re: xz and bzip2...

good point, how could xz be subject to path based bugs? perhaps one for tips & corrections?

[Anonymous Coward]

Well...just like the article says.

If you're going to run "unzip" as an administrator then you're very careless.

[Waseem Alkurdi]

What if you're already logged in as root (don't tell me about the security risks, I don't rm -Rf / by accident) and want to unzip a file? Should I su - guest just to unzip a file?

[Anonymous Coward]

(don't tell me about the security risks, I don't rm -Rf / by accident)

Well, good for you. Most people make mistakes from time to time.

I suppose you also don't ever run shell scripts written by other people? Or launch software you didn't compile yourself?

[Outer mongolian custard monster from outer space (honest)]

*Sigh*, I tested this as soon as THN broke it on twitter, its just for libraries.

Untarring and unzipping as root is dumb (I did it on a throwaway vm so you don't have to...) but linux command line zip and tar are both patched in the shell anyway, since the 1990's for tar and somewhere around 2006 for zip. I didn't even bother testing the other variants. It really is the old 2006 path recursive attack that some libraries were never fixed for still in use, except it has a logo, and people running round twitter trying to make a "name" for themselves in the security community to get hired.

root@testbox:/home/testuser/zip-slip-vulnerability/archives# tar -xvf zip-slip.tar

good.txt

tar: Removing leading `../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../' from member names

tar: ../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../tmp/evil.txt: Member name contains '..'

tar: Exiting with failure status due to previous errors

root@testbox:/home/testuser/zip-slip-vulnerability/archives# ls -la *evil*

ls: cannot access '*evil*': No such file or directory

root@testbox:/home/testuser/zip-slip-vulnerability/archives#

root@testbox:/home/testuser/zip-slip-vulnerability/archives# unzip zip-slip.zip

Archive: zip-slip.zip

extracting: good.txt

warning: skipped "../" path component(s) in ../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../tmp/evil.txt

extracting: tmp/evil.txt

root@testbox:/home/testuser/zip-slip-vulnerability/archives# ls -lR tmp

tmp:

total 4

-rw-r--r-- 1 root root 20 Apr 15 22:04 evil.txt

root@testbox:/home/testuser/zip-slip-vulnerability/archives#

[Outer mongolian custard monster from outer space (honest)]

And holy crap el reg? 5 captcha's just to post a comment with actual facts in it? Do you even want people to post here still?

[Doctor Syntax]

If you're going to run "unzip" as an administrator then you're very careless.

Or you're doing it deliberately. It's been a way to install or update stuff since forever. If you didn't intend to give an absolute path when you created your tar it's also been a way to make a balls-up for just as long. I'm sure somebody would have a "Who, me?" story on that.

[jake]

70's on line 1 again.

HEY, YOU KIDS! WHO SAID YOU COULD RESURRECT OUR VULNERABILITY? THERE'S A REASON WE KILLED THAT ONE OFF DECADES AGO!

Honestly, you try to teach 'em, you try to bring 'em up right, but will they listen? No. Of course not. What do us grey haired old fuddy-duddies know about code testing?

[Claptrap314]

This is a #metoo kind of thing

Last week, we had it in git. Now this. Sigh.

[Jan 0]

Great headline!

Thanks Shaun.

[Missing Semicolon]

What about 7-zip?

If that's borked too, truly the end of days is here....

[Charles 9]

Re: What about 7-zip?

Only if it's elevated. Normally it runs as a standard user so a write to a privileged area will trigger alerts.

[Nick Kew]

And in other news ...

make -n install shows you where stuff will get installed before you allow anything potentially risky to happen.

I always thought it was just normal good practice (i.e. obvious) to sandbox the unpacking of anything short of trusted and familiar?

[jake]

Re: And in other news ...

I would say ESPECIALLY the trusted and familiar! I don't know anyone I'm more trustworthy with than myself, and I certainly know me better than I know anybody else ... and yet I know damn day well that I make misteaks!

Don't grill me on that ...

[Claptrap314]

Re: And in other news ...

make -n has been useless since autoconf. I hear chroot still works, though.

[stephanh]

Re: And in other news ...

"I hear chroot still works, though."

Probably easier today to use a Docker container.

[DropBear]

Oh FFS...

Jan. 1st - "insecure code [...] fixes [...] pushed out to the public so people can install them and be safe." You were unsafe before. You install updates. You are now safe.

Jan. 8th - "insecure code [...] fixes [...] pushed out to the public so people can install them and be safe." You were unsafe before. You install updates. You are now safe.

Jan. 15th - "insecure code [...] fixes [...] pushed out to the public so people can install them and be safe." You were unsafe before. You install updates. You are now safe.

Jan. 22nd - "insecure code [...] fixes [...] pushed out to the public so people can install them and be safe." You were unsafe before. You install updates. You are now safe.

...we keep using that word, "safe". I don't think it means what we seem to think it means.

[Alistair]

Re: Oh FFS...

@DropBear:

Sadly, we're also still starting land wars in Asia.