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

[Brian Fundakowski Feldman]

On Tue, Dec 01, 2009 at 11:29:12AM -0500, Robert N. M. Watson wrote:
> 
> 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.

An abort() makes more sense than an error return where no error is ever
expected (i.e. expecting unsetenv(3) to never fail is quite reasonable).

> - 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.

Do you see a clear advantage to scrubbing environment in the kernel versus libc?
The libc environ functions will still need to be able to do it upon change
of the environ pointer, so there's some duplication of functionality; but then
again there may be iffy environ-using logic in things you run which are not
using the /lib/libc.so.

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\