5 ms·

Agreed. The IFS trick is shortly followed by an explanation, which includes a bunch of anti-patterns, such as bare ${foo[@]} and $@ usage. Rule of thumb: quote

Agreed. The IFS trick is shortly followed by an explanation, which includes a bunch of anti-patterns, such as bare ${foo[@]} and $@ usage. Rule of thumb: quote all your variables. http://mywiki.wooledge.org/Quotes http://mywiki.wooledge.org/Quotes

redsymbol 12y ago
That's the common answer, and while I practice that myself, I have to disagree with it as guidance. Maybe you and I are fastidious enough to always remember to quote all our variables, but many are not - I know I was writing shell scripts for a couple of years before I realized its importance, and it's very common that even experienced engineers don't know or care to do it. If someone writing or editing the code forgets to quote the variable that allows subtle bugs to sneak in. It's unfortunate the semantics of bash don't have variable references behave like they are quoted by default. I really wish it did.
- dap 12y ago
  While setting IFS=$"\t\n" may make problems less likely when strings contain spaces, it's still not correct. File names (and other strings) can contain tabs and newlines, too. That's relatively rarer, but the quoting approach always works.
  - redsymbol 12y ago
    Hm, is that true? When I run this script: #!/bin/bash items=( 'a' 'b c' "d\te" "f\ng" ) echo "Unquoted:" for item in ${items[@]}; do echo -e ". $item" done echo "Quoted:" for item in "${items[@]}"; do echo -e ". $item" done set -euo pipefail IFS=$'\n\t' echo "Unquoted strict mode:" for item in ${items[@]}; do echo -e ". $item" done ... I get this output: Unquoted: . a . b . c . d e . f g Quoted: . a . b c . d e . f g Unquoted strict mode: . a . b c . d e . f g Note the output for "Quoted" and "Unquoted strict mode" are identical. (GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu))
- _kst_ 12y ago
  If you can remember to use $@ rather than $*, you should be able to remember to use "$@". The only reason $@ exists is that it behaves differently when enclosed in double quotes.
- staticshock 12y ago
  Unquoted variables are an attack vector. Plain and simple. The IFS tip, as described in the original article, does nothing to remedy it. https://www.owasp.org/index.php/Command_Injection https://www.owasp.org/index.php/Command_Injection
  - redsymbol 12y ago
    Can you give an example of an exploit in bash? The link you give is excellent information, but doesn't have any shell script examples. My first thought: It seems like only $@, $* and variables read from the environment could be possible attack vectors. But since shell scripts can't be setuid, it's hard for me to immediately imagine how unquoting could enable a new exploit. EDIT: the most dangerous example I can think of right now is a script like this, where a webapp invokes the script and passes a GET param as an argument: #!/bin/bash exec $1 But if I execute this like so: ./badscript.sh 'some-benign-command ; cat /etc/passwd' ... then passwd is not exposed, because the tokens ";", "cat" and "/etc/passwd" are passed into the argv of some-benign-command. (And if "cat /etc/password" itself can be passed as $1, then quoting won't help...)

redsymbol 12y ago

That's the common answer, and while I practice that myself, I have to disagree with it as guidance. Maybe you and I are fastidious enough to always remember to quote all our variables, but many are not - I know I was writing shell scripts for a couple of years before I realized its importance, and it's very common that even experienced engineers don't know or care to do it. If someone writing or editing the code forgets to quote the variable that allows subtle bugs to sneak in. It's unfortunate the semantics of bash don't have variable references behave like they are quoted by default. I really wish it did.

dap 12y ago
While setting IFS=$"\t\n" may make problems less likely when strings contain spaces, it's still not correct. File names (and other strings) can contain tabs and newlines, too. That's relatively rarer, but the quoting approach always works.
- redsymbol 12y ago
  Hm, is that true? When I run this script: #!/bin/bash items=( 'a' 'b c' "d\te" "f\ng" ) echo "Unquoted:" for item in ${items[@]}; do echo -e ". $item" done echo "Quoted:" for item in "${items[@]}"; do echo -e ". $item" done set -euo pipefail IFS=$'\n\t' echo "Unquoted strict mode:" for item in ${items[@]}; do echo -e ". $item" done ... I get this output: Unquoted: . a . b . c . d e . f g Quoted: . a . b c . d e . f g Unquoted strict mode: . a . b c . d e . f g Note the output for "Quoted" and "Unquoted strict mode" are identical. (GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu))
_kst_ 12y ago
If you can remember to use $@ rather than $*, you should be able to remember to use "$@". The only reason $@ exists is that it behaves differently when enclosed in double quotes.
staticshock 12y ago
Unquoted variables are an attack vector. Plain and simple. The IFS tip, as described in the original article, does nothing to remedy it. https://www.owasp.org/index.php/Command_Injection https://www.owasp.org/index.php/Command_Injection
- redsymbol 12y ago
  Can you give an example of an exploit in bash? The link you give is excellent information, but doesn't have any shell script examples. My first thought: It seems like only $@, $* and variables read from the environment could be possible attack vectors. But since shell scripts can't be setuid, it's hard for me to immediately imagine how unquoting could enable a new exploit. EDIT: the most dangerous example I can think of right now is a script like this, where a webapp invokes the script and passes a GET param as an argument: #!/bin/bash exec $1 But if I execute this like so: ./badscript.sh 'some-benign-command ; cat /etc/passwd' ... then passwd is not exposed, because the tokens ";", "cat" and "/etc/passwd" are passed into the argv of some-benign-command. (And if "cat /etc/password" itself can be passed as $1, then quoting won't help...)