On 09/27/2014 12:53 PM, Chet Ramey wrote:
> $ function /bin/echo () { builtin echo whoops; }
> > along with exporting these functions and importing them without complaint. > > This is obviously bad, and I removed the ability to do this in the first > patch in the event that someone figured out an easy way to remotely > specify an arbitrary variable name before we implemnted something to stop > it. Right now, we know of no way for an attacker to force an arbitrary variable name - ONLY arbitrary variable contents. So I would prefer a patch that allows the export/import of the exact same set of names as what can be used as valid function names. Neither set should be larger than the other, and for back-compat purposes, at least in bash mode, the set needs to STILL allow for functions named 'foo::bar' or 'foo/bar'. > > The problem is that it's too restrictive. There are folks who have taken > advantage of this flexibility to define, use, and export functions like > > STD::what::does::this::do > > which are no longer allowed. This is a pretty bad break with backwards > compatibility. 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. > > So what's your opinion on the appropriate set of restrictions? This is a > question that goes farther than what a particular shell will import, > since I'm going to align the restrictions on what functions a shell will > import from the environment with what functions that shell will let a > user define. That means that a posix-mode shell will require imported > functions to be valid identifiers, but a non-posix mode shell will allow > words. The original check that was in bash-4.3 does this. What additional > checks should there be? I can see starting with rejecting function names > that can be confused with pathnames. I'm 50:50 between two options: 1: Have two sets of valid names. In /bin/sh POSIX mode, functions can only be variable names, and when /bin/sh is importing from the env, it silently ignores or discards any mangled names that would not fit that restriction; meanwhile, invoking a function is only possible if the function name is a variable name; then in bash mode, functions can have any name and be invoked by that name 2. Have only a single rule on what forms a valid name. POSIX doesn't forbid us from having an enlarged namespace for valid function names; a strictly conforming application won't use such unusual names. You may still want to ignore or scrub those out of the environment during /bin/sh importing, but that brings us back to the question of whether function imports should be automatic, or something the user has to explicitly request. If ALL function imports are skipped unless explicitly requested, then it doesn't matter WHAT function names are exported, the incoming functions in a child shell (regardless of whether the shell is in bash or /bin/sh mode) will have no impact to that child unless the script programmer of the parent asked to have functions imported. Thankfully, bash already forbids trying to name a function 'a=b' (having to support such a name would make env-var export/import rather difficult), so the main culprits that people seem to be worried about are '-', '.', ':', and '/'. > > (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; the only violation I see is that the implementation is preventing the use of arbitrary values of normal variables. And the proposed fixes that use an alternate namespace to avoid collisions have already resolved that issue. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
