Earlier quoted context omitted.
The second variant (test -v) for me doesn't error out, but also doesn't write the /tmp/pwnd file, which tells me there is no subscript eval there.
What shell and what `test` are you using?
TIL: Some surprising code execution sources in bash
11–20 of 51 posts
Re: TIL: Some surprising code execution sources in bash
#12I... don't understand. I thought the whole reason for using [[ and breaking posix compatibility was to prevent just this kind of vulnerability. Why would bash do this.
Re: TIL: Some surprising code execution sources in bash
#13I... don't understand. I thought the whole reason for using [[ and breaking posix compatibility was to prevent just this kind of vulnerability. Why would bash do this.
Re: TIL: Some surprising code execution sources in bash
#14Shellcheck currently gives Sample 1 a pass. I hope this is something it can be modified to catch.
Re: TIL: Some surprising code execution sources in bash
#15I... don't understand. I thought the whole reason for using [[ and breaking posix compatibility was to prevent just this kind of vulnerability. Why would bash do this.
Instead of `if [[ "${num}" -eq 42 ]]`, bash expects `if [ "${num}" -eq 42 ]` or `if (( num==42 ))`.
(and where '[' is simply an alias to 'test')
Re: TIL: Some surprising code execution sources in bash
#16What's the fix for those code samples? Shellcheck currently gives Sample 1 a pass. I hope this is something it can be modified to catch.
Re: TIL: Some surprising code execution sources in bash
#17What's the fix for those code samples? Shellcheck currently gives Sample 1 a pass. I hope this is something it can be modified to catch.
${num}
is completely useless. Inside [[ bash does not do any word splitting after variable expansion. Double quotes never prevent variable expansion. I am not sure what the author is talking about. Shellcheck is correct to not complain. I stopped reading there.Re: TIL: Some surprising code execution sources in bash
#18Yuck, I was always instinctively put off by [[, now I finally have some arguments to justify it. IMO safe shell scripting is kind of dead. I can do it if I really have to, but too many external programs have tricky "convenience" features like interpreting flags after positional parameters, etc.
Re: TIL: Some surprising code execution sources in bash
#19My first insinct would be to remove the bashisms first: https://gist.github.com/alganet/a4198158651f3b2dc43ce658052e... Then, if we run it: "line 3: test: a[$(cat /etc/passwd > /tmp/pwned)] + 42: integer expression expected"
(Author of the post.) Yep, this is specifically a bashism (by way of being a kshism). However, it's worth noting that the second variant (`type -v`) will work in `[` and `test`. (It's also a still a bashism, but IME people don't realize how little of `type` is actually POSIX.)
I just declare all of my shell scripts to use bash, since I've got no idea how much of anything is a bashism versus POSIX, and I hate shell scripts enough that I don't care to learn.