11 ms·

Detecting the use of “curl | bash” server side (2016)

373 points by pabs3 4y ago

encryptluks2 4y ago
I get so annoyed at the amount of Linux tools suggesting to install something using this method rather than focusing on package management inclusion. Even more so when they try to request sudo access.
- worldsavior 4y ago
  It's sometimes preferred because package repositories don't always include the updated version of the program, and saves the tedious work on uploading to every package repository like Arch Linux or Debian's.
- Semaphor 4y ago
  A common reply is that all the different package managements are even more work for someone already maintaining a project.
  - geggam 4y ago
    Funny thing about work. It is usually something people dont want to do and this is why its incentivized with money.
    - serf 4y ago
      I mean, you're right -- but security and maintainability aside doesn't it feel odd to advocate against the use of a universal method and FOR the use of one of many hundreds of package managers for NIX operating systems that claims to have gotten it right? Adding maintenance overhead to a FOSS project to support a package manager is one thing, adding support for every Flavor Of The Week package manager after that initial time investment is tougher, especially when the first one is no longer en vogue. tl;dr : the thousands of ways to package data for NIX creates a situation in which hurts maintainability unless the package maintainer lucks into picking the one that their crowd wants for any length of time. Piping data from curl works just about anywhere, even if it's a huge security faux-pas waiting to happen. semi-unrelated aside : it strikes me as humorous that people on that side of OS aisle have cared so much about pipes being a security issue for years and years, whereas on the MS side of things people still distribute (sometimes unsigned) binaries all over the place, from all over the place, by any random mary/joe. (not to say that that's not the case on the nix side, but it feels more commonplace in MS land, that's for sure.)
  - deathanatos 4y ago
    One of the the things I love about Gentoo & Arch is that packaging for them is incredibly easy. At least, as long as upstream isn't doing anything insane. But this means that I as a user can wrap an upstream package, without too much of an issue. (E.g., if you have a binary tarball that can be unpacked to, e.g., /opt. Even if it has to be built, so long as your dependencies are clear, that's usually not too hard. Some languages fight package management a bit more than others, though.)
- bravetraveler 4y ago
  I'm with you! If you're serious about your software (read: you want users)... either make a Flatpak manifest, package spec, or something equivalent. Point is, somebody made something better than this little install shell script. I'll accept pip, I'm not picky. There is almost surely no reason for $thing to be writing to my system directories. Nobody should be coaching this, it can go wrong in every way. Binaries and libraries can come from my home directory. You won't find /home mounted with noexec outside of strict compliance environments. Build services like OBS and COPR make the actual equipment investment of building packages basically non-existent. Roaming repositories for any distribution you could want. Leaving the one-time cost of writing out the specs... and I suppose maintaining dependency creep. That maintenance isn't that expensive because you'd be maintaining them in the script anyway. You're just using common domain language Do these things and you cover 95% of the DSL: - PKGBUILD (basically the script, AUR means you'll get maintainers) - RPM - DEB Say a fourth significant option comes around, I'll guarantee you the concepts are similar enough. Macro creep is real, but this is the cost of maintenance work. Give us something to maintain. Signed, - A person maintaining several packages for projects with no upstream involvement
  - fiddlerwoaroof 4y ago
    Pip/npm/gems are just as bad as are debs/rpms from an untrusted source. Piping curl to sh is no worse than any other way of installing unvetted software from an untrusted source and the only better alternative is either verifying the software installation instructions yourself or relying on a trusted third party to do this for you (e.g. the Debian maintainers)
    - bravetraveler 4y ago
      Those services I mentioned -- COPR/OBS, they can be the trusted sources by your users. They're signed the same way as your first party packages. If you trust the developer/maintainer, you can trust these services. It's literally the same infrastructure as OpenSUSE/Fedora/Red Hat. As a developer you don't have to provide the infrastructure or equipment, simply whatever is to be built. I'm not suggesting people provide their software by pure RPM or DEB files. The repositories do the important part of actually distributing the software. If you're on either OBS or COPR you're on the fast path to having the OS maintainers do the work for you
- twblalock 4y ago
  Package management isn't realistic unless you only pick a few distros to support -- and then you get criticized for not supporting every distro, some of the distros end up way behind on the version, some of them modify your code to make it fit better in their system...
  - Eleison23 4y ago
    [dead]
  - saghm 4y ago
    Lately I've been coming around to the idea that AppImage is the best middle ground we have so far. Basically, it lets you provide static binary for people to download and use as-is if their repos don't have it available but then bundles in special flags starting with `--appimage-` for stuff like extracting the bundle libraries/assets into a directory structure that's the same for every AppImage. It seems like it's a step in the direction towards being able to automate making packages for various distros; It would be a tough design problem but really amazing if the format being expanded to be able to include source files so that each package manager could write their own plugins for converting the extracted AppImage into their own package format (appimage2deb, appimage2rpm, etc.). Maybe AppImage isn't the right basis for this sort of thing, but instead of trying to drive adoption of distro agnostic package managers which will face resistance from distro maintainers, I feel like the right solution would be something that provides for distros what LSP provided for editors and what LLVM provided for compiler authors. We're not lacking in package managers as a community, but we really could use a standard protocol or intermediate layer that _doesn't _ try to replace existing package managers but instead works with and relies upon them in a way that benefits everyone.
    - aprdm 4y ago
      It’s worth noting that some big companies have something like what you describe. I was building packages for one and it’s basically reverse engineering however something is packed (e.g an RPM) and making it build/bundle in the way big corp operates. It’s a lot of busy work but we guaranteed that we had all dependencies in house and that the same package had the same layout of files across every OS
- charcircuit 4y ago
  The alternative is something like AppImage. The benefit of curl | bash is that it's a command that can be run on any distro and just work. There is no need to worry about how the Linux ecosystem still hasn't agreed upon a single package format.
  - encryptluks2 4y ago
    I've worked with people creating curl scripts to install software and most of the time it should scare people. At least with package management there is some community validation and version history of what changes are made, as well as checksum. I'm not saying you should discount all installs using curl, but you should at least check the script first and see if you're comfortable proceeding.
- bombolo 4y ago
  The bar is much higher to enter a distribution. You need to use an appropriate license, you can't download stuff from the internet, you can't vendor libraries.
  - deathanatos 4y ago
    … you don't have to be part of the distro's official package set. Ubuntu, Debian, Gentoo, Arch, etc., support third-party repositories and packages with bad licenses: the user adds the repo / installs the deb / etc. Pacman, in particular, even has direct support for such, and calls them out (to help ensure the user knows, and perhaps reads, the license). Then I know I can gracefully uninstall the package by just asking the package manager to do that. (You don't have to unvendor libs, either: if you install into something like /opt/$pakage_name, you can keep vendored libs in there. You should unvendor them, though. Yeah, downloading stuff from the Internet in the middle of a package install is definitely harder with some package managers, but IMO that's a poor practice.)
    - hsbauauvhabzb 4y ago
      I agree with your sentiment, but do any of those package managers prevent some random repository from adding Firefox version 190 which will install on next apt upgrade? Not that they need to - presumably any package I’ve installed already basically has root access.
      - chungy 4y ago
        Yes. Apt has preferences and pinning. Basically the official repositories by default have higher priority than other repositories. You can change the defaults, but you'll know when it happens (because you have to do it yourself).
- deleted 4y ago
  [deleted]
- ithkuil 4y ago
  Sure package management is nice but that's actually orthogonal with secure delivery. Something like: https://getsum.pub https://getsum.pub
- nine_k 4y ago
  For self-contained stuff, there is AppImage that's just a filesystem subtree [1], or a Docker container. The latter doesn't need Docker, or even Podman; you likely already have systemd, and it knows how to run a container. If you want to depend on system-wide stuff, or, worse yet, provide shared system-wide stuff, it's time to create a proper OS package (a bunch of them: Debian, Ubuntu, Fedora, Nix, etc). The curl | bash approach has only one upside: you can store the script, inspect it, then run. I did that a couple times. Because otherwise it's a pretty scary operation, a very literal RCE.
  - masklinn 4y ago
    > The curl | bash approach has only one upside: you can store the script, inspect it, then run. Not having to waste countless hours on whatever distro's package format of choice is a pretty big upside. And those are also RCEs if you're not upstreaming the package (which you likely are not because that increases the amount of time needed by an order of magnitude) as most package managers have multiple scripting points which run arbitrary code, and usually run as root already.
- aeyes 4y ago
  If I give you an rpm package, that isn't really any better. It can run any script during installation and you'll already be running it as root.
  - TacticalCoder 4y ago
    > If I give you an rpm package, that isn't really any better. It can run any script during installation and you'll already be running it as root. But it's not about you giving an rpm package at will. It's about the distro including packages in its official distribution and many people installing the very exact same package. Instead of people randomly pulling install scripts from the Web which can, for all we know, at every curl, be fetching a different install script. In addition to that Debian has an ever growing number of packages which are fully reproducible, bit for bit. All these executables, reproducible bit by bit. When I install a package from Debian I know many people have already both scrutinized it and installed it. It's not a guaranteed nothing shady is going on but what's safer: - installing a Debian package (moreover reproducible bit for bit) which many people already installed - curl bash'ing some URL at random Anyone who says the two offer the same guarantees is smoking something heavy. It's all too easy to sneak it in a backdoor for, say, once every 100 download when you moreover detect, as in TFA, that curl bash'ing is ongoing. And it's hard to catch. And it's near impossible to reproduce. When you install from a package that's full reproducible: there's nowhere to run, nowhere to hide, for the backdoor once noticed. It shall eventually be caught. Here's why it matters (FWIW there are tens of thousands of Debian packages which are fully reproducible): https://reproducible-builds.org/ https://reproducible-builds.org/ Thinking that installing a package "isn't really any better" than curl bash'ing from a URL is, plain simply, wrong.
  - colinsane 4y ago
    consider the broader class of attack this article is demonstrating: stealthily delivering different payloads to different requests. i don’t know about rpm specifically, but most new-ish package managers do actually ensure this more strongly than any curl-based approach: a hash of the 3rd party content is provided through some more secure chain (e.g. directly in your OS’s or language’s package database, or signed by some key associated with one of those and which you’ve already trusted). yeah, if the package is delivered through the same channel as the bash script, and not anchored by anything external, you lose those benefits. but even hosting the package contents through pip or cargo or AUR or just unaffiliated and manually synced mirrors is a (relatively easy) way to decrease that attack surface.
- IshKebab 4y ago
  That's misplaced. You should be annoyed at distros for not agreeing to a reasonable minimal cross-distro package format. Nobody has time to create packages for 8 different distros.
Semaphor 4y ago
2016 2020, 133 comments: https://news.ycombinator.com/item?id=25356757 https://news.ycombinator.com/item?id=25356757 2018, 146 comments: https://news.ycombinator.com/item?id=17636032 https://news.ycombinator.com/item?id=17636032 2016, 122 comments: https://news.ycombinator.com/item?id=11532599 https://news.ycombinator.com/item?id=11532599
- xrayarx 4y ago
  I think this should be a feature of HN: Automatically post previous posts of the same article
  - baq 4y ago
    with archive.org links and diffs.
  - swyx 4y ago
    you can already get this with the "Refined HN" chrome extension
    - Semaphor 4y ago
      Firefox as well, not just the adtech browser. It’s what I usually use to post these, but this time I was at my parents and remembered that I had seen this before, so I used the search ;)
  - zufallsheld 4y ago
    It sort of exists already. There is a "past" link under the title of the submission that lists previous submissions.
