Bash quoting paranoid or necessary

Question

I wanted to know how vulnerable is bash by code injection. So I wrote a script as simple as this:

#!/bin/bash
grep $1 $2

and saved it as greptest.sh. The quotes around the variables were dropped intentionally for vulnerability test, so grep "$1" "$2" is the preferred way. Then I created test.txt:

sadhuer
sadjfh Hello
cusad
Hello
fgdfg

First was to show its proper use.

$ ./greptest.sh 'Hello' 'test.txt'

Output as expected:

sadjfh Hello
Hello

Then the first attack:

$ ./greptest.sh 'Hello test.txt'

Outputs the same as above. So, obviously, it does something due to missing quotes within the script - altough $2 is empty! Next try with $2 not empty for proving my assumption that $2 will be interpreted as a further input file:

$ ./greptest.sh 'Hello test.txt' 'nonexistingfile.txt'

outputs:

test.txt:sadjfh Hello
test.txt:Hello
grep: nonexistingfile.txt: No such file or directory

Then the harder attack: Trying to execute an arbitrary command:

$ ./greptest.sh 'Hello test.txt' '; ls'

outputs:

test.txt:sadjfh Hello
test.txt:Hello
grep: ;: No such file or directory
grep: ls: No such file or directory

I did not expect this. I thought the variables were subsitituted to yield

grep Hello test.txt ; ls

which should result in listing the current directory. So, is missing these quotes just ugly and error prone or a serious security concern I should care about (given the values of these parameters come from an untrusted source)?

In case of `grep $1 $2`, I don't see a security concern. But, if later in the script `$var` contains a command name, or `eval` is involved, you're in trouble. — choroba, Feb 22 '16 at 11:51
Thanks for pointing to `eval`, which is always very special about security. Of course, I could even write `eval grep $1 $2`, then my execution of `ls` really works. — rexkogitans, Feb 22 '16 at 12:01
Unless you're executing a variable, I don't see how code injection enters the picture. Quoting is still necessary if you don't want unintended effects: `cp $1 $2`, for example. Quoting and security is extensively discussed on [unix.se]: http://unix.stackexchange.com/q/171346/70524 — muru, Feb 22 '16 at 12:53
Semicolons as command separators are recognized *before* parameter expansion, so any semicolons resulting from expansion are treated as literal text. — chepner, Feb 22 '16 at 13:53

score 0 · Answer 1 · edited Apr 13 '17 at 12:36

0

You don't need to worry about the parameters passed to your greptest.sh bash script, as you are passing the parameters directly as parameters to the called program (grep in this case).

You need to worry about whatever calls greptest.sh injecting parameters onto that command line.

See this post for information.

edited Apr 13 '17 at 12:36

Community

1
1

answered Feb 23 '16 at 11:37

SilverlightFox

32,436
11
76
145

score 0 · Answer 2 · edited Jun 20 '20 at 09:12

One security issue of unquoted variables (though not code injection) is glob expansion DoS – a variable without quotes not only undergoes word splitting, but also globbing!

If the variable contains a pattern like */*/../../ repeated several times, like */*/../../*/*/../../, */*/../../*/*/../../*/*/../../ and so on, then the number of files that expands to increases exponentially with the length of the pattern.
Not related to quoting, but if the attacker can influence $PATH, $LD_PRELOAD, etc, then he can make grep in your script mean anything.

Bash quoting paranoid or necessary

2 Answers2