The parsing of environment variables to produce functions should be disabled int bash by default, unless a loud and clear command line option is given to request the behavior, like "bash --hit-me-with-environment-variable-stupidity-please".
Furthermore, perhaps it should only work on environment variables in a loud an clear namespace like __bash_func_foo="() { whatever }" produces a function called "foo". A variable not in this namespace like TERM or REQUEST_URL is not scanned for this function-defining syntax under any circumstances.
Lastly, perhaps the target functions should be in a namespace themselves, making it impossible to pass down a function called "echo" or "ls". For instance only functions with the "if_" prefix ("inheritable function") could be subject to inheritance. Don't like the ugly prefix? Then write your shell application so that every new execution of a script sources all the code it needs from files. Or write your personal scripts so that they use a repository of functions in your ~/.bashrc rather than passing functions down among themselves. Or use local aliases for the ugly prefixed names.
Agreed. It is deeply strange that bash interprets the contents of environment variables at all and, although I'm no sysadmin, it would make sense to simply disable all interpretation and deal with subsequent breakage individually.
bash's implicit environment processing is the bug. A process that depends on bash's implicit environment processing is a bug by the transitive nature of bugs (newly coined by me, just now).
(Of course, you have to fix bash, then you have to replace it everywhere, including on devices that might not be user-updatable. I didn't think it was possible but this is clearly worse than heartbleed.)
Confining the parser to a namespace as in your second paragraph should be a sufficient solution, because it is already a well-known fact that allowing completely arbitrary control of the environment to a potential attacker is a bad idea, and existing software is written to account for that fact by restricting which environment variables can be set.
In the CGI case, for example, the environment variables in question are prefixed by HTTP_.
The problem is that any fix for this bug that makes the security crowd perfectly happy is necessarily going to break compatibility for the (probably very few) people who actually use this feature.
However, a flaw in some software (failure to properly restrict environment variables) is amplified by this feature of the shell; it gives an attacker an instant way to do harm. Whereas without this feature, attackers have to find some other ways by which environment variable contents can lead to an exploit. E.g. smuggle a rogue shared library onto the system somehow, then LD_PRELOAD it or whatever.
Woah. This is getting blown a little out of proportion now. It's a bad bug, but we don't need a bunch of misinformation about it:
1. The released patch (and subsequent update for many distributions) fixed the only currently-known remotely exploitable version of the bug. The cases found afterward are a different bug, and so far there's no publicly known way to remotely exploit it. These other bugs were published to demonstrate that there are deeper flaws in bash's parsing of environment variables. If you have updated bash with the most recent fix, the odds are in your favor that you're going to be just fine.
2. "Routers, web cameras, SIP gateways, NAS’s" & etc. all need to be running a variant of bash to be exploitable. dash doesn't have this problem. ksh, csh, other shells don't have this problem. ash, used by BusyBox, doesn't have this problem. BSD-based systems don't have this problem (except in rare circumstances).
3. DHCP exploitation requires that you have network-start scripts that are run by bash on your system, and you're getting DHCP from a compromised host.
4. Yes, ssh hosts are vulnerable -- if you already have ssh access to those hosts and your shell is bash. This bug doesn't give most users a level of access that they don't already have. But, it can mean that if a user is restricted to specific commands for sudo without being prompted for a password, then they can run arbitrary sudo commands, which isn't very nice.
5. And yeah, mass-scanning started late last night and the first examples of malware using this as a vector are being seen. As scanning techniques improve -- currently they're pretty rudimentary -- more and more hosts will get compromised.
9 comments
[ 78.7 ms ] story [ 803 ms ] threadFurthermore, perhaps it should only work on environment variables in a loud an clear namespace like __bash_func_foo="() { whatever }" produces a function called "foo". A variable not in this namespace like TERM or REQUEST_URL is not scanned for this function-defining syntax under any circumstances.
Lastly, perhaps the target functions should be in a namespace themselves, making it impossible to pass down a function called "echo" or "ls". For instance only functions with the "if_" prefix ("inheritable function") could be subject to inheritance. Don't like the ugly prefix? Then write your shell application so that every new execution of a script sources all the code it needs from files. Or write your personal scripts so that they use a repository of functions in your ~/.bashrc rather than passing functions down among themselves. Or use local aliases for the ugly prefixed names.
bash's implicit environment processing is the bug. A process that depends on bash's implicit environment processing is a bug by the transitive nature of bugs (newly coined by me, just now).
(Of course, you have to fix bash, then you have to replace it everywhere, including on devices that might not be user-updatable. I didn't think it was possible but this is clearly worse than heartbleed.)
In the CGI case, for example, the environment variables in question are prefixed by HTTP_.
The problem is that any fix for this bug that makes the security crowd perfectly happy is necessarily going to break compatibility for the (probably very few) people who actually use this feature.
Is this still true? On Ubuntu we got another update today:
1. The released patch (and subsequent update for many distributions) fixed the only currently-known remotely exploitable version of the bug. The cases found afterward are a different bug, and so far there's no publicly known way to remotely exploit it. These other bugs were published to demonstrate that there are deeper flaws in bash's parsing of environment variables. If you have updated bash with the most recent fix, the odds are in your favor that you're going to be just fine.
2. "Routers, web cameras, SIP gateways, NAS’s" & etc. all need to be running a variant of bash to be exploitable. dash doesn't have this problem. ksh, csh, other shells don't have this problem. ash, used by BusyBox, doesn't have this problem. BSD-based systems don't have this problem (except in rare circumstances).
3. DHCP exploitation requires that you have network-start scripts that are run by bash on your system, and you're getting DHCP from a compromised host.
4. Yes, ssh hosts are vulnerable -- if you already have ssh access to those hosts and your shell is bash. This bug doesn't give most users a level of access that they don't already have. But, it can mean that if a user is restricted to specific commands for sudo without being prompted for a password, then they can run arbitrary sudo commands, which isn't very nice.
5. And yeah, mass-scanning started late last night and the first examples of malware using this as a vector are being seen. As scanning techniques improve -- currently they're pretty rudimentary -- more and more hosts will get compromised.
Keep calm and update bash.