14 ms·

Note that dowloading an app (.exe for windows, or an apple app) and running it, is just as bad. Downloading an installer, and running it, is also insecure. So t

• rakoo 12y ago
  It's interesting to note that we essentially do the same with javascript in the browser, except the user doesn't even know there's some code that is automatically run. The big difference, of course, being that javascript code runs in a sandboxed environment. Maybe we should create some kind of sandboxed sh ? (I actually hardly believe it will ever take on, seeing that so many sites tell you to run not `sh` but `sudo sh`... yeah, sure, why have unprivileged users, we should do everything as root anyway)
  • paulmd 12y ago
    Well, the Unix approach to this is a sandbox application and a shell application, not a sandboxed shell application. Docker attempts many of those tasks. On windows there's Sandboxie, which does more or less what you want as well. It creates a sandbox whose filesystem and internals can be modified by sandboxed applications without affecting the state of the REAL filesystem. Very nice utility for mitigating bad programming - I often use it to run multiple copies of applications that crash or refuse to launch multiple instances.
• youngun 12y ago
  The proper alternative is some sort of lightweight virtualization like Docker, with a proper security policy in place. You can mostly do this today curl <blah> | docker run --rm -t -i ubuntu sh but the containerizing naturally locks down/virtualizes some stuff you might want the script to be doing, like installing stuff locally. I think cleaning this up and making it friendly enough is a solvable UX problem, but I haven't quite solved it yet.
  • vezzy-fnord 12y ago
    I can't tell if you're trolling, but "put some Windex on it" (or in this case, containerization) is hardly a solution, only a bad workaround. The root cause of curl | sh being a broken paradigm to begin with is left unaddressed.
    • youngun 12y ago
      I'm not sure that curl | sh is a "broken paradigm" -- no more broken than than running JavaScript in a browser. The only difference between the two is in the sandboxing. The solution I'm proposing isn't to add Windex, but to cleanly wrap whatever curlpipesh is doing. Make it equivalent to opening a browser tab: interact with it safely, keep what you like, and throw everything away if you don't like the way things look. Curlpipesh can be just like loading a site. We have the technology to do it; we just need to figure out the UX.
• cowabunga 12y ago
  No it's not because MSI packages and EXEs are signed so there is at least a chain of trust. SmartScreen kicks you in the face if it's not "known" by various metrics and it's hard to get around that these days (as someone who just had to get EV certs for their MSI). If you click through that, and you don't know what the source was then you're a muppet. curl + bash is suck and blam the machine. Hope you didn't do a sudo in the last few seconds... http://www.nastybastard.com/funky-super-installer.sh http://www.nastybastard.com/funky-super-installer.sh: #!/bin/bash echo "mwuhahahaha" sudo rm -rf /boot
  • maccard 12y ago
    > No it's not because MSI packages and EXEs are signed Sure, some are. But most software packages that a user is going to download aren't signed.
    • mooreds 12y ago
      Right. And really, who checks signatures? I'm a developer and I don't think I've every checked an md5 signature of a jarfile/gem/package I've downloaded. Nor have I ever been in an environment where that was ever mentioned. (Have mostly worked in small to medium businesses--I imagine that bigger orgs or the defense department might do this.)
    • IvyMike 12y ago
      You might be surprised. I just pulled up Process Explorer, which makes it easy to see which running apps are signed, and the only unsigned things I'm currently running are VLC, Evernote, and some Brother Printer utilities. Things from Google, Intel, MS, VMWare, Spotify, Github, Dropbox, and even f.lux are all signed. Of course YMMV but the trend has been positive. (A little worrisome is that there are two running Broadcom bluetooth apps that have explicitly revoked signatures...I wonder what that's about.)
  • d0mine 12y ago
    > No it's not because MSI packages and EXEs are signed Is it more difficult to provide your own fake exe installer than to middle-man https that curl examples use?
