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.
If we are to be precise, xz and bz2 ar not archives. They compress individual files. They are, however, usually paired with tar or cpio.
They are not mentioned in any of the links so the use in this post probably means xz or bz2 compressed tar or cpio archives.
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.
puny little You Mans,
This is just a mere small demonstration of our capabilities.
Hu have not even found half of the exploits that are available.
Prepare your time
All your base are belong to us
This is not common in any actual *archive* software. Where they were finding it was places where people just rolled their own quickly ("it's only like 20 lines of code, what could go wrong?")
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.
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."
Ok - so here is rule number 1. Do not unpack files without checking. Rule number 2. Do not unpack files as root. Rule 3. Reread rule 1 and 2.
There is no alternative. This examples is kinda stupid. What if you zip a symlink that links to ../../../../../../../ and call it "special" and in "special" you have "bin/sh" - unpacking will not violate anything until the OS is asked to resolve the symlink.
The take home message is that this kind of validation is not the realm of the unpacking software. Configuring a system with proper privilegse is a required step. Barring that, the user expect to get owned and have thei content trashed.
Enough said. Next story please.
Just ask the millions of thousands of people slaughtered by the foreign interventions she, Bill and their ilk cooked up. Apparently genocide is less offensive to you than some unsavory comments by an old man.
If you expand a path that includes traversals (like "../") into the actual absolute path and then
(a) fail to check the validity of the resulting expanded path, or
(b) fail to verify that the resulting complete file name and path is not already in use,
then you have COMPLETELY FAILED TO "VALIDATE USER INPUT"
I chalk problems like this up to incompetent "coders" pasting together a bunch of "free" libraries they found on the internet with the software equivalent of chewing gum, used band-aids, and spit. Such would-be programmers have no clue about how "their" "program" actually works, cannot properly test/debug it, and cannot fix it when users find a problem.
This is bone-head level incompetence. Buffer overruns and filesystem path expansion hacks are some of the oldest stupid vulnerabilities there are - If they are in code that is less than 25 years old, then a moron at a keyboard (who is better suited to ask "you want fies with that?") is to blame.
Ambient Authority, the design flaw underlying most "modern" operating systems, strikes again.
Don't you have an election somewhere that you're supposed to be fixing?
Il n'y a pas de Planet B.
- 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 ]
Any half decent MAC will prevent this issue.
Da!
I said all I have to say here (& you RAN as you stalk me by unidentifiable anonymous posts or impersonate me) https://yro.slashdot.org/comments.pl?sid=12190270&cid=56731102/ you disgusting little punk.
APK
P.S.=> One day, I'll find out WHO & WHERE you are & fuck you up... apk
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.
"That's exactly right" - Milton T Pike
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.
Isn't this the way zip packages are supposed to work?
It's kinda like saying that downloading an .exe and running it can result in bad shit happening. Well, duh. That's why you don't do it unless you know and trust the .exe file and the downloads source.