(I'm redirecting this back to this list -- there might be others
that are interested)

Someone wrote (off-list):
> 
> What is the inherent danger in URG data? I know that interactive apps rely
> on this for things like quit and control c etc.?

The inherent danger is in applications that do not process urgent
data properly.

An example of this (using the BSD socket interface) is:

  // insert socket "sock" in readfds, writefds and exceptfds
  while(select(sock+1, &readfds, &writefds, &exceptfds))
  {  // note beautiful brace positioning, you open source dweebs :)
    if(FD_ISSET(s, &readfds))
      ... despool and process inbound data ...
    if(FD_ISSET(s, &writefds))
      ... send stuff that needs to be sent ...
  }

Note how this snippet does NOT check for "exceptional" (urgent) 
data. This will snag the application in a tight loop, since
the select() call will always return "something available",
and the application will never despool it.

I believe this is what occured when win9x was shown to be
vulnerable to "WinNuke", which basically connected to 
port 139 and shoved some urgent data across the connnection.

Of course, on a win9x box with substandard process handling,
this would cause all sorts of nastiness, especially if it
were to happen to the SMB (NetBIOS) drivers.


(Note that this is only what I THINK is what happened in 
WinNuke. I don't know for sure.)

This same sort of screw-up can happen in any application. 
The results may just not be as... fatal... on a better 
operating system.

Also note that applications do not automagically become
immune to URG problems if behind a proxy. There are cases
where the proxy forwards the urgent signals.


-- 
Mikael Olsson, Clavister AB
Storgatan 12, Box 393, SE-891 28 �RNSK�LDSVIK, Sweden
Phone: +46 (0)660 29 92 00   Mobile: +46 (0)70 26 222 05
Fax: +46 (0)660 122 50       WWW: http://www.clavister.com
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
http://lists.gnac.net/mailman/listinfo/firewalls

Reply via email to