deleted 4y ago
[deleted]
zeptonix 4y ago
Always safer to first curl url > file, then read through file, then only if all looks good, run the file (under an appropriate user and with permissions as limited as possible, etc.)
- rgoulter 4y ago
  Is there any meaningful/significant security benefit from doing this? Whatever executable such a script installs could itself later download + run arbitrary commands.
  - leoh 4y ago
    Given that an attacker would likely obfuscate shenanigans, I don’t think there is much benefit to glancing over source unless you’re really ready to do a little research project for a few hours.
  - sureglymop 4y ago
    The benefit for me is knowing what installs where so that i can later uninstall everything without having to rely on an uninstaller that leaves bits behind. Of course I'm talking about a different scenario where I'm already assuming the script and binaries it installs are safe.
    - radarsat1 4y ago
      I used to use checkinstall for this, makes a little uninstallable apt package for you.
    - midasuni 4y ago
      I’m old enough to remember when you had a makefile or even better an rpm or deb. It was so much better than the windows way of running a random program with little visibility, and so sad when so much software changed away from that method.
      - imperfect_blue 4y ago
nodoodles 4y ago
Neat! A more foolproof method might be sending a bit of bash that triggers a callback request (ie "liveness check", "latest version check" etc) to origin server, and pauses. When the callback is received, continue with malicious payload, otherwise after some timeout, send a benign script..
- jameshart 4y ago
  This approach seems much simpler and more reliable than detecting the pipe buffer is full.
- catalypso 4y ago
  That would indeed be more precise, but it would be harder to obfuscate. If I simply curl the script (without piping to bash), I'd be less suspicious if I saw a sleep than I would be if I saw a callback to a server.
