Hacker News Reader

Comment by simias | Hacker News Reader

IMO getenv's API itself is to blame since it won't let you provide a buffer. As such if the libc wants to provide a local buffer it has to figure out a way to allocate it for the caller.

As far as I can tell glibc's implementation is probably what the people who designed getenv in the first place had in mind, just return a pointer to a global buffer. At best FreeBSD managed to create a workaround for modern environments.

There are unfortunately many such oddities in the standard libc APIs, remnants from an other time. Let us remember that "gets" was standardized as part of the C standard at some point, a function that's by design literally impossible to use safely.

View on HN

> Let us remember that "gets" was standardized as part of the C standard at some point, a function that's by design literally impossible to use safely.

It _is_ possible in theory to use gets safely, as long as your standard input is trusted. For instance, if a process forks and connects the standard input in the child to a pipe from the parent, which always writes a fixed amount of data to the pipe, you can use gets() without risk of overflow.

(This is a really contrived scenario, but I don't know of any simpler one where using gets() is safe.)

> It _is_ possible in theory to use gets safely, as long as your standard input is trusted.

Only if we define "trusted" to include "known to be bug free" in e.g. it's truncation or bounding of output over the pipe to the child. I argue that, in theory, this is impossible to know, and thus that it this level of trust is impossible, and thus that this is not an example of a potential safe use of gets.

Even a mathematical proof of safety, after all, could contain errors - or could prove the wrong thing - or could apply to the code as written and not the code as messed with by your optimizer - or another thread - or an injected dll - or ...

> For instance, if a process forks and connects the standard input in the child to a pipe from the parent, which always writes a fixed amount of data to the pipe, you can use gets() without risk of overflow.

This is also insufficient - one must also prevent nonstandard invocations of the child process. Even if your normal parent process gives the child input that is 100% safe, that's no guarantee that an attacker won't launch your child process in an unusual manner. If the child process is suid, for example, this would be a potential avenue for privilege escalation.

> Only if we define "trusted" to include "known to be bug free" in e.g. it's truncation or bounding of output over the pipe to the child. I argue that, in theory, this is impossible to know, and thus that it this level of trust is impossible, and thus that this is not an example of a potential safe use of gets.

"In the security engineering subspecialty of computer science, a trusted system is a system that is relied upon to a specified extent to enforce a specified security policy. As such, a trusted system is one whose failure may break a specified security policy." -- https://en.wikipedia.org/wiki/Trusted_system

That's the definition of "trusted" I'm using.

> This is also insufficient - one must also prevent nonstandard invocations of the child process.

I'm thinking of pure fork(), not fork+exec. That is, the child process is the same executable image, so the only way to invoke the child process in a nonstandard way would be through a debugger. And that is why the child process can trust the parent process in my example: they're the same process until the fork().

(As I said, it's a really contrived scenario. In more realistic scenarios, gets() is unsafe.)

Well, on Linux, there are various hardening mechanisms that lock down ptrace, as well as things like /proc/PID/mem/, but I don't think the same restrictions apply to grabbing fds from other processes via /proc/PID/fd/. So in theory a process running as the same user (but which can't just debug your process due to hardening) could steal your pipe and exploit your program... probably not a terribly realistic threat, but a contrived objection to a contrived scenario :)

> Let us remember that "gets" was standardized as part of the C standard at some point, a function that's by design literally impossible to use safely.

Which thankfully was removed by recent standard revisions of C and C++, meaning a compliant compiler isn't required to provide it any longer.

Actually, what we should remember is that setenv, clearenv, unsetenv, and putenv came along a lot later than getenv. There was a fair while when the general mental model was that the environment was immutable.

gets is impossible to use safely with unformatted input, which need not be the case.

Reply on news.ycombinator.com