4 ms·

Ahh yes, let me just run curl ... | bash

scubbo 4y ago
If you're savvy enough to know why that's potentially dangerous, you're savvy enough to pipe to an intermediate executable file to inspect the code.
- noja 4y ago
  If you're technical enough to answer that, then you're technical enough to know that security by default is better.
  - scubbo 4y ago
    No, I'm sorry, I seriously don't understand how that applies in this case. How is "trusting the content you get from `apt-get`/`dpkg`/`pacman`" safer than curling-to-bash? In both cases, you are downloading and installing content from a trusted source (assuming you are curling via https to avoid MITMs). In the curl-to-bash case, you have the _ability_ to at least inspect the code first before you install it (though, realistically, how many folks would really have the dedication and the ability to do so?), whereas with package managers you're installing "blind". Doesn't that make curling-to-bash the _safer_ option? I clearly must be missing something, here, because everyone decries "curling-to-bash" as a bad security practice, but I haven't seen an explanation of _why_. I tried doing some research for myself - this page[1] suggests that package managers have built-in checksumming and signature verification, but then goes on to propose an attack vector where the load balancer is compromised, so (presumably?) those same checksums/signatures could also be intercepted and faked. This gist[2] has a lot of people speaking against it, but from following those links, the only downside I could see was here[3], pointing out that the shell will keep executing if a connection closes mid-stream - which, yes, is certainly a bad thing and a good argument to use package managers, but not what I would call a security concern (unless you don't trust the entity on the other end of the stream - and, again, I'm taking that as a prerequisite both for `curl | bash` and for using package managers). This[4] demonstrates that a server can detect `curl | bash` and render differently - but, again, if you trust the entity at the other end, that's not an issue. This is a genuine question, not a fight - you clearly know more about this than me, so I'm asking for your perspective, not challenging you. I recognize that there are non-security flaws to `curl | bash` (handling updates, handling unreliable connections), but I don't see how it's a security concern. How would a malicious attacker exploit someone doing a `curl | bash` from a trusted location over https? [1] https://sysdig.com/blog/friends-dont-let-friends-curl-bash/ https://sysdig.com/blog/friends-dont-let-friends-curl-bash/ [2] https://gist.github.com/btm/6700524 https://gist.github.com/btm/6700524 [3] https://www.seancassidy.me/dont-pipe-to-your-shell.html https://www.seancassidy.me/dont-pipe-to-your-shell.html [4] https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
- kobalsky 4y ago
  there's usually a simple apt-get behind that, but this is not the case. clearly they went through a we-dont-need-apt-just-for-this phase and things got out of hand. there's like a dozen scripts to handle installation of scripts, crons, services and to handle their lifecycle. check this uninstall script https://github.com/mcguirepr89/BirdNET-Pi/blob/main/scripts/uninstall.sh https://github.com/mcguirepr89/BirdNET-Pi/blob/main/scripts/... they need someone to do their apt packaging like yesterday.

If you're savvy enough to know why that's potentially dangerous, you're savvy enough to pipe to an intermediate executable file to inspect the code.

noja 4y ago
If you're technical enough to answer that, then you're technical enough to know that security by default is better.
- scubbo 4y ago
  No, I'm sorry, I seriously don't understand how that applies in this case. How is "trusting the content you get from `apt-get`/`dpkg`/`pacman`" safer than curling-to-bash? In both cases, you are downloading and installing content from a trusted source (assuming you are curling via https to avoid MITMs). In the curl-to-bash case, you have the _ability_ to at least inspect the code first before you install it (though, realistically, how many folks would really have the dedication and the ability to do so?), whereas with package managers you're installing "blind". Doesn't that make curling-to-bash the _safer_ option? I clearly must be missing something, here, because everyone decries "curling-to-bash" as a bad security practice, but I haven't seen an explanation of _why_. I tried doing some research for myself - this page[1] suggests that package managers have built-in checksumming and signature verification, but then goes on to propose an attack vector where the load balancer is compromised, so (presumably?) those same checksums/signatures could also be intercepted and faked. This gist[2] has a lot of people speaking against it, but from following those links, the only downside I could see was here[3], pointing out that the shell will keep executing if a connection closes mid-stream - which, yes, is certainly a bad thing and a good argument to use package managers, but not what I would call a security concern (unless you don't trust the entity on the other end of the stream - and, again, I'm taking that as a prerequisite both for `curl | bash` and for using package managers). This[4] demonstrates that a server can detect `curl | bash` and render differently - but, again, if you trust the entity at the other end, that's not an issue. This is a genuine question, not a fight - you clearly know more about this than me, so I'm asking for your perspective, not challenging you. I recognize that there are non-security flaws to `curl | bash` (handling updates, handling unreliable connections), but I don't see how it's a security concern. How would a malicious attacker exploit someone doing a `curl | bash` from a trusted location over https? [1] https://sysdig.com/blog/friends-dont-let-friends-curl-bash/ https://sysdig.com/blog/friends-dont-let-friends-curl-bash/ [2] https://gist.github.com/btm/6700524 https://gist.github.com/btm/6700524 [3] https://www.seancassidy.me/dont-pipe-to-your-shell.html https://www.seancassidy.me/dont-pipe-to-your-shell.html [4] https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
kobalsky 4y ago
there's usually a simple apt-get behind that, but this is not the case. clearly they went through a we-dont-need-apt-just-for-this phase and things got out of hand. there's like a dozen scripts to handle installation of scripts, crons, services and to handle their lifecycle. check this uninstall script https://github.com/mcguirepr89/BirdNET-Pi/blob/main/scripts/uninstall.sh https://github.com/mcguirepr89/BirdNET-Pi/blob/main/scripts/... they need someone to do their apt packaging like yesterday.