Re[2]: SECURITY.NNOV: Multiple applications fd_set structure bitmap array index overflow

[3APA3A <3APA3A@xxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxx:

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
Да, ему чертовски повезло. Эх и паршиво б ему пришлось если бы он выжил! (Твен)