Live data from Hacker News

TIL: Some surprising code execution sources in bash

yossarian.net

11–20 of 51 posts

Re: TIL: Some surprising code execution sources in bash

#11
post #5

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?

In this case I did some tests with latest dash and latest bash. I tested only with builtin `test`.

Re: TIL: Some surprising code execution sources in bash

#13

I... 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 ))`.

Re: TIL: Some surprising code execution sources in bash

#15

I... 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 ))`.

or if test $num -eq 42, which is the most sensible way to do it in my view, since it really makes the point clear that what you're really evaluating is the exit status of the evaluated command

(and where '[' is simply an alias to 'test')

Re: TIL: Some surprising code execution sources in bash

#17

What'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.

The first function one is not particularly well-written, but harmless. The quoting of

   ${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

#18

Yuck, 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.

Ack to yuck, but dead.. definitely not. Pretty sure large amounts of shell still get written, mostly due to it being the default scripting interface to the operating system.

Re: TIL: Some surprising code execution sources in bash

#19
post #2

My 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.)

> (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.

Post reply on HN