@akkartik It is a very explicit eval via a subshell. There should be no surprise here other than users can't recognize subshells :)

@gcb Sorry, something ate all-important quotes the first time around. Here's a correction:

% x='(PATH=2)'
% echo $((x+1))
% echo $PATH

(The original `x=(PATH=2)` without quotes doesn't actually perform any eval.)

Does it make sense now? This is indeed quite subtle.


"..things that can be parsed as variable names are treated as variable names in arithmetic contexts. ..bash does this *recursively* until it gets to an integer, or to something that can't be parsed as either an integer or a variable name."


OMG. This is _not_ documented.

@gcb @rain @kingcons

I hope all the shell scripts in the world are sanitizing their inputs.

@gcb @rain @kingcons

@rain @kingcons @akkartik If a webapp is building a string to send to any shell, even this S shell, it is already susceptible to shellshock-like attacks since it is by definition building a string that will be evaluated. The only protection against this is if the language the webapp is using has proper shell string building library that handles escaping properly, like most have to SQL et al.

@gcb @kingcons @akkartik

yeah I get what you're saying. To really fix the problem all command line programs would have to be redesigned to take a well specified language as input. Command line flag parsing is too ad-hoc.

@gcb @rain @kingcons @akkartik Except in the SQL case, there usually isn't escaping done behind the scenes. Instead the data is passed like commandline arguments to pre-compiled/optimized queries.

Still, great point: always escape your text.

@alcinnz @gcb @kingcons @akkartik

wait a sec, in SQL it is done with no escaping? what data format is sent across the wire then?

I am expecting something like netstrings maybe?

@rain as far as I am aware its plain text which has always been why I wrap any mysql connection in ssh.

@akkartik @kingcons @gcb @alcinnz

@rain @alcinnz @gcb @kingcons @akkartik So the original method uses escaped plaintext queries. But at some point someone figured out that they could parse a symbolic version of a query, save that parsed version, and then provide non-escaped arguments to that pre-parsed query, which is both faster (for complex queries) and much safer. I have no idea what the protocol looks like for this but I assume it has explicit string lengths or null terminators or something, instead of quoting.

@someonetellmetosleep @alcinnz @gcb @kingcons @akkartik

super interesting stuff! thanks for sharing. I'll see if i can find out what it look like on-the-wire

@akkartik @gcb @rain @kingcons i always thought that Bash is terrifying, but i didn't realize it's this terrifying…

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!