• RKearney 12y ago
  I think one of the larger issues with curl | sh is what could happen in the event of a network outage or early termination on the connection. For example, if you're downloading a script that has a line like this rm -rf ~/.tmp/foo/bar But the HTTP connection was lost before the entire file was downloaded and `rm -rf ~` was the end of one packet and `/.tmp/foo/bar` was the contents of the other (lost) packet, you're screwed. The incomplete script will still be piped to sh and it's game over.
  • michaelmior 12y ago
    In at least some of those cases, I would expect curl to exit with an error and the pipeline to abort.
    • LeonidasXIV 12y ago
      Some scripts also detect this and are written so that there is no code executed before the file is not complete. Of course, that's a minority.
      • michaelmior 12y ago
        Definitely including a checksum and validating that before executing would be ideal.
      • dTal 12y ago
        To elaborate, this is quite easy: you wrap the entire contents of the script into a function definition, then call the function as the last line.
    • mikeash 12y ago
      All bash sees are bytes coming in on stdin, and eventually an EOF. It neither knows nor cares what caused the EOF.
      • michaelmior 12y ago
        Sure, but if the server response is not pipelined (as is probably often the case), then bash should never see anything.
• earthrise 12y ago
  I've written down some general principles we should follow, but any reasonable implementation of them seems pretty far off: https://defuse.ca/triangle-of-secure-code-delivery.htm https://defuse.ca/triangle-of-secure-code-delivery.htm tl;dr: (1) Reproducible builds, (2) Make sure everyone is getting the same thing (to detect targeted attacks) and (3) Cryptographic signing. Package managers and appstores are the best we have right now, but they're missing (1) and (2). In the meantime, offering a pgp-signed installer file is a lot better than curl | sh.
  • sarciszewski 12y ago
    I'm really surprised this hasn't gotten more attention from the commenters here. :( ^~ To the people scrolling by at 70 mph: READ THIS
  • d0mine 12y ago
    `curl | sh` is protected by a ssl certificate issued by CA that my system trusts. "pgp-signed installer file" is protected by a key from a stranger. Both are insecure. Could you enumerate several points that show "pgp-signed installer file is __a lot better__ than curl | sh" ?
    • earthrise 12y ago
      Say we're trying to download the PHP source code from php.net. If all that's protecting us is SSL, then if an adversary compromises the php.net servers (happens all the time, and actually has happened to PHP), they can immediately replace all the downloads with backdoored copies. Whereas with a PGP signature, the key can be stored off-line (even on an air-gapped system), so that even if the web server is compromised, the adversary can't make me believe the file is legit. PGP can also be used in a trust-on-first-use manner. Get the public key once over an insecure channel, and if the attacker missed that single opportunity, you're safe until the key changes. With SSL, on the other hand, you're at risk every single time you make a connection, because any of hundreds of CAs has the power to sign that certificate, and as above, you have to assume the web server isn't compromised. Another reason PGP is important is mirroring. Big F/OSS projects let others' volunteer mirrors. Even if those mirrors support SSL and the transport from the author to the mirror is encrypted, there's absolutely no guarantee that the mirrors themselves are not malicious. The mirrors could be backdooring their own files. The fact that you have an SSL connection to the mirror doesn't do anything to prevent this. But with PGP signatures, you're assured the files come from the software's developer, and haven't been tampered with by the mirror. So the difference is: SSL secures the connection between your browser and the web server. PGP ensures you're getting the file the software developer intended you to get. It's a semantic difference. I'd also argue hard against `curl | sh` for (assuming it exists) the psychological effect of teaching users that it's OK to pipe random things from the web into sh.
• peterwwillis 12y ago
  If you're really paranoid, download the MD5 and PGP keys of the application release's source code tarball from the author's website using SSL. Then unpack the source (being careful to use a sandbox, because an exploit in gzip/tar/etc might be bad) and examine the source code for any unexplained or dangerous behavior. Then compile and install it using a non-root user. Personally, i'm totally comfortable with the idea of someone owning my box. The files I care about are backed up offline, I don't have many secrets, and the only accounts that would affect my life in general have passphrases, pins and multiple-factor auth tied to them. The worst thing someone could maybe do is impersonate me and cause havoc using my accounts, but I really don't see anyone having cause to do that. Anyway, I don't sweat it. If you trust your distro, just verify the PGP keys of packages you download before installing, which is mostly automatic for most modern OSes.
  • sarciszewski 12y ago
    """ Personally, i'm totally comfortable with the idea of someone owning my box. The files I care about are backed up offline, I don't have many secrets, and the only accounts that would affect my life in general have passphrases, pins and multiple-factor auth tied to them. The worst thing someone could maybe do is impersonate me and cause havoc using my accounts, but I really don't see anyone having cause to do that. Anyway, I don't sweat it. """ Are you trolling? This sounds like the same sort of argument from the "I don't have anything to hide. NSA/GCHQ can spy on me all they want" camp.
    • peterwwillis 12y ago
      Uh, it's not an argument, it's my personal feelings and my personal opinions. It's OK if you don't feel the same way.
      • sarciszewski 12y ago
        I look forward to you getting 0wned then. Just my personal feelings and personal opinions. :)
  • phaer 12y ago