Neil44 4y ago
On an old web server I ran for someone I renamed the original curl and wgets and replaces them with ones that just logged and did nothing else. After a year I had a nice list of URL’s for naughty scripts bots and exploits! (Server ran a load of Wordpress sites)
gorgoiler 4y ago
A clever trick with a funny example, but I’m also fine with curl|bash — as fine as I am with “pip3 install thing” or installing “thing.dmg”. I almost always decide whether to execute someone’s else’s software based on their reputability. Is the project well known? Is it maintained, with lots of GitHub stars? My decision is never based on reading the source code. I don’t have nearly as much of a problem with curling shell scripts as the finger-wagging “actually you shouldn’t do that” crowd seem to say I should. The one thing that really does give me the creeps is adding someone else’s apt repository to my system-wide one. I just can’t seem to square that off in my head against my more laissez-afire “well do I trust them or not?” attitude that I take for every other installation attack vector. Maybe because it means trusting the third party forever, instead of just once?
- kevin_thibedeau 4y ago
  The problem with Pypi is the transitive dependencies. You may trust a high profile package but it could pull in any number of projects that are exploited by bad actors.
  - freeqaz 4y ago
    This is a real problem that I believe will become increasingly commonly used by attackers to break into companies. Unfortunately, it's not an easy problem to automate the detection. There are some heuristics, but you're basically writing something like Norton Antivirus for Python packages lol. A sufficiently skilled attacker can make their code look totally innocent[0]. :) Source: Former security engineer at Uber/Snap that's now working on tooling in this space[1]. 0: "Underhanded C Competition" http://www.underhanded-c.org/ http://www.underhanded-c.org/ 1: Open Source "Supply Chain Security" platform https://github.com/lunasec-io/lunasec https://github.com/lunasec-io/lunasec
    - jollofricepeas 4y ago
      It’s already extremely common in the Python, Ruby and Node ecosystem (see sources below). The only company that has a real chance at making a dent in the issue is GitHub and to a degree they already have. SOURCES: - https://www.mandiant.com/resources/blog/supply-chain-node-js https://www.mandiant.com/resources/blog/supply-chain-node-js - https://www.zdnet.com/article/backdoor-found-in-ruby-library-for-checking-for-strong-passwords/ https://www.zdnet.com/article/backdoor-found-in-ruby-library... - https://www.reversinglabs.com/blog/mining-for-malicious-ruby-gems https://www.reversinglabs.com/blog/mining-for-malicious-ruby... - https://news.sophos.com/en-us/2021/10/24/node-poisoning-hijacked-package-delivers-coin-miner-and-credential-stealing-backdoor/amp/ https://news.sophos.com/en-us/2021/10/24/node-poisoning-hija... - https://www.bleepingcomputer.com/news/security/dev-corrupts-npm-libs-colors-and-faker-breaking-thousands-of-apps/amp/ https://www.bleepingcomputer.com/news/security/dev-corrupts-... - https://portswigger.net/daily-swig/amp/malicious-python-library-ctx-removed-from-pypi-repo https://portswigger.net/daily-swig/amp/malicious-python-libr...
jakear 4y ago
Funny, I thought about this today when installing Bun^. I read the bash script, saw that it was indeed downloading a release binary from the official GitHub repo, then gave up. The binary it downloaded could do absolutely anything when I run it, am I supposed to then go and verify every line of the source, and all its dependencies? Then verify the release package is the same as the one I make building it myself? Then verify the compiler source is a reasonable interpretation of the Zig spec (which doesn't seem to exist)? Then verify the complier binary I used is the same as the one created by a trusted compilers? Then verify all those binaries.... End of the day: the package is from a somewhat reputable source, and you don't keep life changing secrets user-accessible on your dev machine, fuck it. Also, resist installing as root. Figure out what the real permissions the thing needs are and go from there. ^https://bun.sh/ https://bun.sh/ (if you haven't been introduced: https://dl.acm.org/doi/pdf/10.1145/358198.358210 https://dl.acm.org/doi/pdf/10.1145/358198.358210)
- Jarred 4y ago
  Unfortunately it takes awhile to compile Bun from scratch. It doesn’t need root privileges though. To compile Bun completely from scratch, you’d need to compile: - Zig - mimalloc - libtcc - zlib - picohttpparser - sqlite3 - BoringSSL - WebKit’s JSCOnly port - libarchive - lol-html (+ rust) From there, you also need clang 13, which you might also want to compile from source (though that can take an hour or more). When compiling Bun in CI, many dependencies are compiled from source (excluding Rust, LLVM, and Zig)
  - unsafecast 4y ago
    How does compiling it yourself change anything?
    - jakear 4y ago
      If all you do is download the release binary, anything could compromise you. If you read the source, an inauthentic release binary could compromise you. If you read the source and compile it, a compromised compiler could compromise you. If you read the compiler source, bootstrap compiling it from hardware code (reading all the source along the way), read the app source, and finally compile it using your compiled compiler, then compromised hardware could compromise you. Every step along the way you increase the severity of the statement "If I'm fucked, then so is everyone using X". You stop when the set of people using X grows so large than you are sufficiently worthless in comparison.
zX41ZdbW 4y ago
I've also thought about this problem but ended up with curl | sh: curl https://clickhouse.com/ | sh The arguments are: - it's 'sh', not 'sudo sh', so it's not that bad; - you can remove '| sh' and read the script; - the deb, rpm, tgz, and docker packages are also provided, but only as advanced usage; - nevertheless, all these packages, for all distributions, contain the same byte-identical ClickHouse binary. It works surprisingly well. Even people without experience can copy-paste this command and start using our software.
- LinuxBender 4y ago
  it's 'sh', not 'sudo sh', so it's not that bad; Along the lines of "curl | bash" detection, one can add "sudo -n" to see if the person has passwordless sudo. In my own testing I have found that many people have passwordless sudo. Even without sudo it turns out that people have bad posix permissions throughout their filesystem and one can hijack many things including existing SSH tunnels because of control-master. Even without sudo one can hop around a persons production network riding existing SSH channels. Many devops people have SSH multiplexing and control-master enabled in their SSH client. Then it is just a matter of finding bad permissions in production environments which is also often the case. One rarely needs root to download or even modify database contents as the database credentials are often stored in an environment file that gets sourced by automation. The biggest problem here I see is that companies rarely let their penetration testers a.k.a. red-team into production. Corporate leaders would be taken aback at the findings.
- Kwpolska 4y ago
  > - you can remove '| sh' and read the script; But why can’t I copy the URL into my browser? Why discriminate on user agent? Why couldn’t it be https://clickhouse.com/install.sh https://clickhouse.com/install.sh - so that it would work with browsers and curl alike? > - the deb, rpm, tgz, and docker packages are also provided, but only as advanced usage; How are deb and rpm advanced? How do I uninstall something installed with your custom script? Also, why are the RPM packages [0] still using /etc/init.d and not systemd? [0] https://clickhouse.com/docs/en/install/#from-rpm-packages https://clickhouse.com/docs/en/install/#from-rpm-packages
tomp 4y ago
> Installing software by piping from curl to bash is obviously a bad idea and a knowledgable user will most likely check the content first. I’ve yet to hear a coherent explanation why this is any worse than installing software from the internet in general. It’s not like you check the source of all software you install.
- deleted 4y ago
  [deleted]
- ducktective 4y ago
  If maintainers of the distro review their accepted packages thoroughly, then apt install would be superior to curl | bash But 9 out of 10 times I used apt install cargo, I've been bitten by dependency hell
- jacooper 4y ago
  I think its more that the packages are vetted by your distro, but this script isn't, and you don't know what's in it.
  - tomp 4y ago
    Most software I install isn’t distro software, but Python binaries (python, mamba, numpy, pytorch) and packages via pip/mamba/conda.
- LilBytes 4y ago
  Source in this instance doesn't always mean source code but _the source were you're downloading it from_. If canonical.com tells me to curl $url | sh, I'm fairly confident the script Im downloading is safe. as much as an .iso, .bin or .exe would be. But I'd be a lot more hesitant doing the same from craigs-legit-swe-blog.com.
- l33tman 4y ago
  I guess it's a question of effort on the side of the person doing the trojan - if enough suckers just copy those snippets regularly you can be lazy and just do it like that, you don't need to go through the hassle of creating fake Ubuntu PPAs with trojans or distribute a big repo on GitHub and risk someone seeing the trojan part.
mootzville 4y ago
Seems like the best solution is to not use this technique. Been touching linux servers for 10+ years, and have never had to use it. I definitely used it when learning linux though. I curl to files for review when I need / want to run a remote script. A bonus is you still have to `chmod u+x some_remote.sh` before it can be run, so it would be extremely difficult to accidentally run.
- mootzville 4y ago
  Having said that, I write a lot of JS / Node. When you npm (a package manager for NodeJS) install something there could very well be some curl commands piping to bash or sh. Makes me think of an idea -- and maybe it exists -- create a npm package whose only purpose is to run checks on the code of the other packages being installed to ensure they are "safe".
digitalsushi 4y ago
I used to do this for a product... I was finding that some of it was apparently happening asynchronously. I had a separate shell function I grabbed from the first, with all the functions. I eventually put a variable at the bottom of it with a sentinel value, and from the first script, would block until that variable got populated, before running the main function. I think I'd always do it as an inline script. Admittedly I was slopping a lot of mud on the wall back then as a tactic.
alexiaa 4y ago
I think this could be avoided by using this syntax instead: bash < <(curl -fsSL example.com/foo.sh)
pornel 4y ago
Cleverness and sneakiness of this technique makes people laser-focus just the Hollywood-worthy hack, and forget the larger picture that it's about trusting the host not to pwn you. If you trust the host won't screw you, it doesn't matter how many style points they could have scored on something they won't do. If you don't trust the host, don't use it, because reviewing 10 lines of bash won't save you. • The sneakiness of this can be defeated with `tee` (or a variety of other ways like modified bash or a VM). • dpkg runs arbitrary package scripts as root, so you still put trust in whoever signed the package. • When you use `curl|sh` to install binary blob built from millions lines of code, it has countless other opportunities to include exploits with plausible deniability. If the host is hacked, they can put the payload in the binary, knowing you'll review the bash script like a hawk, and then YOLO the rest. • Targeted attacks can can use your IP too. • Your distro's overworked unpaid maintainer LGTMs packages with a glance, and won't review millions lines of code for backdoors. • There is a huge gap between what people imagine they could have theoretically done properly to keep things secure and gather evidence of any potential wrongdoing, and what they actually do.
- ddtaylor 4y ago
  > dpkg runs arbitrary package scripts as root, so you still put trust in whoever signed the package. This is correct, but in those cases the maintainer is likely a much more trusted individual where more eyes are on the script as the hierarchy of maintainers sign off on things until the point it makes it into a readily accessible repository by end-users. > Your distro's overworked unpaid maintainer LGTMs packages with a glance, and won't review millions lines of code for backdoors. The same argument could be made about the Linux kernel itself, yet the system is surprisingly robust and examples of abuse are few and far between.
- Zuiii 4y ago
  > people [..] forget the larger picture that it's about trusting the host not to pwn you It's not about that. It's about pushing back the trust boundary to be as close to the source as possible. Of course your upstream can compromise you if they turn malicious, but having your trust boundary needlessly extend all the way out to the web server is not only unnecessary but also introduces real dangers to users (unless you also consider Transmission's incident to be one of your "Hollywood-worthy" hacks). I'm glad people are rightfully criticizing this stupid approach. I'm glad most reputable systems use off-line signatures to verify software before running it. Security is not about absolutes. It's about thresholds.
