Wow this is getting out of hand, that's not really a security vulnerability anymore. That's how bash passes exported functions, I'll get back to that.
There is some misunderstanding though regarding the suid shell script. I can't think of any modern unix other than solaris that allows those by default any more. It's just not a concern anymore unless an admin twiddles some sysctl or what not. And in the case of solaris /bin/sh is not bash. Also /bin/sh does it's own setuid after comparing to 100 (unless the -p option is passed) so often if people are not adding users to a group or sudo, they would create a ksh or perl script instead. Anyway that's just rambling, sorry, the short answer is that I would be really surprised if there was any modern system that used bash as /bin/sh and also allowed suid interpreter scripts.
Doh, forgot to get back to the first point, sorry.
My thinking is that at this point the whole exporting functions (and anything else other that environment variables, like arrays) is just a bad idea in the default case. I actually do do it, but for a stupid reason and can totally see how I should just put those functions in bashrc for the same effect anyway.
So I really would like to see that all disabled by default in bash and a shellopt added to enable it if anyone really needed it.
I've heard about other ideas like prefix, suffix the name, or add a BASH_FOOBARBAZ that lists exported functions, but it's just not something most people do, and it would be a pita for the people that do need it now needing to change how they do it cause I can totally see people that made use of this having done it in C and perl knowing that if they did added to ENV 'cat=() { ...' or what not it would change what they needed in the subshell after they called system. That would really be annoying for those people to have all that break in a way they would need to change all that baroque code instead of just adding an option, something like system("exec /bin/bash --foobarbaz ... ") now.
Plus there are other programs like sudo that already know how to deal with the '() {' style env vars and clear them-out by default, people would have to update all those (plus what ever ancient suid C launcher programs they already had doing this kind of env var clean-up in their own broken ways from before the time sudo became the way to do this stuff) now too.
I should not have replied until I had more time to respond clearly, sorry.
The BASH_FUNC_foo()=() { ... is nice, it's how it should have been from the get go. Besides having a nice prefix that owns them all (what about arrays though)it makes it hard to set an exported function from the shell using = cause of the () suffix. That's clever, promotes the use of export -f basically from bash itself.
Unfortunately it breaks how to do it from everything other than bash cause it's not backwards compatible, and people like me had done that. Now I realize that I had done it for not great reasons with other better ways to do what I wanted. I think most everyone else that had exported functions would have felt the same. So very few people actually need exported functions, most can come-up with a work-around.
Taking that into account what is trying to be accomplished here with any patch? Really it's to prevent a future vulnerability, that should be the goal. Going back, the first vulnerability was that when the shell was initializing more got executed than intended. Then the next (which I can't figure-out how to exploit) was because of state from that initialization being kept around (in this case from an error bailing) and then messing-up later execution.
It's sort of a hackish way to do all this, right? It only took a day for someone to find another bug, I was able to get bash to seg fault left and right when I was looking into it myself before the patches. What is the chance that there is another bug in that parser say? Noby knows for sure.
The netbsd approach goes: Fix the current bugs, because there are so few reasons to export functions, so few people do so, most people can find another approach, and the way that they are implemented might be found vulnerable => do not ever export functions by default. As a courtesy to those that have and that still must, provide an option to allow them and do not break backwards compatibility so those with the most trouble need only add the option instead of changing other complicated squirrelly things.
The redhat approach goes: Fix the current bugs, because there are people that export functions, let us do it in a more sensible way. Now since we have a prefix and suffix, we protect against an attacker being able to create arbitrary function definitions. If an attacker could control BASH_FUNC_foo()=, then they would go after lower hanging fruit anyway. As a courtesy, if the people used export -f, it is compatible.
So it's a philosophical thing. The limitation of the redhat approach is there are people like me that feel there will be more bugs in bash. The parser is complicated, it is being called in this early place, state remains for later, I expect that it will not be too much to get bash to segfault again, and then it's careful analysis to see if payload can be crafted to get it to execute instead of simply seg fault. So I would like a way to have it just not do any of that by default. The redhat approach does not give me a way to do that. I value that more, plus being backward compatible. The redhat approach values having a safer way to pass functions, one that continues to allow that by default, but breaks compatibility and does not allow me to disable it at all.
Personally I like this approach from netbsd much better, it's not ripped-out, just disabled by default. Though it would be nice if there was a single char shopt so set, $-, and shebangs could all work with it, but then again it might be such a rare (and somewhat questionable) thing to export functions that it's a good idea just to leave it like this with only a longopt. Might force people to think about it some and use /usr/bin/env foo=bar ... - /bin/bash now, or just do the system(exec ... like I had above. But changing the shebang would be simplest, something like #!/bin/sh -g for the scripts that need it. And yes I had to deal with code like this doing exporting functions from perl and C in the past, it was for gross reasons to emulate older systems poorly.
ha, I forgot one more point! The fact that I have export -f in my bashrc, broke the common later () { a=[><]\ style redirect IO parser exploit. I thought that was funny.
Comments
Wow this is getting out of hand, that's not really a security vulnerability anymore. That's how bash passes exported functions, I'll get back to that.
There is some misunderstanding though regarding the suid shell script. I can't think of any modern unix other than solaris that allows those by default any more. It's just not a concern anymore unless an admin twiddles some sysctl or what not. And in the case of solaris /bin/sh is not bash. Also /bin/sh does it's own setuid after comparing to 100 (unless the -p option is passed) so often if people are not adding users to a group or sudo, they would create a ksh or perl script instead. Anyway that's just rambling, sorry, the short answer is that I would be really surprised if there was any modern system that used bash as /bin/sh and also allowed suid interpreter scripts.
Doh, forgot to get back to the first point, sorry.
My thinking is that at this point the whole exporting functions (and anything else other that environment variables, like arrays) is just a bad idea in the default case. I actually do do it, but for a stupid reason and can totally see how I should just put those functions in bashrc for the same effect anyway.
So I really would like to see that all disabled by default in bash and a shellopt added to enable it if anyone really needed it.
I've heard about other ideas like prefix, suffix the name, or add a BASH_FOOBARBAZ that lists exported functions, but it's just not something most people do, and it would be a pita for the people that do need it now needing to change how they do it cause I can totally see people that made use of this having done it in C and perl knowing that if they did added to ENV 'cat=() { ...' or what not it would change what they needed in the subshell after they called system. That would really be annoying for those people to have all that break in a way they would need to change all that baroque code instead of just adding an option, something like system("exec /bin/bash --foobarbaz ... ") now.
Plus there are other programs like sudo that already know how to deal with the '() {' style env vars and clear them-out by default, people would have to update all those (plus what ever ancient suid C launcher programs they already had doing this kind of env var clean-up in their own broken ways from before the time sudo became the way to do this stuff) now too.
Debian has already released a batch patched to only treat BASH_FUNC_FOO() as exported functions.
It's the second half of the security fix, so I recommend upgrading.
There is a small potential for breakage as you mention, but less than ripping the feature entirely out.
I should not have replied until I had more time to respond clearly, sorry.
The BASH_FUNC_foo()=() { ... is nice, it's how it should have been from the get go. Besides having a nice prefix that owns them all (what about arrays though)it makes it hard to set an exported function from the shell using = cause of the () suffix. That's clever, promotes the use of export -f basically from bash itself.
Unfortunately it breaks how to do it from everything other than bash cause it's not backwards compatible, and people like me had done that. Now I realize that I had done it for not great reasons with other better ways to do what I wanted. I think most everyone else that had exported functions would have felt the same. So very few people actually need exported functions, most can come-up with a work-around.
Taking that into account what is trying to be accomplished here with any patch? Really it's to prevent a future vulnerability, that should be the goal. Going back, the first vulnerability was that when the shell was initializing more got executed than intended. Then the next (which I can't figure-out how to exploit) was because of state from that initialization being kept around (in this case from an error bailing) and then messing-up later execution.
It's sort of a hackish way to do all this, right? It only took a day for someone to find another bug, I was able to get bash to seg fault left and right when I was looking into it myself before the patches. What is the chance that there is another bug in that parser say? Noby knows for sure.
The netbsd approach goes: Fix the current bugs, because there are so few reasons to export functions, so few people do so, most people can find another approach, and the way that they are implemented might be found vulnerable => do not ever export functions by default. As a courtesy to those that have and that still must, provide an option to allow them and do not break backwards compatibility so those with the most trouble need only add the option instead of changing other complicated squirrelly things.
The redhat approach goes: Fix the current bugs, because there are people that export functions, let us do it in a more sensible way. Now since we have a prefix and suffix, we protect against an attacker being able to create arbitrary function definitions. If an attacker could control BASH_FUNC_foo()=, then they would go after lower hanging fruit anyway. As a courtesy, if the people used export -f, it is compatible.
So it's a philosophical thing. The limitation of the redhat approach is there are people like me that feel there will be more bugs in bash. The parser is complicated, it is being called in this early place, state remains for later, I expect that it will not be too much to get bash to segfault again, and then it's careful analysis to see if payload can be crafted to get it to execute instead of simply seg fault. So I would like a way to have it just not do any of that by default. The redhat approach does not give me a way to do that. I value that more, plus being backward compatible. The redhat approach values having a safer way to pass functions, one that continues to allow that by default, but breaks compatibility and does not allow me to disable it at all.
Personally I like this approach from netbsd much better, it's not ripped-out, just disabled by default. Though it would be nice if there was a single char shopt so set, $-, and shebangs could all work with it, but then again it might be such a rare (and somewhat questionable) thing to export functions that it's a good idea just to leave it like this with only a longopt. Might force people to think about it some and use /usr/bin/env foo=bar ... - /bin/bash now, or just do the system(exec ... like I had above. But changing the shebang would be simplest, something like #!/bin/sh -g for the scripts that need it. And yes I had to deal with code like this doing exporting functions from perl and C in the past, it was for gross reasons to emulate older systems poorly.
http://seclists.org/oss-sec/2014/q3/755
ha, I forgot one more point! The fact that I have export -f in my bashrc, broke the common later () { a=[><]\ style redirect IO parser exploit. I thought that was funny.