Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TIL: Some surprising code execution sources in bash

yossarian.net

Post reply on HN
Print view View original

21–30 of 51 posts

Re: TIL: Some surprising code execution sources in bash

#21

Post by woodruffw »

usr1106 wrote: post #17
spiffytech wrote: post #14

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.

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

I think it would behoove you to read the rest of the post. The double quotes are not the operative part of example there; they're only there to demonstrate that the code execution doesn't come from splatting or word splitting.

The actual code execution in Case #1 comes from the fact that bash (and other ksh descendants) run arithmetic evaluation on some strings in arithmetic contexts, regardless of their double or single quoting. That evaluation, in turn, can run arbitrary shell commands.

Re: TIL: Some surprising code execution sources in bash

#23

Post by PhilipRoman »

kreetx wrote: post #18
PhilipRoman wrote: post #3

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.

I don't mean that all shell scripting is dead (emphasis on the word safe), but it should not be at a security boundary.

Re: TIL: Some surprising code execution sources in bash

#24

Post by mmsc »

Unfortunately, there's a lot of gotchas in Bash like this. A lot of them are documented here: https://mywiki.wooledge.org/BashPitfalls, including the `test -v` case, which is #61. Some more code execution pitfalls are documented here: https://mywiki.wooledge.org/BashProgramming/05?action=show&r... including the `-eq` part (under Arithmetic Expansion).

Basically, the -v case was by design, so for `-v 'hash[$key]'`, "$key is expanded before the array subscript evaluation, and then the whole array plus expanded index is evaluated in a second pass". "Newer versions of bash (5.0 and higher) have a assoc_expand_once option which will suppress the multiple evaluations"

Note that the `-v` case doesn't really work the way one may infer from reading the OP:

> $ key='$(cat /etc/passwd > /tmp/pwned)'

> $ [[ -v 'x[$key]' ]]

> bash: $(cat /etc/passwd > /tmp/pwned): syntax error: operand expected (error token is "$(cat /etc/passwd > /tmp/pwned)") *

> [[ -v "${x[$key]}" ]]

> bash: $(cat /etc/passwd > /tmp/pwned): syntax error: operand expected (error token is "$(cat /etc/passwd > /tmp/pwned)")

Re: TIL: Some surprising code execution sources in bash

#25

Post by pizzalife »

spiffytech wrote: post #14

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.

Honestly, the fix is to only allow alphanumeric input to shellscripts. Anything else invariably fails at some point.

Re: TIL: Some surprising code execution sources in bash

#26

Post by usr1106 »

woodruffw wrote: post #21
usr1106 wrote: post #17

Earlier quoted context omitted.

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.

> 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. I think it would behoove you to read the rest of the post. The double quotes are not the operative part of example there; they're only there to demonstrate that the code execution doesn't come from splatting or word splitting. The actual code execution in Ca…

Ok, need to read it again with more time.

Myself I typically don't script in bash. Most of the extras like [[ are not needed, you can do everything in dash. Arrays are the only feature that comes to my mind where bash would be handy.

Re: TIL: Some surprising code execution sources in bash

#28

Post by jerf »

voidfunc wrote: post #22

So many footguns in bash. When do we finally get serious about ditching this language as an industry in the same way we are about memory safety?

A lot of this behavior is only a major problem if you're putting arbitrary input in, and especially, externally sourced input.

The "good news" is that bash is so full of ways to get command execution that people blow their foot off and get compromised long before these little details are what are compromising their system. People get popped putting in user input at the base string layer where all you have to do is slap down a semi-colon to get arbitrary command execution long before they're getting popped by obscure "test" behaviors.

Re: TIL: Some surprising code execution sources in bash

#30

Post by jwilk »

oneshtein wrote: post #13
webstrand wrote: post #6

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

"if (( num==42 ))" can exectue code from $num too.
Post reply on HN