6 ms·
I had this conversation with a person on reddit just the other day. After I pointed that there is no difference between piping a script directly into bash and d
by wang_li 10y ago
I had this conversation with a person on reddit just the other day. After I pointed that there is no difference between piping a script directly into bash and downloading a package and installing it, they told me that they can audit a script/package they download and that they have personally audited every bit of code on their linux box. The kernel, gnome and metasploit.
I got to thinking what it would take to do such a task, and mainly what I came up with was a whole damned lot of time. Assuming a person can read, understand and remember 5000 lines of code per day (which honestly I think is way more than is realistic), it'd only take 8.5 years to audit the linux kernel. Add in all the other stuff and I figure something on the order of two decades. And in the end you'd be running two decade old software or you'd have to start over.
At the end of the day, security comes from the personal and corporate economics of reputation, profit, and prison avoidance. Do your best to get your stuff from people who you judge to be trustworthy and rely on their own self interest to not be malicious and to do their best to protect their repositories. And rely on others to be good citizens and report the bad shit that happens to them so that things can be cleaned up.
Now I'm not saying to throw out security best practices, but people should be aware that the quality of their systems are built on trust in human nature and self interest.
- contingencies 10y agoThere are better strategies than blindly relying on third party reputation. A primary approach is package management with hash databases, to ensure you are receiving the same code as others. Another is the use of multiple implementations whose results are compared, recently discussed @ https://news.ycombinator.com/item?id=12666923 https://news.ycombinator.com/item?id=12666923
- wang_li 10y agoYou're still relying on the source to not be underhanded and malicious. Getting the same, reproducible build as everyone else only means you've got a lot of company. It doesn't mean there isn't malicious code or intentional "bugs."
- contingencies 10y agoYou are right, though with hashing you've got effective post-release protection against a compromised source injecting malicious data at the very least, which these days is probably more likely than an outright malicious source for most major packages. So it's not without value. The second approach, more of an architectural workaround than a true solution, can still be used to insulate from major issues.
- seanp2k2 10y agoYou can do that with curl + bash too. RVM does this: https://rvm.io/rvm/security https://rvm.io/rvm/security
- ams6110 10y agoA downloaded installer can be signed, and you can verify signatures or at least checksums out-of-band.
- recursive 10y agoThat just asserts that it's the same series of bytes that was originally provided. You still have to trust the provider.
- njharman 10y agoRight, we know that security is a gradient, do you? There is a quantitative difference between covering your laptop under a coat and locking the car doors and leaving it on bench when you take a walk around park. Just as there is difference between piping the internet to root shell and installing a signed package that has whole ecosystem and many users validating and looking at it.
- deleted 10y ago[deleted]
- foota 10y agoIn fairness, ssl from a trusted host is pretty similar.
- na85 10y agoAt least you avoid javascript pastejacking in this manner.
- myhf 10y agoYou always have to trust the provider. If you don't authenticate the message you also have to trust every carrier.
- falcolas 10y agoYou're trusting the provider of the program, not the provider of the server. Curl/bash from github? You're trusting Github to provide the correct content; there have been times before where people have been able to spoof other users. Signatures on the package (or the code) would prevent an issue like this.
- deleted 10y ago[deleted]
- alphapapa 10y ago> there is no difference between piping a script directly into bash and downloading a package and installing it Well then I guess you haven't seen this, in which the server detects whether the script is being downloaded to disk or piped to a shell, and adjusts the payload accordingly: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b... i.e. when you download to disk and look at it, it looks benign, but when you pipe it to a shell, you get owned. Just say no to curl|sh, kids.
- eridius 10y agoPeople who pipe it to a shell aren't going to look at it anyway. That's kind of the point. If they were, they'd download it first. There is literally no security gained by downloading it and running it, instead of just `curl|sh`. IF it's malicious, you just installed it either way. The only thing downloading does in this scenario is lets you look at the script later on when you realize it might have been malicious, but that's even assuming you kept it (I would wager that almost everybody would throw away the script after installing it if they weren't planning on reading it before installation), and assuming you know enough to understand its contents (not everybody knows bash scripting, and you can write some surprisingly complex scripts).
- alphapapa 10y agoNo, the point is that installing software by either downloading and executing shell scripts or piping shell scripts directly to the shell is a wildly bad idea. And the ancillary point is that piping directly to the shell is worse, because it allows an attacker to exploit any false sense of security a user might have from having looked at the downloaded version of the script (whether that's that user specifically or someone else who did so and vouches for it). The correct thing to do is distribute via cryptographically signed archives or packages, or via signed git tags. Again, just say no to curl|sh, and also just say no to downloading and executing unverified shell scripts. Really, what are you arguing for here? Security is a process that involves layers, and you seem to be advocating for tossing all the layers aside because layer A doesn't protect against attack method B.
- edwintorok 10y agoWhat if the download gets interrupted due to network error and bash runs something else than what was intended. E.g. the script has: rm -rf /tmp/something But when the pipe gets interrupted it executes: rm -rf /
- plorkyeran 10y agoThe body of the shell script should be wrapped in a function which is invoked at the end. If you do not trust them to get this incredibly basic thing right, how can you possibly trust any of the other code they have written?
- _nalply 10y agosandstorm.io said: «If the connection dies mid-line, bash will execute the incomplete line – however, this can be mitigated by wrapping the whole script in a bash function executed on the last line, as we do.» (Source: https://sandstorm.io/news/2015-09-24-is-curl-bash-insecure-pgp-verified-install https://sandstorm.io/news/2015-09-24-is-curl-bash-insecure-p...)
- RealityVoid 10y agoSoo, maybe a silly question... but are downloads from the internet always "linear"? Meaning they go uninterrupted from start to end and if it drops it will stop in the middle of the downloaded file? Doesn't it get "pieces" and then place them together?