Comment by rwmj | Hacker News Reader

Comment by rwmj | Hacker News Reader

Parent Full thread

glibc APIs are occasionally deprecated, usually because they are broken or dangerous. A well-known example is gets[1] which is impossible to use without introducing a buffer overflow. Less well-known ones include readdir_r, sigpause, register_printf_function.

APIs are occasionally broken too, although that would be a bug.

At least one API is known buggy and hasn't been fixed: fts_open. It only works properly if used on 32 bit architectures. [Edit: I just noticed that glibc got around to fixing this - yay!]

glibc+Linux is not entirely conforming to POSIX - threads being a good example where it differs in some significant respects from what POSIX requires.

Sometimes POSIX itself isn't well defined. Until very recently it was not properly specified if a file descriptor is closed if close(2) returns an error. Some POSIX systems closed it, some didn't, some closed it on some errors but not on others; and most programs wouldn't retry the close on error so would leak the fd. It has since been changed so that the fd is always closed even in the error case.

[1] https://www.man7.org/linux/man-pages/man3/gets.3.html

> A well-known example is gets[1] which is impossible to use without introducing a buffer overflow.

Actually, it is possible to use gets() safely, under a sufficiently contrived set of circumstances. Since it reads from stdin, you just have to make sure that stdin reads from a pipe which has its write end under the control of the same process, and be careful to only ever write a limited amount of data to that pipe, smaller than the buffer of any gets() call in the process.

Fun fact: the linker complains at you when you try to use gets. It makes it rather annoying when you're trying to use it in a testsuite making sure your tool can handle some idiot using gets correctly...

I like to nitpick and point out gets() can be used safely, as a stunt.

Memory map a read/write page and after that memory map a no-permissions guard page. Now you can safely use gets() to read a page size string without allowing a buffer overflow.

Does gets() guarantee that it will write its output in order? If not it could in theory write after your guard page before touching the guard page itself. Of course I don't know if either the kernel or glibc would ever do this.

I think the only safe way to use gets() is with trusted input.

Why does the order matter? It'll only write to the guard page if the input string is long enough to necessitate it, in which case it was going to fault anyway regardless of which page it touched first.

Edit: I guess you're considering "used safely" to include reading a truncated string, in which case writing in order would allow the program to be written such that it recovers from the fault and reads the valid page-worth of string.

I think the parent meant that if your string was longer than the size of the read/write page plus the size of the guard page, and if gets() is allowed to, say, write the string from the end to the beginning (I think this is unlikely, but let's say it could), then it would try to write the last character (first) all the way out beyond your guard page, possibly scribbling on some memory that the application had allocated for something else.

If it can write past the guard page, even if your program faults afterwards, it could have already compromised the larger system. Not claiming that it can, just entertaining the what-if.

You could hypothetically have a situation where libc has an arbitrarily large internal FILE* buffer (instead of reading a block, looking for a newline, and copying everything over immediately), and then copies in reverse, corrupting data after the guard page before it hits the guard page.

If there are other threads accessing data that happens to be placed after the guard page, bad things could happen, but this seems rather unlikely to be a real problem.

Ah, right. >2 pages-worth of input would break the scheme.

Or if you own both sides of stdin...

If we're nitpicking, doesn't this technically not still allow a buffer overflow, just negate the consequences of it?

Actually gets() was deprecated in ISO C11.

... but this does not apply retroactively; nor are you required to use C11 to interface with libc. So maybe this will be impactful in, oh, 20-30 years from now? :-(

Whatever, the point being that this wasn't a decision from glibc developers.

As for what C version one is required to use alongside libc, UNIX is C's platform, on other OSes libc is part of the compiler not OS.

Also a post C11 compliant compiler is not required to still provide gets() in their libc for the case you use C89/C99 language mode.

Reply on news.ycombinator.com