blacklion 4y ago
I don't understand, why do people throw in trash can one of the strongest Linux features: package management. Left aside security implications of "curl | bash" installation - what will you do if installation fails and you need to roll-back partial changes to system? How will you update this software? How will you uninstall in the future? How will you track CVEs for it, if your package manager doesn't know about its existence and all periodic scripts of your distro can not check for CVEs? How you will update libraries used by this software, are you sure this will not broke it?
- tylergetsay 4y ago
  This is what has been pushing Arch Linux and the AUR for me
- bigDinosaur 4y ago
  Extreme simplicity. This is the installation equivalent to updating your website by scp-ing in a new index.html.
  - blacklion 4y ago
    To be honest, if you site is static-generated (where "generated" includes "typed by you in text editor") this approach hasn't any drawbacks to more complex schemes. Installing software via running random scripts has a ton of drawbacks to using system package manager.
- marcosdumay 4y ago
  Linux needs an normal-user package manager.
  - londonReed 4y ago
    Almost all package managers have a graphical front end. I'm not sure how that's not "Normal user" oriented. Windows even has a "Windows Store" bastardized version of a package manager,
Makhini 4y ago
As a side note: the culture or installing stuff via curl is like a virus. If you check the npm docs, they say "We strongly recommend using a Node version manager like nvm to install Node.js and npm". Then if you check nvm docs, the primary installation method is curl to bash, and not even from their official website - it pulls stuff from github...
fbrusch 4y ago
A way to fix this is via content addressable distribution protocols such as IPFS (maybe supported by a trasparent name system like ENS).
deleted 4y ago
[deleted]
fburnaby 4y ago
I have been getting tired of node dependencies and not knowing what I'm running or when it will break. I make simple things for small number of users and started playing with just writing my own CGI in C++ or bash behind thttpd. This appears to be working very well so far and runs on a vanilla Linux install with deps just on system libs and gcc. With all the pain and unsafety of deps, this might actually make most sense. What new vulnerabilities am I inviting? Why aren't we still doing things this way? It seems... much easier, perhaps not to make it but to secure and sustain it.
rcarr 4y ago
If dependency hell is pretty much unavoidable at this point, is the best solution for everyone to have something like Little Snitch or similar installed that monitors for unusual outgoing traffic so that the hackers can't get away with it for very long before getting shut down? And to do all high risk activity like coding in VMs?
fargle 4y ago
wouldn't it be a whole lot easier for the script being curled to just detect it was running as part of a `curl | bash` pipeline and bail out with a message? if [ ! -t 0 ]; then echo "script must be run interactively, etc."; exit 1; fi of course that's equally useless because as someone else said, the root problem with doing `curl | bash` in the first place is that you are putting the trust in someone else's server, so you can't fix that "server side". what the article is proposing is a whole lot of magic detect `curl | bash` from his safe server, where's it's already safe.

