3 ms·

If you're technical enough to answer that, then you're technical enough to know that security by default is better.

by noja 4y ago

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

If you're technical enough to answer that, then you're technical enough to know that security by default is better.

by noja 4y ago

If you're technical enough to answer that, then you're technical enough to know that security by default is better.

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