10352 2009-06-30 20:06:00 +0000 no protection against using fd_set with fd>1024 2011-05-03 20:05:03 +0000 1 1 1 Unclassified glibc libc unspecified All All RESOLVED WONTFIX P2 normal --- 1 kees drepper.fsp bressers bugdal glibc-bugs 36962 kees 2009-06-30 20:06:20 +0000 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! 39379 drepper.fsp 2009-10-30 06:30:54 +0000 select is what it is. Every program using it must be considered buggy. 48483 bressers 2011-05-02 15:19:21 +0000 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. 48488 drepper.fsp 2011-05-03 00:31:51 +0000 (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. 48509 bugdal 2011-05-03 20:05:03 +0000 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.