373 points by pabs3 4y ago

I get so annoyed at the amount of Linux tools suggesting to install something using this method rather than focusing on package management inclusion. Even more so when they try to request sudo access.

worldsavior 4y ago
It's sometimes preferred because package repositories don't always include the updated version of the program, and saves the tedious work on uploading to every package repository like Arch Linux or Debian's.
Semaphor 4y ago
A common reply is that all the different package managements are even more work for someone already maintaining a project.
- geggam 4y ago
  Funny thing about work. It is usually something people dont want to do and this is why its incentivized with money.
  - serf 4y ago
    I mean, you're right -- but security and maintainability aside doesn't it feel odd to advocate against the use of a universal method and FOR the use of one of many hundreds of package managers for NIX operating systems that claims to have gotten it right? Adding maintenance overhead to a FOSS project to support a package manager is one thing, adding support for every Flavor Of The Week package manager after that initial time investment is tougher, especially when the first one is no longer en vogue. tl;dr : the thousands of ways to package data for NIX creates a situation in which hurts maintainability unless the package maintainer lucks into picking the one that their crowd wants for any length of time. Piping data from curl works just about anywhere, even if it's a huge security faux-pas waiting to happen. semi-unrelated aside : it strikes me as humorous that people on that side of OS aisle have cared so much about pipes being a security issue for years and years, whereas on the MS side of things people still distribute (sometimes unsigned) binaries all over the place, from all over the place, by any random mary/joe. (not to say that that's not the case on the nix side, but it feels more commonplace in MS land, that's for sure.)
- deathanatos 4y ago
  One of the the things I love about Gentoo & Arch is that packaging for them is incredibly easy. At least, as long as upstream isn't doing anything insane. But this means that I as a user can wrap an upstream package, without too much of an issue. (E.g., if you have a binary tarball that can be unpacked to, e.g., /opt. Even if it has to be built, so long as your dependencies are clear, that's usually not too hard. Some languages fight package management a bit more than others, though.)
bravetraveler 4y ago
I'm with you! If you're serious about your software (read: you want users)... either make a Flatpak manifest, package spec, or something equivalent. Point is, somebody made something better than this little install shell script. I'll accept pip, I'm not picky. There is almost surely no reason for $thing to be writing to my system directories. Nobody should be coaching this, it can go wrong in every way. Binaries and libraries can come from my home directory. You won't find /home mounted with noexec outside of strict compliance environments. Build services like OBS and COPR make the actual equipment investment of building packages basically non-existent. Roaming repositories for any distribution you could want. Leaving the one-time cost of writing out the specs... and I suppose maintaining dependency creep. That maintenance isn't that expensive because you'd be maintaining them in the script anyway. You're just using common domain language Do these things and you cover 95% of the DSL: - PKGBUILD (basically the script, AUR means you'll get maintainers) - RPM - DEB Say a fourth significant option comes around, I'll guarantee you the concepts are similar enough. Macro creep is real, but this is the cost of maintenance work. Give us something to maintain. Signed, - A person maintaining several packages for projects with no upstream involvement
- fiddlerwoaroof 4y ago
  Pip/npm/gems are just as bad as are debs/rpms from an untrusted source. Piping curl to sh is no worse than any other way of installing unvetted software from an untrusted source and the only better alternative is either verifying the software installation instructions yourself or relying on a trusted third party to do this for you (e.g. the Debian maintainers)
  - bravetraveler 4y ago
    Those services I mentioned -- COPR/OBS, they can be the trusted sources by your users. They're signed the same way as your first party packages. If you trust the developer/maintainer, you can trust these services. It's literally the same infrastructure as OpenSUSE/Fedora/Red Hat. As a developer you don't have to provide the infrastructure or equipment, simply whatever is to be built. I'm not suggesting people provide their software by pure RPM or DEB files. The repositories do the important part of actually distributing the software. If you're on either OBS or COPR you're on the fast path to having the OS maintainers do the work for you
twblalock 4y ago
Package management isn't realistic unless you only pick a few distros to support -- and then you get criticized for not supporting every distro, some of the distros end up way behind on the version, some of them modify your code to make it fit better in their system...
- Eleison23 4y ago
  [dead]
- saghm 4y ago
  Lately I've been coming around to the idea that AppImage is the best middle ground we have so far. Basically, it lets you provide static binary for people to download and use as-is if their repos don't have it available but then bundles in special flags starting with `--appimage-` for stuff like extracting the bundle libraries/assets into a directory structure that's the same for every AppImage. It seems like it's a step in the direction towards being able to automate making packages for various distros; It would be a tough design problem but really amazing if the format being expanded to be able to include source files so that each package manager could write their own plugins for converting the extracted AppImage into their own package format (appimage2deb, appimage2rpm, etc.). Maybe AppImage isn't the right basis for this sort of thing, but instead of trying to drive adoption of distro agnostic package managers which will face resistance from distro maintainers, I feel like the right solution would be something that provides for distros what LSP provided for editors and what LLVM provided for compiler authors. We're not lacking in package managers as a community, but we really could use a standard protocol or intermediate layer that _doesn't _ try to replace existing package managers but instead works with and relies upon them in a way that benefits everyone.
  - aprdm 4y ago
    It’s worth noting that some big companies have something like what you describe. I was building packages for one and it’s basically reverse engineering however something is packed (e.g an RPM) and making it build/bundle in the way big corp operates. It’s a lot of busy work but we guaranteed that we had all dependencies in house and that the same package had the same layout of files across every OS
charcircuit 4y ago
The alternative is something like AppImage. The benefit of curl | bash is that it's a command that can be run on any distro and just work. There is no need to worry about how the Linux ecosystem still hasn't agreed upon a single package format.
- encryptluks2 4y ago
  I've worked with people creating curl scripts to install software and most of the time it should scare people. At least with package management there is some community validation and version history of what changes are made, as well as checksum. I'm not saying you should discount all installs using curl, but you should at least check the script first and see if you're comfortable proceeding.
bombolo 4y ago
The bar is much higher to enter a distribution. You need to use an appropriate license, you can't download stuff from the internet, you can't vendor libraries.
- deathanatos 4y ago
  … you don't have to be part of the distro's official package set. Ubuntu, Debian, Gentoo, Arch, etc., support third-party repositories and packages with bad licenses: the user adds the repo / installs the deb / etc. Pacman, in particular, even has direct support for such, and calls them out (to help ensure the user knows, and perhaps reads, the license). Then I know I can gracefully uninstall the package by just asking the package manager to do that. (You don't have to unvendor libs, either: if you install into something like /opt/$pakage_name, you can keep vendored libs in there. You should unvendor them, though. Yeah, downloading stuff from the Internet in the middle of a package install is definitely harder with some package managers, but IMO that's a poor practice.)
  - hsbauauvhabzb 4y ago
    I agree with your sentiment, but do any of those package managers prevent some random repository from adding Firefox version 190 which will install on next apt upgrade? Not that they need to - presumably any package I’ve installed already basically has root access.
    - chungy 4y ago
      Yes. Apt has preferences and pinning. Basically the official repositories by default have higher priority than other repositories. You can change the defaults, but you'll know when it happens (because you have to do it yourself).
deleted 4y ago
[deleted]
ithkuil 4y ago
Sure package management is nice but that's actually orthogonal with secure delivery. Something like: https://getsum.pub https://getsum.pub
nine_k 4y ago
For self-contained stuff, there is AppImage that's just a filesystem subtree [1], or a Docker container. The latter doesn't need Docker, or even Podman; you likely already have systemd, and it knows how to run a container. If you want to depend on system-wide stuff, or, worse yet, provide shared system-wide stuff, it's time to create a proper OS package (a bunch of them: Debian, Ubuntu, Fedora, Nix, etc). The curl | bash approach has only one upside: you can store the script, inspect it, then run. I did that a couple times. Because otherwise it's a pretty scary operation, a very literal RCE.
- masklinn 4y ago
  > The curl | bash approach has only one upside: you can store the script, inspect it, then run. Not having to waste countless hours on whatever distro's package format of choice is a pretty big upside. And those are also RCEs if you're not upstreaming the package (which you likely are not because that increases the amount of time needed by an order of magnitude) as most package managers have multiple scripting points which run arbitrary code, and usually run as root already.
aeyes 4y ago
If I give you an rpm package, that isn't really any better. It can run any script during installation and you'll already be running it as root.
- TacticalCoder 4y ago
  > If I give you an rpm package, that isn't really any better. It can run any script during installation and you'll already be running it as root. But it's not about you giving an rpm package at will. It's about the distro including packages in its official distribution and many people installing the very exact same package. Instead of people randomly pulling install scripts from the Web which can, for all we know, at every curl, be fetching a different install script. In addition to that Debian has an ever growing number of packages which are fully reproducible, bit for bit. All these executables, reproducible bit by bit. When I install a package from Debian I know many people have already both scrutinized it and installed it. It's not a guaranteed nothing shady is going on but what's safer: - installing a Debian package (moreover reproducible bit for bit) which many people already installed - curl bash'ing some URL at random Anyone who says the two offer the same guarantees is smoking something heavy. It's all too easy to sneak it in a backdoor for, say, once every 100 download when you moreover detect, as in TFA, that curl bash'ing is ongoing. And it's hard to catch. And it's near impossible to reproduce. When you install from a package that's full reproducible: there's nowhere to run, nowhere to hide, for the backdoor once noticed. It shall eventually be caught. Here's why it matters (FWIW there are tens of thousands of Debian packages which are fully reproducible): https://reproducible-builds.org/ https://reproducible-builds.org/ Thinking that installing a package "isn't really any better" than curl bash'ing from a URL is, plain simply, wrong.
- colinsane 4y ago
  consider the broader class of attack this article is demonstrating: stealthily delivering different payloads to different requests. i don’t know about rpm specifically, but most new-ish package managers do actually ensure this more strongly than any curl-based approach: a hash of the 3rd party content is provided through some more secure chain (e.g. directly in your OS’s or language’s package database, or signed by some key associated with one of those and which you’ve already trusted). yeah, if the package is delivered through the same channel as the bash script, and not anchored by anything external, you lose those benefits. but even hosting the package contents through pip or cargo or AUR or just unaffiliated and manually synced mirrors is a (relatively easy) way to decrease that attack surface.
IshKebab 4y ago
That's misplaced. You should be annoyed at distros for not agreeing to a reasonable minimal cross-distro package format. Nobody has time to create packages for 8 different distros.

Semaphor 4y ago

2016 2020, 133 comments: https://news.ycombinator.com/item?id=25356757 https://news.ycombinator.com/item?id=25356757 2018, 146 comments: https://news.ycombinator.com/item?id=17636032 https://news.ycombinator.com/item?id=17636032 2016, 122 comments: https://news.ycombinator.com/item?id=11532599 https://news.ycombinator.com/item?id=11532599

xrayarx 4y ago
I think this should be a feature of HN: Automatically post previous posts of the same article
- baq 4y ago
  with archive.org links and diffs.
- swyx 4y ago
  you can already get this with the "Refined HN" chrome extension
  - Semaphor 4y ago
    Firefox as well, not just the adtech browser. It’s what I usually use to post these, but this time I was at my parents and remembered that I had seen this before, so I used the search ;)