• paulmd 12y ago
  I get a little bit of heartburn over running arbitrary scripts downloaded from internet websites. The easiest alternative is to run "curl <blah>", download the script, take a peek at the source, and only THEN follow up with the sh. I mean, you're probably going to see a bunch of "download and install" commands, so you don't get much reassurance if you're worried that one of THOSE might be compromised too. But that's a problem inherent to unsigned internet installer scripts. At least you've somewhat mitigated the possibility that it's dumping your private SSH key to a server somewhere or some other blatantly malicious command. On the other hand, the script might also include appropriate SHA1 verification commands, or be setting up a repository in a package manager, in which case it's pretty reasonable to trust the script.
  • sarciszewski 12y ago
    My preferred hypothetical installer Trojan method is to make it append a value to ~/.ssh/authorized_keys and then ping a C&C server with the current username and IP ;)
    • idlewan 12y ago
      You would still have to hope that sshd is enabled and accepting connections (which by default it shouldn't, at least on end-user distros).
      • sarciszewski 12y ago
        True. I've mostly seen PHP devs using this to deploy composer onto staging and production servers, so it would work on them. ;)
• Igglyboo 12y ago
  Trust is really the only solution, we as developers might be able to inspect some code before we run it but if it is sufficiently complex we could spend months auditing it. Even worse for the non-technical users that can't tell a hello world from a keylogger, there really is no solution other than some trust based system.
  • dllthomas 12y ago
    Trust is a partial solution. You need to be able to make sure that you're only trusting those who are trustworthy. A part of that is assessment of trustworthiness, and a part is making sure you're aware who you're trusting (probably allowing delegation).
• rpdillon 12y ago
  "appstores such as found on ios and android" are actually simpler versions of Linux package management, which fits very well with open-source. Packages are retrieved over HTTPS and signed by maintainers/authors. For distros like Lunar or Gentoo, the source is retrieved in a similar fashion and compiled locally.
• heavenlyhash 12y ago
  I agree, it is difficult to find a proper alternative. App stores do have some advantages here, today. It's also true that they don't well fit the model for open source. App stores define some root of trust for signing, but just like the CA model for HTTPS certificates, there are issues with that. App stores also bring a host of issues with user freedom. (Even the free ones can have this effect unintentionally: what percent of your coworkers know how to manage apt pinning? If one person on ubuntu 10.04 has an working, installed package, and wants to hand that exact (known working) version of it to a friend on ubuntu 12.04, can they do it?) PGP signed binaries are one major step in the right direction. More friendly tools and popularized workflows for this would help a lot of people avoid major moments of vulnerability. PGP (or any other signing system) also leave an interesting challenge, which is what to do in the case of key compromise. Revocation is hard. And say you want an audit log of all prior releases: what can you do? We're all used to git having an immutable log of history by hash chaining, at this point. Is it time to start using systems like that to keep an auditable log of software releases, as well? I've been working on something called "mdm" [1] that attempts to do an auditable, immutable chain of releases like this. It was originally designed to be a dependency manager for (arbitrary, language-agnostic, any binaries) software development needs, but I wonder if something like this is what the software distribution world needs to start evolving towards as well. Imagine if your end users could all verify that they have the same hash... and the same picture of historic releases from the same author, and the same picture of if the releaser's signing key changed, and so on. I'd love to hear other thoughts on how hash chains and signatures can be made to intersect to tell the broadest story. The challenges are very real here. --- [1] https://github.com/polydawn/mdm/ https://github.com/polydawn/mdm/