svn commit: r199983 - in head: lib/libc/stdlib tools/regression/environ

[Robert N. M. Watson]

On 1 Dec 2009, at 11:25, Sean C. Farley wrote:

>>> We've already had two major security issues arising out of getenv.c in the past year, and I'd like to make sure we don't have a third.
>> 
>> I think it's fair to say that the POSIXization of the environment code has been an unmitigated disaster, and speaks to the necessity for careful review of those sorts of code changes.
> 
> As the author of the environment code, I agree that it has been a painful process.
> 
> Interestingly, the security issue was a combination of r169661 to rtld.c, which is a correct action, and the new environ code which was developed, as opposed to committed, at the same time.  Separately, the security issue would not have existed.

One immediately pressing question is whether we can mitigate future possible problems along the same lines. The obvious thing is a further (and very careful) audit if all environmental variable use in the base system. But I wonder if there are some other things we could do, such as:

- libc environment scrubbing: try to be more robust in the presence of the unexpected (for example, if you find corrupted stuff, ignore it more robustly); another variation might be to have libc abort(2) if issetugid() and unsetenv(3) would fail.
- kernel environment scrubbing: the kernel is already responsible for getting those variables across the execve(2) boundary, so is already copying (and to a lesser extent, validating) it, and could learn to be a bit more rigorous in its expectations, perhaps more so for security-sensitive transitions (setuid/setgid/MAC/...)

Brian's changes, although poorly timed, seem like a reasonable direction in this regard: we're stuck with unhelpful APIs, but maybe we can do a better job.

Robert