- zufallsheld 4y ago
  It sort of exists already. There is a "past" link under the title of the submission that lists previous submissions.

deleted 4y ago

[deleted]

zeptonix 4y ago

Always safer to first curl url > file, then read through file, then only if all looks good, run the file (under an appropriate user and with permissions as limited as possible, etc.)

rgoulter 4y ago
Is there any meaningful/significant security benefit from doing this? Whatever executable such a script installs could itself later download + run arbitrary commands.
- leoh 4y ago
  Given that an attacker would likely obfuscate shenanigans, I don’t think there is much benefit to glancing over source unless you’re really ready to do a little research project for a few hours.
- sureglymop 4y ago
  The benefit for me is knowing what installs where so that i can later uninstall everything without having to rely on an uninstaller that leaves bits behind. Of course I'm talking about a different scenario where I'm already assuming the script and binaries it installs are safe.
  - radarsat1 4y ago
    I used to use checkinstall for this, makes a little uninstallable apt package for you.
  - midasuni 4y ago
    I’m old enough to remember when you had a makefile or even better an rpm or deb. It was so much better than the windows way of running a random program with little visibility, and so sad when so much software changed away from that method.
    - imperfect_blue 4y ago

nodoodles 4y ago

Neat! A more foolproof method might be sending a bit of bash that triggers a callback request (ie "liveness check", "latest version check" etc) to origin server, and pauses. When the callback is received, continue with malicious payload, otherwise after some timeout, send a benign script..

jameshart 4y ago
This approach seems much simpler and more reliable than detecting the pipe buffer is full.
catalypso 4y ago
That would indeed be more precise, but it would be harder to obfuscate. If I simply curl the script (without piping to bash), I'd be less suspicious if I saw a sleep than I would be if I saw a callback to a server.

Neil44 4y ago

On an old web server I ran for someone I renamed the original curl and wgets and replaces them with ones that just logged and did nothing else. After a year I had a nice list of URL’s for naughty scripts bots and exploits! (Server ran a load of Wordpress sites)

gorgoiler 4y ago

