Summary: | environment cleaning of unsecvars by setuid/gid programs not documented | ||
---|---|---|---|
Product: | glibc | Reporter: | Joshua Rodman <jrodman> |
Component: | manual | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | NEW --- | ||
Severity: | minor | CC: | aj, bugdal, fweimer, glibc-bugs, ppluzhnikov |
Priority: | P2 | Flags: | fweimer:
security-
|
Version: | unspecified | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | 2012-05-06 00:00:00 |
Description
Joshua Rodman
2007-02-09 16:43:34 UTC
Still in glibc 2.15 This behavior is also non-conformant. The library should *ignore* such environment variables when the program was invoked as suid, but it should not prune them. A conforming application can expect to be able to inspect them (e.g. to validate them itself and use them for its own purposes if they're deemed safe) or have them successfully passed on to a new process or process image. This latter usage is safe if the program has dropped privileges before doing so, and if a program running with elevated privileges is going to exec or spawn child processes without dropping privileges, it MUST clear the whole environment or at least all but a small whitelisted set of variables to be secure. glibc's behavior of pruning the environment actually makes things a lot LESS secure in the latter case, because programmers may forget (or assume they don't need) to do this whitelist-based pruning themselves. This is not safe, because glibc only knows about the variables which it uses, not other third-party-library-specific or application-specific variables that could be equally dangerous. (In reply to comment #2) > This behavior is also non-conformant. The library should *ignore* such > environment variables when the program was invoked as suid, but it should not > prune them. FWIW, I recently had to implement a "setuid(); execve();" wrapper entirely in assembly, just so I could avoid this unsetting of LD_DEBUG, etc. by glibc. |