Hacker News Reader

Comment by bogwog | Hacker News Reader

This type of thing needs to stop

"Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead."

https://news.ycombinator.com/newsguidelines.html

Why? If it's over TLS you can trust it's being served by the owner of the website. You're having to trust the person who wrote the script anyway. And before anyone says "I'm going to inspect the shell script before I run it", do also note that its purpose is to download and run binaries that you are never going to inspect.

True, the only real counterpoint is someone who clones the repo, inspects it, and builds from source.

Do you really own your own operating system if you haven't compiled the kernel yourself?

Even if you do compile the kernel yourself, do you really own your OS if you haven't compiled the compiler yourself? Did you use a pre-built compiler binary to compile the compiler?

Now we're getting to the real questions in life. :)

(Incidentally, this is probably the most fundamental software supply chain attack vector - manipulate the compiler binary used to compile the compiler used to compile the kernel and userspace. The attack payload would never appear in any sources, but would always be present in binaries.)

A little late but an obligatory read:

https://www.quora.com/What-is-a-coders-worst-nightmare/answe...

IMO the main problem is that it isn't clear how updates will work. Some of the curl-to-bash scripts don't do anything in regards to updates at all, some add a PPA/similar on ubuntu/debian/fedora/etc.

It'd be nice to know what and how I should manage updates.

You could add additional security to the process by first validating some cryptographic signature or verifying that the downloaded content's hash matches one that the author published.

Both of those just push the overall security a bit down the line, but both are ultimately not completely safe. The only truly safe action to take is to not download it at all.

The other thing to be careful about is that the script is written in a way that a truncated script has no effect. This is because sh will execute the stdin line-by-line as it reads it, so if the download fails in the middle of a line the downloaded fragment of that line will be executed.

It can be the difference between `rm -rf ~/.cache/foo` and `rm -rf ~/`

The standard way to solve this problem is to put the entire script inside a function, invoke that function in the last line of the script (as the only other top-level statement other than the function definition), and name it in such a way that substrings of the name are unlikely to map to anything that already exists. Note that the bun.sh script does not do this, but also from a quick glance the only thing that could noticeably go wrong is this line:

    rmdir $bin_dir/bun-${target}

A truncated download could make it run `rmdir $bin_dir` instead, in which case it'll end up deleting ~/.bun instead of ~/.bun/bin/bun-${target}, which is probably not a big deal.

someone demonstrated a while back how based on user agent you could serve innocuous code for a browser checking the code first, and then a different malicious payload for curl.

thanks to dementiapatien below for the link https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

Yeah, people should be using fish! /s

Ok, let's say I have a experimental tool I want to distribute to people with a easy install. What way would you prefer to install it?

Going through package registries/repositories is a slow process, so obviously want something faster.

Just GitHub releases? Would you be fine if the URL instead pointed to GitHub in that case?

All I want is a download link to a single .exe. Or a zip if it has runtime content/dependencies. GitHub release is fine.

So then Bun is doing fine here? They have GitHub Release activated and are using it for releases.

Looks like it! I answered your question as stated. Which was a general question and not specific to Bun.

I disagree. This reduces friction for users. Users should be aware of what/who they are trusting.

And we need to ban binary downloads from vendor sites as well, as those pose the exact same risks? Good luck with that!

Techniques like this could make curl|bash more prone to malicious activity: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

You're running untrusted binaries anyway in the end, so I don't think this is anything more than a neat party trick.

But this technique lets you serve malicious code to a small number of people using curl|bash, rather than hosting obviously-bad binaries that anyone can inspect and call you out on. It also lets you target the attack to specific users or IP blocks.

The previous HN discussion said it better than I can: https://news.ycombinator.com/item?id=17636032

Moreutils has two programs that would trivially defeat this:

`sponge` reads the full input before passing it on

`vipe` inserts your editor inline, so you can view/modify the input before passing it on to bash (change an install directory, etc)

Reply on news.ycombinator.com