3 ms·

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 t

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

wakawaka28 8mo ago
If you want to be super pedantic, try to make the command shell-agnostic in case the user is not running bash already.
- godelski 8mo ago
  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.
  - cgfjtynzdrfht 8mo ago
    [dead]
  - maleldil 8mo ago
    `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)
    - godelski 8mo ago
      Okay so doesn't work for fish or dash but who is using those? More importantly, who is using those and doesn't know how to convert? It really just seems like you're trying to start a fight and I don't know why. If you're going to fight with anyone go actually click the link and fight with the one who started it
  - wakawaka28 8mo ago
    I'm not sure either but some of those things are bashisms. `<(...)` is a bashism and won't work in some shells. Honestly I ONLY use bash, so it's fine for me, but since you seem to be a pedantic person I thought you should consider trying to solve that puzzle too. Someone might want to copy and paste your command into csh, tcsh, zsh, sh, or ksh. Some of these may support bashisms and some don't. I haven't tried to investigate further either, even to the point of talking to an AI about it, but if you want max nerd cred then you can shoot for it. Keep in mind that csh/tcsh is not entirely POSIX compliant, but it is default on some BSDs.
    - godelski 8mo ago
      Fwiw it works in zsh and I believe ksh (haven't checked). There's not many people that run csh, tcsh, sh, ksh, or even fish. I could be more pedantic but I'll trade for practicality. I'm sure we could even do better than this [0] but the problem exists because people are lazy. If you got something that is portable and fits a code-golf like mentality then I'm all ears. There's bigger problems with the lines I wrote besides portability. They don't stop malicious actors nor provide any security. At best they provide defense against early termination and a log to help debug any damage that was done. Not prevent it. Which those are solvable things! But they're solved by more effort, which unfortunately is a losing battle. So the task isn't to solve all the problems, it's to find something that people might actually do that might actually provide some harm reduction, even if it isn't much. Something is better than nothing, right? [0] https://news.ycombinator.com/item?id=47107740 https://news.ycombinator.com/item?id=47107740
0xbadcafebee 8mo ago
t=$(mktemp) && [ -w $t ] && curl foo.sh -o $t && echo "$t lksjdfkljshdkfljhdsklfjhslkdjfhsdlkjfhslkdjhf" | sha256sum -c - && bash $t Uses standard tmp files, makes sure it's writable (tmp file creation can fail), checks cryptographic hash before executing
- godelski 8mo ago
  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
  - 0xbadcafebee 8mo ago
    Agreed. People would rather have a cute looking command to copy than security or reliability
rgoulter 8mo ago
> 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.
- godelski 8mo ago
  > the attacker could inject additional malicious commands when curl'd directly to bash 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 rm -rf /home/theuser/.config/theprogram/build_dir 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... > If you're not going to then also read all the source code 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.
- jolmg 8mo ago
  >> 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.

wakawaka28 8mo ago

If you want to be super pedantic, try to make the command shell-agnostic in case the user is not running bash already.

godelski 8mo ago
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.
- cgfjtynzdrfht 8mo ago
  [dead]
- maleldil 8mo ago
  `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)
  - godelski 8mo ago
    Okay so doesn't work for fish or dash but who is using those? More importantly, who is using those and doesn't know how to convert? It really just seems like you're trying to start a fight and I don't know why. If you're going to fight with anyone go actually click the link and fight with the one who started it
- wakawaka28 8mo ago
  I'm not sure either but some of those things are bashisms. `<(...)` is a bashism and won't work in some shells. Honestly I ONLY use bash, so it's fine for me, but since you seem to be a pedantic person I thought you should consider trying to solve that puzzle too. Someone might want to copy and paste your command into csh, tcsh, zsh, sh, or ksh. Some of these may support bashisms and some don't. I haven't tried to investigate further either, even to the point of talking to an AI about it, but if you want max nerd cred then you can shoot for it. Keep in mind that csh/tcsh is not entirely POSIX compliant, but it is default on some BSDs.
  - godelski 8mo ago
    Fwiw it works in zsh and I believe ksh (haven't checked). There's not many people that run csh, tcsh, sh, ksh, or even fish. I could be more pedantic but I'll trade for practicality. I'm sure we could even do better than this [0] but the problem exists because people are lazy. If you got something that is portable and fits a code-golf like mentality then I'm all ears. There's bigger problems with the lines I wrote besides portability. They don't stop malicious actors nor provide any security. At best they provide defense against early termination and a log to help debug any damage that was done. Not prevent it. Which those are solvable things! But they're solved by more effort, which unfortunately is a losing battle. So the task isn't to solve all the problems, it's to find something that people might actually do that might actually provide some harm reduction, even if it isn't much. Something is better than nothing, right? [0] https://news.ycombinator.com/item?id=47107740 https://news.ycombinator.com/item?id=47107740

0xbadcafebee 8mo ago

t=$(mktemp) && [ -w $t ] && curl foo.sh -o $t && echo "$t lksjdfkljshdkfljhdsklfjhslkdjfhsdlkjfhslkdjhf" | sha256sum -c - && bash $t Uses standard tmp files, makes sure it's writable (tmp file creation can fail), checks cryptographic hash before executing

godelski 8mo ago
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
- 0xbadcafebee 8mo ago
  Agreed. People would rather have a cute looking command to copy than security or reliability

rgoulter 8mo ago

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

godelski 8mo ago
> the attacker could inject additional malicious commands when curl'd directly to bash 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 rm -rf /home/theuser/.config/theprogram/build_dir 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... > If you're not going to then also read all the source code 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.
jolmg 8mo ago
>> 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.