Conversation

Replying to
AFAICT this tweet is nearly-free money to any bug bounty folks. Thanks to for the info. Please donate to musl C If you can. (It’s nothing new; you can find the same advice posted on Hacker News, but I guess the security ramifications haven’t been fully appreciated.)
1
6
To spell it out: Some libraries attempt to provide a thread-safe wrapper around every libc function that might access the environment, and then use coding conventions to enforce that these “safe” wrappers are used. This fails for multiple reasons:
1
7
1. There might be multiple wrappers. For example, Ruby has one, Rust has one, NSPR/NSS has one. All with separate locks. 2. Only a subset of functions have wrappers, and this subset appears to often be based on POSIX/ISO’s list, or just the environment API.
1
7
3. Some are a bad idea to call while holding a lock, e.g. getaddrinfo (Not in the POSIX list). 4. POSIX/ISO don’t guarantee that a lock is sufficient anyway, even if you successfully wrap every function with a locking wrapper.
2
6
You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more
Replying to
Imagine another thread modifies the environment, while getaddrinfo is looking up that environment variable. getaddrinfo is then potentially reading garbage, perhaps outside the environment completely.
1
1
You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more
Replying to and
proposal: process environment is frozen on startup, and putenv only affects a separate derived environment used to fork children. whatever breaks deserves it.
1
1
Replying to and
Well, for execing children, you get to specify your own environ[] at exec time, and that's the right way to do it. putenv/setenv have no role here. They do have a 'legitimate' role in some legacy single-threaded software that does stuff like overriding or changing its timezone.
1
1