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

41–50 of 51 posts

Re: TIL: Some surprising code execution sources in bash

#41

Post by usr1106 »

woodruffw wrote: post #38
usr1106 wrote: post #34

Earlier quoted context omitted.

So -eq triggers evaluation? Sounds like typical bash magic. I would use [ an the problem goes away. Showing -eq is not the best example, it can just be replaced by = and the problem goes away. But if you need -gt or similar there is no replacement. So one should stick to [. If I follow correctly the dangerous combination is [[ and arithmetic comparisons?

`-eq` is for arithmetic comparison; `=` is for string comparison. They don't do the same thing, and it's unsound to uniformly replace either with the other. The dangerous thing here is that an undefined number of contexts exist where Bash treats strings as arithmetic expressions, which can contain arbitrary code despite not being quoted for expansion. `-eq` is just one example of that; others have linked other exampl…

Can you give an example where = would be unsuitable for comparison of numbers?

Re: TIL: Some surprising code execution sources in bash

#42

Post by woodruffw »

usr1106 wrote: post #41
woodruffw wrote: post #38

Earlier quoted context omitted.

`-eq` is for arithmetic comparison; `=` is for string comparison. They don't do the same thing, and it's unsound to uniformly replace either with the other. The dangerous thing here is that an undefined number of contexts exist where Bash treats strings as arithmetic expressions, which can contain arbitrary code despite not being quoted for expansion. `-eq` is just one example of that; others have linked other exampl…

Can you give an example where = would be unsuitable for comparison of numbers?

Here's a trivial one:

    $ [[ 0xFF -eq 255 ]] ; echo $?
    0

    $ [[ 0xFF = 255 ]] ; echo $?
    1

Re: TIL: Some surprising code execution sources in bash

#43

Post by alganet »

everforward wrote: post #39
flanbiscuit wrote: post #36

Earlier quoted context omitted.

Curious what you use instead of bash? When you spin up a server somewhere, what's the first thing you like to install that replaces what we typically use bash for?

Do these apply to NuShell? I think something like that is the way forward. Something with real data types rather than implicitly doing weird array processing. I would be pretty happy with something similar to Python but with easier IO redirection and subprocess management. xonsh is neat in principle, but painful in actual usage ime. And I suspect vulnerable to similar issues around the Python-bash interop.

What would you do with `configure` scripts?

Let's say you need to install some third party software that is pretty standard `./configure && make && make install`, what would you do? Port `configure` to python?

Re: TIL: Some surprising code execution sources in bash

#44

Post by casey2 »

usr1106 wrote: post #26
woodruffw wrote: post #21

Earlier quoted context omitted.

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

I can only assume you were down-voted for calling bloat like arrays useful.

Re: TIL: Some surprising code execution sources in bash

#46

Post by lmz »

pizzalife wrote: post #25
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.

Taint checking as in Perl would be nice.

Re: TIL: Some surprising code execution sources in bash

#47

Post by usr1106 »

woodruffw wrote: post #42
usr1106 wrote: post #41

Earlier quoted context omitted.

Can you give an example where = would be unsuitable for comparison of numbers?

Here's a trivial one: $ [[ 0xFF -eq 255 ]] ; echo $? 0 $ [[ 0xFF = 255 ]] ; echo $? 1

Oh, hex. Another bashism. Not sure when I would have needed that in a shell script last time. So in most cases just using [ solves the problem. If you want to use hex from untrusted user input you need to validate the input first. Yes, the bash programmer needs to be aware of many pitfalls. I wasn't, but I would call myself more a bash avoider than a bash programmer. Yes, I use bash for interactive use, talking only about scripting.

Re: TIL: Some surprising code execution sources in bash

#48

Post by sshine »

alganet wrote: post #43
everforward wrote: post #39

Earlier quoted context omitted.

Do these apply to NuShell? I think something like that is the way forward. Something with real data types rather than implicitly doing weird array processing. I would be pretty happy with something similar to Python but with easier IO redirection and subprocess management. xonsh is neat in principle, but painful in actual usage ime. And I suspect vulnerable to similar issues around the Python-bash interop.

What would you do with `configure` scripts? Let's say you need to install some third party software that is pretty standard `./configure && make && make install`, what would you do? Port `configure` to python?

sh

Re: TIL: Some surprising code execution sources in bash

#49

Post by joveian »

tpoacher wrote: post #27

From what I understand, based on the premise that this results from switching into 'arithmetic' mode, you don't even need test. The following will also work with the proposed attack: function guess () { declare -i num="${1}" ; } (unless I'm missing something?)

Why I couldn't guess but an example similar to the article that I tried does not immediately execute (version 5.2.37(1)-release) when indrected through a variable as you show although other aritmetic evaluation does still happen when indirected. You can echo "${num}" and it shows the passed string. If you change it to declare -i num ; num="${1}" then it does immediately execute.
Post reply on HN