5 ms·

I'm sorry for being snarky, but something seems funny to me about piping something straight from github through bash to check for a security flaw.

orblivion 12y ago
(Oh actually, you could probably do it pretty safely with a guest account.)
peteretep 12y ago
Why does piping commands in to bash from the internet take on a magical security significance for people who run software they haven't audited literally all the time?
- zorpner 12y ago
  In the case of a network interruption, a command could become truncated with potentially destructive results.
  - hetman 12y ago
    That would result in a broken pipe and the command being aborted. We're not dumping raw datagrams here...
    - 0x0 12y ago
      https://news.ycombinator.com/item?id=8385374 https://news.ycombinator.com/item?id=8385374
- e12e 12y ago
  You don't see the difference between running an exploit to check if you're vulnerable to a security bug, and running software provided by your upstream distribution?
  - peteretep 12y ago
    No, I don't see why people who run open source code from a variety of sources think that there's something magically insecure about downloading it and executing it using curl and bash.
- zurn 12y ago
  This is a good question to think about, especially if it makes you consider more carefully about what software you run! But there's a lot of spectrum between "i have audited this software" and "i'm just piping this random url off the web to my shell". Many software distribution mechanisms provide varying degrees of curation, reputation, accountability etc. Also in this case the link was provided in a context that would select for people who are concerned about security updates (= looking after high value systems) and still somewhat naive about security practices, and could get run on systems that have strict rules about installing software on them.
- heavenlyhash 12y ago
  Perhaps the parent commenter doesn't run software without audit. There's no reason to presume defeat -- It's wholly possible to run a modern system using only signed builds from trusted sources and compile-from-source from everything else. Certainly, one can't audit every line, but just as certainly, one can establish a train of trusted sources and audit the rest (like this tiny snippet of bash, which is so utterly trivial to verify you might as well polish the habit on it).
christiangenco 12y ago
I'm in the same boat. Though I see the argument that I'm running code I haven't audited all the time, there's something about a bash script in particular that gives me worry. I don't know how rational this is, but I feel like the author could switch the code momentarily to something exploitive, wait for N downloads, then switch it back. I'm not sure how you could gather evidence that this even happened, since the nature of `curl -s URL | bash` is so transient. I'd rather take an extra few seconds to do: $ curl https://raw.githubusercontent.com/hannob/bashcheck/master/bashcheck > bashcheck.sh $ cat bashcheck.sh # nothing fishy $ chmod +x bashcheck.sh && ./bashcheck.sh
- floatingatoll 12y ago
  You're better off using any text editor - cat will display ANSI terminal codes unescaped in many situations, which can inhibit your ability to see code that might otherwise be hidden by # ^[[<wipe to beginning of line> or somesuch appended to a malicious bit.
  - teddyh 12y ago
    “cat” will display all bytes unescaped – that’s its job. The correct command in this case would be “less” (or any other pager, or possibly editor).
    - treve 12y ago
      Well since you went for a technical argument... if you really want to get technical.. it doesn't display anything and just sends the raw bytes to a stream. It doesn't 'display' all bytes, because not all bytes are displayable. hexdump would do a better job there.
- ClashTheBunny 12y ago
  We could at least reference a known good version by hash. This is at least a little more secure. But considering that Github could have been compromised by this bug, I would probably not pipe much from them until I know more about them not being compromised. Isn't running a jailed git server over ssh one of the great exploits of this bug?
k_bx 12y ago
It's https, so no worries.
- dllthomas 12y ago
  Still potentially vulnerable to truncation, though I don't know that that could actually cause a problem with this payload. And of course, habits like this could quickly propagate infection if a trusted source is compromised (though there are certainly plenty of other habits that share that characteristic).

orblivion 12y ago

(Oh actually, you could probably do it pretty safely with a guest account.)

peteretep 12y ago

Why does piping commands in to bash from the internet take on a magical security significance for people who run software they haven't audited literally all the time?

zorpner 12y ago
In the case of a network interruption, a command could become truncated with potentially destructive results.
- hetman 12y ago
  That would result in a broken pipe and the command being aborted. We're not dumping raw datagrams here...
  - 0x0 12y ago
    https://news.ycombinator.com/item?id=8385374 https://news.ycombinator.com/item?id=8385374
e12e 12y ago
You don't see the difference between running an exploit to check if you're vulnerable to a security bug, and running software provided by your upstream distribution?
- peteretep 12y ago
  No, I don't see why people who run open source code from a variety of sources think that there's something magically insecure about downloading it and executing it using curl and bash.
zurn 12y ago
This is a good question to think about, especially if it makes you consider more carefully about what software you run! But there's a lot of spectrum between "i have audited this software" and "i'm just piping this random url off the web to my shell". Many software distribution mechanisms provide varying degrees of curation, reputation, accountability etc. Also in this case the link was provided in a context that would select for people who are concerned about security updates (= looking after high value systems) and still somewhat naive about security practices, and could get run on systems that have strict rules about installing software on them.
heavenlyhash 12y ago
Perhaps the parent commenter doesn't run software without audit. There's no reason to presume defeat -- It's wholly possible to run a modern system using only signed builds from trusted sources and compile-from-source from everything else. Certainly, one can't audit every line, but just as certainly, one can establish a train of trusted sources and audit the rest (like this tiny snippet of bash, which is so utterly trivial to verify you might as well polish the habit on it).

christiangenco 12y ago

I'm in the same boat. Though I see the argument that I'm running code I haven't audited all the time, there's something about a bash script in particular that gives me worry. I don't know how rational this is, but I feel like the author could switch the code momentarily to something exploitive, wait for N downloads, then switch it back. I'm not sure how you could gather evidence that this even happened, since the nature of `curl -s URL | bash` is so transient. I'd rather take an extra few seconds to do: $ curl https://raw.githubusercontent.com/hannob/bashcheck/master/bashcheck > bashcheck.sh $ cat bashcheck.sh # nothing fishy $ chmod +x bashcheck.sh && ./bashcheck.sh

floatingatoll 12y ago
You're better off using any text editor - cat will display ANSI terminal codes unescaped in many situations, which can inhibit your ability to see code that might otherwise be hidden by # ^[[<wipe to beginning of line> or somesuch appended to a malicious bit.
- teddyh 12y ago
  “cat” will display all bytes unescaped – that’s its job. The correct command in this case would be “less” (or any other pager, or possibly editor).
  - treve 12y ago
    Well since you went for a technical argument... if you really want to get technical.. it doesn't display anything and just sends the raw bytes to a stream. It doesn't 'display' all bytes, because not all bytes are displayable. hexdump would do a better job there.
ClashTheBunny 12y ago
We could at least reference a known good version by hash. This is at least a little more secure. But considering that Github could have been compromised by this bug, I would probably not pipe much from them until I know more about them not being compromised. Isn't running a jailed git server over ssh one of the great exploits of this bug?

k_bx 12y ago

It's https, so no worries.

dllthomas 12y ago
Still potentially vulnerable to truncation, though I don't know that that could actually cause a problem with this payload. And of course, habits like this could quickly propagate infection if a trusted source is compromised (though there are certainly plenty of other habits that share that characteristic).