Tavis Ormandy

@taviso not true. env X='\' will set the X to \. You're setting a env-var and then running a sh-call as @newshtwit mentioned.

@fransrosen @newshtwit This is a bug in bash function parsing. Read execute_null_command(), and then we can discuss this.

@taviso a better test: `env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable :("

@postmodern_mod3 @taviso @veorq don’t know if obvious, but replacing “bash” with “zsh” prints also “still vulnerable :(”

@postmodern_mod3 @taviso @veorq i.e. env X='() { (a)=>\' zsh -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable”

@Daeinar One of my followers pointed out this prints "vulnerable" because of file "echo" left in cur. dir. Does it reproduce in a clean dir?

@jun0inoue Yeah he is right. There was an “echo” file. Doesn’t work in a clean dir. So zsh seems to be okay. Thanks for pointing it out!

@Daeinar @jun0inoue a commenter on the redhat bug came up with using /dev/stdout to avoid leaving behind files. https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c34 …

@taviso I dont get it. you're just running: sh -c "echo date".

@newshtwit @taviso maybe try "bash" instead of "sh" ... it creates a file called "echo"

@taviso try bash -c "echo ls /etc; cat echo" without and with the X env variable set, perhaps that will better demonstrate what's going on?