Sourceware Bugzilla – Full Text Bug Listing
|Summary:||no protection against using fd_set with fd>1024|
|Product:||glibc||Reporter:||Kees Cook <kees>|
|Component:||libc||Assignee:||Ulrich Drepper <drepper.fsp>|
|Severity:||normal||CC:||bressers, bugdal, glibc-bugs|
Description Kees Cook 2009-06-30 20:06:20 UTC
When a program using select() starts tracking file descriptors above 1024, the fd_set vector (128 bytes) will overflow, writing to whatever is beyond the vector, leading to stack/heap corruption. This is a known, old, issue. Examples: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-1500 http://marc.info/?l=bugtraq&m=110660879328901 It is perfectly valid to use select() on a user-allocated vector that IS large enough to handle the the fds being tracked, but it seems that glibc should take some proactive measures to help applications that are not checking FD_SETSIZE. It was pointed out that SSH, e.g. uses this to work around the issue: fdset = (fd_set *)xcalloc(howmany(maxfd + 1, NFDBITS) Some ideas could be to flag FD_ZERO as dangerous? Or to check sizeof(...) on select() inputs? I would love to see a reasonable approach to protecting applications that aren't prepared for RLIMIT_NOFILE to be >1024. :) Also being tracked here: https://bugs.launchpad.net/bugs/386558 Thanks!
Comment 1 Ulrich Drepper 2009-10-30 06:30:54 UTC
select is what it is. Every program using it must be considered buggy.
Comment 2 Josh Bressers 2011-05-02 15:19:21 UTC
Ulrich, Could I convince you to revisit this bug? This issue is currently being hit by some enterprise sized daemons (lots of open fds). The biggest issue is that almost every use of select is wrong, so fixing them all in a timely manner is rather impractical. Some projects like Samba have already moved to poll(), but they're now hitting fd issues in various libraries. I do agree that this is a library bug, but I think given the situation, it could make sense to add a fix for this to glibc to prevent buggy select use from overwriting arbitrary bits in memory. It's obvious that most projects don't use select() properly, even though its correct use is documented in the man pages. Thanks.
Comment 3 Ulrich Drepper 2011-05-03 00:31:51 UTC
(In reply to comment #2) > Could I convince you to revisit this bug? No. Any such change breaks existing code since there are programs which redefine the set size and do other stupid things.
Comment 4 Rich Felker 2011-05-03 20:05:03 UTC
Wouldn't it be reasonable to range-check the file descriptor when security-related feature test macros (perhaps FORTIFY_SOURCE) are enabled? By the way, POSIX specifies that passing fd values greater than or equal to FD_SETSIZE to the FD_* macros/functions results in undefined behavior, so programs which want to *try* using select with higher fds should do it by allocating an *array of fd_set objects* with (maxfd+FD_SETSIZE)/FD_SETSIZE elements, then performing operations like FD_SET(fd%FD_SETSIZE, &fds[fd/FD_SETSIZE]); -- this also avoids dependency on nonstandard and nonportable macros like NFDBITS.