6 ms·

Did you read the post at all? The issue isn't executing untrusted code, it's connections terminating early and causing your shell to execute incomplete code.

Did you read the post at all? The issue isn't executing untrusted code, it's connections terminating early and causing your shell to execute incomplete code. The article ends with the example code TMP_DIR=`mktemp` rm -rf $TMP_DIR And the stream ending pre-maturely may cause the second line to end with rm -rf / and then execute it. While this wouldn't do anything anyway without --no-preserve-root added, it still brings up a good point about interrupted connections executing incomplete code which would otherwise be safe if the command was finished.

bryanlarsen 13y ago
Those scripts are typically very short. They'll either download completely or not at all. And if they do abort short then what are the chances that it's going to do it in exactly the wrong place? And then you have to manage to kill the wrong process to start the aborted script. Statistically a cosmic ray flips a few bits in your RAM every year. Theoretically those bit flips could transform a benign program into a malicious one, and I'm sure that's happened to somebody somewhere sometime. But it's very unlikely to happen to you tomorrow. You could use ECC RAM to prevent this from happening, but how many people do that?
- FiloSottile 13y ago
  Again, here is the counter-point of the author > This might be unlikely, but the results of this happening, even once, could be catastrophic. Also, you don't have to kill any process, that was a PoC by the author. The scenario is a connection drop.
  - codezero 13y ago
    Counterpoint to the author: have you ever heard of anyone ever having anything catastrophic happen because of this, ever? Have you ever heard of anyone even having it fail with garbage? I haven't.
    - maddddddddddddd 13y ago
      it's hard to hear from someone whose entire hard drive was wiped...
    - mikegirouard 13y ago
      Catastrophic? I can't claim that. But I can tell you that I had a server drop out on me when installing software this way. Here's a quick quote of the bug report I sent to Linode when I was installing Longview. > Bug: Update the nginx (?) error pages to be bash friendly > > root@marius ~]# curl -s https://lv.linode.com/nGiB | sudo bash > bash: line 1: html: No such file or directory > bash: line 2: syntax error near unexpected token `<' > 'ash: line 2: `<head><title>502 Bad Gateway</title></head> > > This could be done by just dumping out echo statements since its already > being parsed by the shell. Additional meta about the request (headers, etc) > could be dumped into comments too… > > # 502 Bad Gateway > echo > echo "Uh oh: Something went sideways during the install!" > echo "(" > echo "Re-running the installer should clear things up." > echo > echo " sudo !!" > echo
      - codezero 13y ago
        Yep, I agree this is generally bad practice and is prone to error conditions, but I am mainly addressing the article since it is claiming that this should never be done because of the possible catastrophic consequences, and I just don't think that scenario is likely enough to mount a campaign to abolish this practice :)
    - hrjet 13y ago
      How many would talk about a catastrophic failure that was caused because of their stupidity. Many wouldn't.
    - mikeash 13y ago
      You're right, let's ignore completely realistic failure modes just because nobody's had it happen yet.
  - cbsmith 13y ago
    No. If the connection drops, wget will retry forever iff you have Content-Length in the HTTP response, which you always do.
toomuchtodo 13y ago
Fine. So this: wget -O - https://example.com/install.sh https://example.com/install.sh | sudo sh Turns into this: wget -O install.sh https://example.com/install.sh https://example.com/install.sh && sudo sh ./install.sh Big deal. EDIT: Changed protocol to https for FiloSottile.
- FiloSottile 13y ago
  "https://" https://", please. Really, please. EDIT: Thanks <3
  - toomuchtodo 13y ago
    Credit where credit is due :)
- general_failure 13y ago
  It is a big deal.
- maddddddddddddd 13y ago
  that doesn't change anything... now instead of the output buffer having incomplete data, the install.sh file has incomplete data that is still executed. in order to make it fool proof the server would have to sign the code using public key cryptography, and the user would have to have their public key and validate the code before executing it.
- antocv 13y ago
  > Turns into this: wget -O install.sh https://example.com/install.sh https://example.com/install.sh && sudo sh ./install.sh Straw man. No it doesnt turn into that, it turns into wget https://install.sh https://install.sh && ls && less install.sh && less lala2 && echo "ok looks good enough" && ./install.sh # no sudo, to user local install, its just a package or program ffs, when you want packages to install for all users, or system wide, then you use the default package manager of your distribution.
  - ocharles 13y ago
cbhl 13y ago
Would it make sense to mitigate this by creating a (even smaller) bootstrap script that itself downloads the "real" script and checks e.g. the SHA256 hash of the downloaded file before executing?
- djjaxe 13y ago
  or possibly a self checking script that only executed if it was complete... ie: the script is escaped and must run unescape(escaped_script) to be lethal but by then you can confirm that the script is infact whole and as the creator intended to be...
- mikegirouard 13y ago
  Yes, but I understand the problem to be that we simply have gotten too comfortable with this behavior.
- hrjet 13y ago
  Even simpler would be: function install_my_software() { ... } install_my_software() If the script is partially downloaded, it won't have any effect.
  - mercurial 13y ago
    I realize that I tend to do that by default in my shell scripts. After a few years of Python, I always make a main() function which gets the command line parameters. Is this weird?
    - eropple 13y ago
      Not really weird - it allows for more composability if you ever need to go that way.
      - mercurial 13y ago
        I think I do that to avoid global variables as much as possible, as well. Declaring things as "local" tends to keep me honest, as opposed to having a bunch of junk cluttering the global namespace.
