Dear David LeBlanc,
You're absolutely right, there is no buffer overflow under Windows. I
just want to point checking FD_SETSIZE before select() and it's macros
should become good coding practice for both Windows and Unix. Currently
it's not. If Windows application uses select() and doesn't check
FD_SETSIZE it will misbehave, because there is no chance to check FD_SET
result. As an example it may lead to sockets leak and DoS through
resource consumption.
Windows example in advisory was given mostly to explain strange Cygwin
approach. Cygwin defines FD_SETSIZE as 64, but exports Unix style
bitmap-based fd_set structure and FD_SET macro without FD_SETSIZE
checking in headers. It's because later it's converted to Windows-style
fd_set structure before using winsock's select(). It's extremely
dangerous, cygwin-ported server should not be used in production
environment.
--Saturday, January 29, 2005, 12:00:12 AM, you wrote to 3APA3A@security.nnov.ru:
DL> defines maximum number of sockets in this array. So, Windows
DL> application may be vulnerable only if it places a large number of
DL> sockets into same fd_set structure (finite state machine
DL> architecture).
For Windows default FD_SETSIZE is 64 and select() is only
DL> POSIX-complatible function to wait on socket input (there is no poll(),
DL> but there are Windows specific functions).
DL> [snip]
DL> if (((fd_set FAR *)(set))->fd_count < FD_SETSIZE) { \
DL> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
DL> So if you attempted to put FD_SETSIZE + 1 sockets into an fd_set, it
DL> would just fail.
--
~/ZARAZA
Да, ему чертовски повезло. Эх и паршиво б ему пришлось если бы он выжил! (Твен)
