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_______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