chadnickbok 13y ago
Actually, in this case, no it won't. Your own shell will parse $TMP_DIR and replace it with the output of mktemp, and then execute it. Its only really bad if some does the following: rm -rf /$TMP_DIR The slash is important
zenojevski 13y ago
Actually, it would end with: rm -rf $TMP and never: rm -rf / Because that is not in the code. Also, both: rm -rf $TM and: rm -rf $TMP_ won't cause the issue (but yeah, potentially others).

bryanlarsen 13y ago

Those scripts are typically very short. They'll either download completely or not at all. And if they do abort short then what are the chances that it's going to do it in exactly the wrong place? And then you have to manage to kill the wrong process to start the aborted script. Statistically a cosmic ray flips a few bits in your RAM every year. Theoretically those bit flips could transform a benign program into a malicious one, and I'm sure that's happened to somebody somewhere sometime. But it's very unlikely to happen to you tomorrow. You could use ECC RAM to prevent this from happening, but how many people do that?

FiloSottile 13y ago
Again, here is the counter-point of the author > This might be unlikely, but the results of this happening, even once, could be catastrophic. Also, you don't have to kill any process, that was a PoC by the author. The scenario is a connection drop.
- codezero 13y ago
  Counterpoint to the author: have you ever heard of anyone ever having anything catastrophic happen because of this, ever? Have you ever heard of anyone even having it fail with garbage? I haven't.
  - maddddddddddddd 13y ago
    it's hard to hear from someone whose entire hard drive was wiped...
  - mikegirouard 13y ago
    Catastrophic? I can't claim that. But I can tell you that I had a server drop out on me when installing software this way. Here's a quick quote of the bug report I sent to Linode when I was installing Longview. > Bug: Update the nginx (?) error pages to be bash friendly > > root@marius ~]# curl -s https://lv.linode.com/nGiB | sudo bash > bash: line 1: html: No such file or directory > bash: line 2: syntax error near unexpected token `<' > 'ash: line 2: `<head><title>502 Bad Gateway</title></head> > > This could be done by just dumping out echo statements since its already > being parsed by the shell. Additional meta about the request (headers, etc) > could be dumped into comments too… > > # 502 Bad Gateway > echo > echo "Uh oh: Something went sideways during the install!" > echo "(" > echo "Re-running the installer should clear things up." > echo > echo " sudo !!" > echo
    - codezero 13y ago
      Yep, I agree this is generally bad practice and is prone to error conditions, but I am mainly addressing the article since it is claiming that this should never be done because of the possible catastrophic consequences, and I just don't think that scenario is likely enough to mount a campaign to abolish this practice :)
  - hrjet 13y ago
    How many would talk about a catastrophic failure that was caused because of their stupidity. Many wouldn't.
  - mikeash 13y ago
    You're right, let's ignore completely realistic failure modes just because nobody's had it happen yet.
- cbsmith 13y ago
  No. If the connection drops, wget will retry forever iff you have Content-Length in the HTTP response, which you always do.

toomuchtodo 13y ago

Fine. So this: wget -O - https://example.com/install.sh https://example.com/install.sh | sudo sh Turns into this: wget -O install.sh https://example.com/install.sh https://example.com/install.sh && sudo sh ./install.sh Big deal. EDIT: Changed protocol to https for FiloSottile.

FiloSottile 13y ago
"https://" https://", please. Really, please. EDIT: Thanks <3
- toomuchtodo 13y ago
  Credit where credit is due :)
general_failure 13y ago
It is a big deal.
maddddddddddddd 13y ago
that doesn't change anything... now instead of the output buffer having incomplete data, the install.sh file has incomplete data that is still executed. in order to make it fool proof the server would have to sign the code using public key cryptography, and the user would have to have their public key and validate the code before executing it.
antocv 13y ago
> Turns into this: wget -O install.sh https://example.com/install.sh https://example.com/install.sh && sudo sh ./install.sh Straw man. No it doesnt turn into that, it turns into wget https://install.sh https://install.sh && ls && less install.sh && less lala2 && echo "ok looks good enough" && ./install.sh # no sudo, to user local install, its just a package or program ffs, when you want packages to install for all users, or system wide, then you use the default package manager of your distribution.
- ocharles 13y ago

cbhl 13y ago

Would it make sense to mitigate this by creating a (even smaller) bootstrap script that itself downloads the "real" script and checks e.g. the SHA256 hash of the downloaded file before executing?

djjaxe 13y ago
or possibly a self checking script that only executed if it was complete... ie: the script is escaped and must run unescape(escaped_script) to be lethal but by then you can confirm that the script is infact whole and as the creator intended to be...
mikegirouard 13y ago
Yes, but I understand the problem to be that we simply have gotten too comfortable with this behavior.
hrjet 13y ago
Even simpler would be: function install_my_software() { ... } install_my_software() If the script is partially downloaded, it won't have any effect.
- mercurial 13y ago
  I realize that I tend to do that by default in my shell scripts. After a few years of Python, I always make a main() function which gets the command line parameters. Is this weird?
  - eropple 13y ago
    Not really weird - it allows for more composability if you ever need to go that way.
    - mercurial 13y ago
      I think I do that to avoid global variables as much as possible, as well. Declaring things as "local" tends to keep me honest, as opposed to having a bunch of junk cluttering the global namespace.

chadnickbok 13y ago

Actually, in this case, no it won't. Your own shell will parse $TMP_DIR and replace it with the output of mktemp, and then execute it. Its only really bad if some does the following: rm -rf /$TMP_DIR The slash is important

zenojevski 13y ago

Actually, it would end with: rm -rf $TMP and never: rm -rf / Because that is not in the code. Also, both: rm -rf $TM and: rm -rf $TMP_ won't cause the issue (but yeah, potentially others).