A clever trick with a funny example, but I’m also fine with curl|bash — as fine as I am with “pip3 install thing” or installing “thing.dmg”. I almost always decide whether to execute someone’s else’s software based on their reputability. Is the project well known? Is it maintained, with lots of GitHub stars? My decision is never based on reading the source code. I don’t have nearly as much of a problem with curling shell scripts as the finger-wagging “actually you shouldn’t do that” crowd seem to say I should. The one thing that really does give me the creeps is adding someone else’s apt repository to my system-wide one. I just can’t seem to square that off in my head against my more laissez-afire “well do I trust them or not?” attitude that I take for every other installation attack vector. Maybe because it means trusting the third party forever, instead of just once?

kevin_thibedeau 4y ago
The problem with Pypi is the transitive dependencies. You may trust a high profile package but it could pull in any number of projects that are exploited by bad actors.
- freeqaz 4y ago
  This is a real problem that I believe will become increasingly commonly used by attackers to break into companies. Unfortunately, it's not an easy problem to automate the detection. There are some heuristics, but you're basically writing something like Norton Antivirus for Python packages lol. A sufficiently skilled attacker can make their code look totally innocent[0]. :) Source: Former security engineer at Uber/Snap that's now working on tooling in this space[1]. 0: "Underhanded C Competition" http://www.underhanded-c.org/ http://www.underhanded-c.org/ 1: Open Source "Supply Chain Security" platform https://github.com/lunasec-io/lunasec https://github.com/lunasec-io/lunasec
  - jollofricepeas 4y ago
    It’s already extremely common in the Python, Ruby and Node ecosystem (see sources below). The only company that has a real chance at making a dent in the issue is GitHub and to a degree they already have. SOURCES: - https://www.mandiant.com/resources/blog/supply-chain-node-js https://www.mandiant.com/resources/blog/supply-chain-node-js - https://www.zdnet.com/article/backdoor-found-in-ruby-library-for-checking-for-strong-passwords/ https://www.zdnet.com/article/backdoor-found-in-ruby-library... - https://www.reversinglabs.com/blog/mining-for-malicious-ruby-gems https://www.reversinglabs.com/blog/mining-for-malicious-ruby... - https://news.sophos.com/en-us/2021/10/24/node-poisoning-hijacked-package-delivers-coin-miner-and-credential-stealing-backdoor/amp/ https://news.sophos.com/en-us/2021/10/24/node-poisoning-hija... - https://www.bleepingcomputer.com/news/security/dev-corrupts-npm-libs-colors-and-faker-breaking-thousands-of-apps/amp/ https://www.bleepingcomputer.com/news/security/dev-corrupts-... - https://portswigger.net/daily-swig/amp/malicious-python-library-ctx-removed-from-pypi-repo https://portswigger.net/daily-swig/amp/malicious-python-libr...

jakear 4y ago

Funny, I thought about this today when installing Bun^. I read the bash script, saw that it was indeed downloading a release binary from the official GitHub repo, then gave up. The binary it downloaded could do absolutely anything when I run it, am I supposed to then go and verify every line of the source, and all its dependencies? Then verify the release package is the same as the one I make building it myself? Then verify the compiler source is a reasonable interpretation of the Zig spec (which doesn't seem to exist)? Then verify the complier binary I used is the same as the one created by a trusted compilers? Then verify all those binaries.... End of the day: the package is from a somewhat reputable source, and you don't keep life changing secrets user-accessible on your dev machine, fuck it. Also, resist installing as root. Figure out what the real permissions the thing needs are and go from there. ^https://bun.sh/ https://bun.sh/ (if you haven't been introduced: https://dl.acm.org/doi/pdf/10.1145/358198.358210 https://dl.acm.org/doi/pdf/10.1145/358198.358210)

Jarred 4y ago
Unfortunately it takes awhile to compile Bun from scratch. It doesn’t need root privileges though. To compile Bun completely from scratch, you’d need to compile: - Zig - mimalloc - libtcc - zlib - picohttpparser - sqlite3 - BoringSSL - WebKit’s JSCOnly port - libarchive - lol-html (+ rust) From there, you also need clang 13, which you might also want to compile from source (though that can take an hour or more). When compiling Bun in CI, many dependencies are compiled from source (excluding Rust, LLVM, and Zig)
- unsafecast 4y ago
  How does compiling it yourself change anything?
  - jakear 4y ago
    If all you do is download the release binary, anything could compromise you. If you read the source, an inauthentic release binary could compromise you. If you read the source and compile it, a compromised compiler could compromise you. If you read the compiler source, bootstrap compiling it from hardware code (reading all the source along the way), read the app source, and finally compile it using your compiled compiler, then compromised hardware could compromise you. Every step along the way you increase the severity of the statement "If I'm fucked, then so is everyone using X". You stop when the set of people using X grows so large than you are sufficiently worthless in comparison.

zX41ZdbW 4y ago

I've also thought about this problem but ended up with curl | sh: curl https://clickhouse.com/ | sh The arguments are: - it's 'sh', not 'sudo sh', so it's not that bad; - you can remove '| sh' and read the script; - the deb, rpm, tgz, and docker packages are also provided, but only as advanced usage; - nevertheless, all these packages, for all distributions, contain the same byte-identical ClickHouse binary. It works surprisingly well. Even people without experience can copy-paste this command and start using our software.

LinuxBender 4y ago
it's 'sh', not 'sudo sh', so it's not that bad; Along the lines of "curl | bash" detection, one can add "sudo -n" to see if the person has passwordless sudo. In my own testing I have found that many people have passwordless sudo. Even without sudo it turns out that people have bad posix permissions throughout their filesystem and one can hijack many things including existing SSH tunnels because of control-master. Even without sudo one can hop around a persons production network riding existing SSH channels. Many devops people have SSH multiplexing and control-master enabled in their SSH client. Then it is just a matter of finding bad permissions in production environments which is also often the case. One rarely needs root to download or even modify database contents as the database credentials are often stored in an environment file that gets sourced by automation. The biggest problem here I see is that companies rarely let their penetration testers a.k.a. red-team into production. Corporate leaders would be taken aback at the findings.
Kwpolska 4y ago
> - you can remove '| sh' and read the script; But why can’t I copy the URL into my browser? Why discriminate on user agent? Why couldn’t it be https://clickhouse.com/install.sh https://clickhouse.com/install.sh - so that it would work with browsers and curl alike? > - the deb, rpm, tgz, and docker packages are also provided, but only as advanced usage; How are deb and rpm advanced? How do I uninstall something installed with your custom script? Also, why are the RPM packages [0] still using /etc/init.d and not systemd? [0] https://clickhouse.com/docs/en/install/#from-rpm-packages https://clickhouse.com/docs/en/install/#from-rpm-packages

tomp 4y ago

> Installing software by piping from curl to bash is obviously a bad idea and a knowledgable user will most likely check the content first. I’ve yet to hear a coherent explanation why this is any worse than installing software from the internet in general. It’s not like you check the source of all software you install.

deleted 4y ago
[deleted]
ducktective 4y ago
If maintainers of the distro review their accepted packages thoroughly, then apt install would be superior to curl | bash But 9 out of 10 times I used apt install cargo, I've been bitten by dependency hell
jacooper 4y ago
I think its more that the packages are vetted by your distro, but this script isn't, and you don't know what's in it.
- tomp 4y ago
  Most software I install isn’t distro software, but Python binaries (python, mamba, numpy, pytorch) and packages via pip/mamba/conda.
LilBytes 4y ago
Source in this instance doesn't always mean source code but _the source were you're downloading it from_. If canonical.com tells me to curl $url | sh, I'm fairly confident the script Im downloading is safe. as much as an .iso, .bin or .exe would be. But I'd be a lot more hesitant doing the same from craigs-legit-swe-blog.com.
l33tman 4y ago
I guess it's a question of effort on the side of the person doing the trojan - if enough suckers just copy those snippets regularly you can be lazy and just do it like that, you don't need to go through the hassle of creating fake Ubuntu PPAs with trojans or distribute a big repo on GitHub and risk someone seeing the trojan part.

mootzville 4y ago

Seems like the best solution is to not use this technique. Been touching linux servers for 10+ years, and have never had to use it. I definitely used it when learning linux though. I curl to files for review when I need / want to run a remote script. A bonus is you still have to `chmod u+x some_remote.sh` before it can be run, so it would be extremely difficult to accidentally run.

mootzville 4y ago
Having said that, I write a lot of JS / Node. When you npm (a package manager for NodeJS) install something there could very well be some curl commands piping to bash or sh. Makes me think of an idea -- and maybe it exists -- create a npm package whose only purpose is to run checks on the code of the other packages being installed to ensure they are "safe".

digitalsushi 4y ago

I used to do this for a product... I was finding that some of it was apparently happening asynchronously. I had a separate shell function I grabbed from the first, with all the functions. I eventually put a variable at the bottom of it with a sentinel value, and from the first script, would block until that variable got populated, before running the main function. I think I'd always do it as an inline script. Admittedly I was slopping a lot of mud on the wall back then as a tactic.

alexiaa 4y ago

I think this could be avoided by using this syntax instead: bash < <(curl -fsSL example.com/foo.sh)

pornel 4y ago

Cleverness and sneakiness of this technique makes people laser-focus just the Hollywood-worthy hack, and forget the larger picture that it's about trusting the host not to pwn you. If you trust the host won't screw you, it doesn't matter how many style points they could have scored on something they won't do. If you don't trust the host, don't use it, because reviewing 10 lines of bash won't save you. • The sneakiness of this can be defeated with `tee` (or a variety of other ways like modified bash or a VM). • dpkg runs arbitrary package scripts as root, so you still put trust in whoever signed the package. • When you use `curl|sh` to install binary blob built from millions lines of code, it has countless other opportunities to include exploits with plausible deniability. If the host is hacked, they can put the payload in the binary, knowing you'll review the bash script like a hawk, and then YOLO the rest. • Targeted attacks can can use your IP too. • Your distro's overworked unpaid maintainer LGTMs packages with a glance, and won't review millions lines of code for backdoors. • There is a huge gap between what people imagine they could have theoretically done properly to keep things secure and gather evidence of any potential wrongdoing, and what they actually do.

ddtaylor 4y ago
> dpkg runs arbitrary package scripts as root, so you still put trust in whoever signed the package. This is correct, but in those cases the maintainer is likely a much more trusted individual where more eyes are on the script as the hierarchy of maintainers sign off on things until the point it makes it into a readily accessible repository by end-users. > Your distro's overworked unpaid maintainer LGTMs packages with a glance, and won't review millions lines of code for backdoors. The same argument could be made about the Linux kernel itself, yet the system is surprisingly robust and examples of abuse are few and far between.
Zuiii 4y ago
> people [..] forget the larger picture that it's about trusting the host not to pwn you It's not about that. It's about pushing back the trust boundary to be as close to the source as possible. Of course your upstream can compromise you if they turn malicious, but having your trust boundary needlessly extend all the way out to the web server is not only unnecessary but also introduces real dangers to users (unless you also consider Transmission's incident to be one of your "Hollywood-worthy" hacks). I'm glad people are rightfully criticizing this stupid approach. I'm glad most reputable systems use off-line signatures to verify software before running it. Security is not about absolutes. It's about thresholds.

