Comment by godelski
19 hours ago
Wow, the rare
bash <(curl foo.sh)
pattern. As opposed to the more common
curl foo.sh | bash
Equivalent but just as unsafe. If you must do this instead try one of these
# Gives you a copy of the file, but still streams to bash
curl foo.sh | tee /tmp/foo.sh | bash
# No copy of file but ensures stream finishes then bash runs
bash -c "$(curl foo.sh)"
# Best: Gives copy of file and ensures stream finishes
curl foo.sh -o /tmp/foo.sh && bash $_
I prefer the last one
> Equivalent but just as unsafe.
To my understanding, the main difference between "curl directly to bash" and "curl to a temp file, then execute the temp file" is "the attacker could inject additional malicious commands when curl'd directly to bash".
If you're not going to then also read all the source code from the download script (& the source code used to produce the binaries), this suggests the attitude of "I mistrust anything I can't read; but will trust anything I could read (without having to read it)".
It seems more likely that malicious code would be in a precompiled binary, compared to malicious commands injected into "curl to bash". -- Though, if there have ever been any observed cases of a server injecting commands from "curl ... | tee foo | bash", I'd be curious to know about these.
>> Equivalent but just as unsafe.
> To my understanding, the main difference between "curl directly to bash" and "curl to a temp file, then execute the temp file"...
It's not a temp file in the sense of a regular file. `<()` is also a pipe, hence equivalent. `curl` and `bash` run concurrently.
Running one after the other wouldn't be all that much of an improvement anyway if it's done automatically. One really should manually review the script before running it.
There's another issue actually. You're streaming, so ask yourself what happens if the stream gets cut prematurely. I'll give you an example, consider how this like could be cut prematurely to create major issues
A malicious attacker doesn't need to inject code, they can just detect the stream and use a line like the above to destroy your filesystem. Sure, you might preserve root but `rm -rf /home` is for all practical purposes destroying the computer's data for most people
Or it doesn't have to be malicious. It can just happen. The best protection is writing functions since those have to be created and so can't execute until fully streamed. But so much bash is poorly written that well... just check out Anthropic's install script...
Saving the source code still has a benefit. If something does go wrong you can go read it. Probably a good place to start tbh. In fact, if you're streaming and something goes wrong you'll see exactly what the early termination error did.
Is it good security practice? Absolutely not. Is it a hundred times better than curl-pipe-bash? Absolutely.
Uses standard tmp files, makes sure it's writable (tmp file creation can fail), checks cryptographic hash before executing
Sure, but now we're not playing code golf. There's much better commands than the ones I wrote but good luck getting people to run them
Agreed. People would rather have a cute looking command to copy than security or reliability
If you want to be super pedantic, try to make the command shell-agnostic in case the user is not running bash already.
Everything I wrote works in bash and zsh. I think this is going to be fine for the vast majority of people. Tbh, I'm not sure what isn't portable, or at least not portable for everything that the curl-pipe-bash pattern doesn't already work for.
`curl foo.sh | bash` works with any shell as long as bash is installed. `bash <(curl foo.sh)` doesn't work on shells that don't have that process substitution syntax (like fish, and I think nushell)
[dead]