3 ms·

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

> 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 ago
People 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 ago
  No, 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.
  - eridius 10y ago
    It's not a wildly bad idea. You are seriously out of touch with how most people use computers if you think that. Very few people actually read every script they execute, and if it's a binary exe, they can't even do that. Whether or not you choose to execute software you downloaded depends entirely on your trust in the vendor and in the delivery process. If you trust the vendor to provide you with something you're willing to execute, then it really doesn't matter how you go about executing it either. Downloading it first and then executing it is no safer than piping it to bash. All it does is give you the option of reading it first, but as I said above, almost nobody actually does that. > The correct thing to do is distribute via cryptographically signed archives or packages, or via signed git tags. And now you have the problem of trusting the key instead of trusting the delivery mechanism. This approach works well for package managers because the user's trust in the package manager implicitly trusts the keys the package manager uses to verify all the software it downloads, but it doesn't work all that well for software distributed directly to end users, because very few people even know how to verify the signature, let alone figure out whether or not they should trust the key it was signed with. After all, the fact that it's signed doesn't mean anything, what's important is whether it's signed with a key that is trusted as belonging to the vendor (and is assumed to not have been compromised). > 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. "Read the script before executing it" is a really really crappy layer. That assumes that you understand shell scripting, that the script is simple enough to actually be reasonable to skim through it and understand what it's doing, and that the hypothetical attacker hasn't figured out how to disguise their modifications to make it not immediately obvious to someone skimming the code. As previously stated, almost nobody actually does this. And once you've determined that, no, you're not going to read through every line of the shell script that you're using to install the software, then `curl | sh` is perfectly fine as long as you trust the delivery mechanism (e.g. https). At this point the only thing you've lost is the ability to verify code signatures, but people don't generally sign their shel scripts anyway, and also as previously stated, even if they did not very many people understand how to actually validate it and how to verify that they have a trusted key. GPG is really not user-friendly at all. I guess what it really comes down to is, use a delivery mechanism that handles all this for you if you can (such as a package manager). If you can't, then the only real question is "do I trust this vendor and delivery mechanism enough to run something I just downloaded on my machine?"
inimino 10y ago
People paranoid enough to download it and read it are more likely to run what they just read. Why would you download it again? curl >x cat x . x However, the point is that if you can't trust the publisher it doesn't make any difference what the installation procedure is.
- inimino 10y ago
  Sorry for the formatting: curl >x less x . x
- alphapapa 10y ago
  What? I feel like you're not thinking about this very carefully. Someone might look at the downloaded script and verify that it is harmless. Then they might run it. Then later they might go to another system they want to install it on, and they might think, "Well, I looked at it a few minutes ago, and it was fine, so now I'll just pipe it to the shell like the web site says to do." Or they might recommend the software to someone else, and they might say, "Hey by the way, I verified that the install script is safe, so you can pipe it straight to a shell like the site says." > However, the point is that if you can't trust the publisher it doesn't make any difference what the installation procedure is. That's not correct. A MitM attack is a risk even if the publisher is trustworthy. This is not complicated--in theory, at least: only distribute cryptographically signed software. Anything else leaves you vulnerable to many attack vectors. And anyone who instructs users to pipe to a shell is irresponsible and encouraging Worst Practices.
  - inimino 10y ago
    I feel like you missed the point of what I wrote. Yes, there are things people could do where if the site owner is malicious they could get screwed. That is generally what happens when you install software from untrustworthy sources. > > However, the point is that if you can't trust the publisher it doesn't make any difference what the installation procedure is. > That's not correct. A MitM attack is a risk even if the publisher is trustworthy. You're contradicting something that I didn't write.

eridius 10y ago

People 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 ago
No, 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.
- eridius 10y ago
  It's not a wildly bad idea. You are seriously out of touch with how most people use computers if you think that. Very few people actually read every script they execute, and if it's a binary exe, they can't even do that. Whether or not you choose to execute software you downloaded depends entirely on your trust in the vendor and in the delivery process. If you trust the vendor to provide you with something you're willing to execute, then it really doesn't matter how you go about executing it either. Downloading it first and then executing it is no safer than piping it to bash. All it does is give you the option of reading it first, but as I said above, almost nobody actually does that. > The correct thing to do is distribute via cryptographically signed archives or packages, or via signed git tags. And now you have the problem of trusting the key instead of trusting the delivery mechanism. This approach works well for package managers because the user's trust in the package manager implicitly trusts the keys the package manager uses to verify all the software it downloads, but it doesn't work all that well for software distributed directly to end users, because very few people even know how to verify the signature, let alone figure out whether or not they should trust the key it was signed with. After all, the fact that it's signed doesn't mean anything, what's important is whether it's signed with a key that is trusted as belonging to the vendor (and is assumed to not have been compromised). > 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. "Read the script before executing it" is a really really crappy layer. That assumes that you understand shell scripting, that the script is simple enough to actually be reasonable to skim through it and understand what it's doing, and that the hypothetical attacker hasn't figured out how to disguise their modifications to make it not immediately obvious to someone skimming the code. As previously stated, almost nobody actually does this. And once you've determined that, no, you're not going to read through every line of the shell script that you're using to install the software, then `curl | sh` is perfectly fine as long as you trust the delivery mechanism (e.g. https). At this point the only thing you've lost is the ability to verify code signatures, but people don't generally sign their shel scripts anyway, and also as previously stated, even if they did not very many people understand how to actually validate it and how to verify that they have a trusted key. GPG is really not user-friendly at all. I guess what it really comes down to is, use a delivery mechanism that handles all this for you if you can (such as a package manager). If you can't, then the only real question is "do I trust this vendor and delivery mechanism enough to run something I just downloaded on my machine?"

inimino 10y ago

People paranoid enough to download it and read it are more likely to run what they just read. Why would you download it again? curl >x cat x . x However, the point is that if you can't trust the publisher it doesn't make any difference what the installation procedure is.

inimino 10y ago
Sorry for the formatting: curl >x less x . x
alphapapa 10y ago
What? I feel like you're not thinking about this very carefully. Someone might look at the downloaded script and verify that it is harmless. Then they might run it. Then later they might go to another system they want to install it on, and they might think, "Well, I looked at it a few minutes ago, and it was fine, so now I'll just pipe it to the shell like the web site says to do." Or they might recommend the software to someone else, and they might say, "Hey by the way, I verified that the install script is safe, so you can pipe it straight to a shell like the site says." > However, the point is that if you can't trust the publisher it doesn't make any difference what the installation procedure is. That's not correct. A MitM attack is a risk even if the publisher is trustworthy. This is not complicated--in theory, at least: only distribute cryptographically signed software. Anything else leaves you vulnerable to many attack vectors. And anyone who instructs users to pipe to a shell is irresponsible and encouraging Worst Practices.
- inimino 10y ago
  I feel like you missed the point of what I wrote. Yes, there are things people could do where if the site owner is malicious they could get screwed. That is generally what happens when you install software from untrustworthy sources. > > However, the point is that if you can't trust the publisher it doesn't make any difference what the installation procedure is. > That's not correct. A MitM attack is a risk even if the publisher is trustworthy. You're contradicting something that I didn't write.