blacklion 4y ago

I don't understand, why do people throw in trash can one of the strongest Linux features: package management. Left aside security implications of "curl | bash" installation - what will you do if installation fails and you need to roll-back partial changes to system? How will you update this software? How will you uninstall in the future? How will you track CVEs for it, if your package manager doesn't know about its existence and all periodic scripts of your distro can not check for CVEs? How you will update libraries used by this software, are you sure this will not broke it?

tylergetsay 4y ago
This is what has been pushing Arch Linux and the AUR for me
bigDinosaur 4y ago
Extreme simplicity. This is the installation equivalent to updating your website by scp-ing in a new index.html.
- blacklion 4y ago
  To be honest, if you site is static-generated (where "generated" includes "typed by you in text editor") this approach hasn't any drawbacks to more complex schemes. Installing software via running random scripts has a ton of drawbacks to using system package manager.
marcosdumay 4y ago
Linux needs an normal-user package manager.
- londonReed 4y ago
  Almost all package managers have a graphical front end. I'm not sure how that's not "Normal user" oriented. Windows even has a "Windows Store" bastardized version of a package manager,

Makhini 4y ago

As a side note: the culture or installing stuff via curl is like a virus. If you check the npm docs, they say "We strongly recommend using a Node version manager like nvm to install Node.js and npm". Then if you check nvm docs, the primary installation method is curl to bash, and not even from their official website - it pulls stuff from github...

fbrusch 4y ago

A way to fix this is via content addressable distribution protocols such as IPFS (maybe supported by a trasparent name system like ENS).

deleted 4y ago

[deleted]

fburnaby 4y ago

I have been getting tired of node dependencies and not knowing what I'm running or when it will break. I make simple things for small number of users and started playing with just writing my own CGI in C++ or bash behind thttpd. This appears to be working very well so far and runs on a vanilla Linux install with deps just on system libs and gcc. With all the pain and unsafety of deps, this might actually make most sense. What new vulnerabilities am I inviting? Why aren't we still doing things this way? It seems... much easier, perhaps not to make it but to secure and sustain it.

rcarr 4y ago

If dependency hell is pretty much unavoidable at this point, is the best solution for everyone to have something like Little Snitch or similar installed that monitors for unusual outgoing traffic so that the hackers can't get away with it for very long before getting shut down? And to do all high risk activity like coding in VMs?

fargle 4y ago

wouldn't it be a whole lot easier for the script being curled to just detect it was running as part of a `curl | bash` pipeline and bail out with a message? if [ ! -t 0 ]; then echo "script must be run interactively, etc."; exit 1; fi of course that's equally useless because as someone else said, the root problem with doing `curl | bash` in the first place is that you are putting the trust in someone else's server, so you can't fix that "server side". what the article is proposing is a whole lot of magic detect `curl | bash` from his safe server, where's it's already safe.