On 09/27/2014 05:59 PM, Chet Ramey wrote: > On 9/27/14, 4:29 PM, Eric Blake wrote: >> On 09/27/2014 12:53 PM, Chet Ramey wrote: > >> Right now, we know of no way for an attacker to force an arbitrary >> variable name - ONLY arbitrary variable contents. > > Sure, but we didn't know that at the time. We still don't, really.
On the bright side: _if_ we find a way for an attacker to generate an arbitrary variable name in a parent process before calling into bash, that is more likely to be raised as a security bug against THAT program, and not bash. The reason bash is getting the limelight for CVE-2014-6271 is because there are so many existing programs that pass untrusted input to environment variable values, where fixing bash solves ALL of those cases at once; but there are a lot fewer (if any) programs stupid enough to create arbitrary environment variable names. The regression with 'at' failing to work is because 'at' is making unportable assumptions that the environment it is passed will always be parsable in shell. But this assumption is wrong whether or not bash uses an alternate namespace for function exports - ANY C program that uses execve can tickle that bug in 'at'. So that particular fix is not bash's problem, but 'at's problem. > >> Exactly, this break is undesirable. Remember, the security hole of >> Shell Shock is NOT what the function is named, but the fact that >> arbitrary variable contents were being parsed. Once you plug that hole >> by sticking function import/export in a separate namespace, then there >> should be no problem in allowing ALL function names that have always >> been previously allowed. > > We have an opportunity to close up a potential problem here, at least > with respect to function names containing `/'. As I said in a later mail, I'm now definitely leaning towards your desire to exclude '/', and may I also add '=', as two characters that will be blacklisted from valid function names both in the shell and during import/export, because they are just too risky. I haven't yet come up with any reason to blacklist any other non-metacharacter, and you already reject any metacharacter that requires quoting. > I'm not really interested in the function-importing-by-default discussion > right now. Maybe sometime later. It's more of a break with backwards > compatibility than I'm willing to go at this point. That's a fair stance. I don't mind waiting and revisiting that discussion later; I agree that the first priority is to plug the namespace issue. >>> (And I'm not interested in rehashing decisions that were made 25 years >>> ago, and I am completely aware that this "violates" Posix. That's why it >>> doesn't do this in posix mode.) >> >> I don't see function export/import as a violation of posix; > > Yeah, but what I was talking about was allowing non-identifiers as valid > function names. Where does POSIX forbid the use of a non-identifier as a valid function name? My understanding is that: a:b () { ... } is unspecified by POSIX (and NOT expressly required to be a syntax error), which has two implications: 1. Strictly-conforming shell scripts will not attempt to use it, and 2: we are allowed to support it as an extension while still remaining POSIX compliant. I'd need to see an example of some script that would be parsed one way with bash's function name extensions and a different well-defined way by a strict reading of POSIX before stating that /bin/sh mode must behave differently at having a smaller subset of valid function names. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature