FreeBSD listen()

[3APA3A () SECURITY NNOV RU (3APA3A)]

Hello,

Can  someone  explain,  why  behavior of listen() backlog parameter in
FreeBSD is different from documentation? I'm not expert in FreeBSD and
Unix  at  all,  so  sorry if this problem is well-known or there is no
problem at all.

LISTEN(2) says:

-=-=-=-=-
int
listen(int s, int backlog)

<skipped>
The backlog parameter defines the maximum length the queue of pending
connections may grow to.  If a connection request arrives with the queue
full the client may receive an error with an indication of ECONNREFUSED,
or, if the underlying protocol supports retransmission, the request may
be ignored so that retries may succeed.

<skipped>
HISTORY
     The listen() function call appeared in 4.2BSD. The ability to configure
     the maximum backlog at run-time, and to use a negative backlog to request
     the maximum allowable value, was introduced in FreeBSD 2.2.
-=-=-=-=-

But:   for  FreeBSD  2.2.* backlog parameter seems doesn't working. At
least, if I use
listen(sock, 1)
and  trying to connect() from 3 different connections all 3 connect()s
succeed  atleast  in  FreeBSD  up  to  2.2.6  (later  versions are not
tested).

FreeBSD 3.* is different, but not perfect - extra connect() attempt is
always  ignored  (i.e. timed out) then backlog is exceeded. Connection
will never be rejected with ECONNREFUSED as stated in documentation.

This fact causes problems. Some application (for example ftp server in
passive mode or ftp client in active mode) use
listen(data, 1);
accept(data,...);
close(data);
to  limit  the  number of incoming data connections to exactly one. If
second  connection  is not rejected it makes possible attack to inject
or  intercept  data  between  server  and  client  as described in NAI
bulletin

http://www.nai.com/nai_labs/asp_set/advisory/ftp-paper.asp

and realized in exploit posted to Vuln-dev, see

http://www.securityfocus.com/templates/archive.pike?list=82&date=1999-10-15&msg=9628.991015 () SECURITY NNOV RU

exploit  doesn't  work against 3.x BSD ftp client because 3.x seems to
have  some  built-in  protection  against SYN flood or similar attacks
which  prevents  frequent  connect()  attempts  exploit uses. But this
fact doesn't eliminates problem itself.

         /\_/\
        { . . }     |\
+--oQQo->{ ^ }<-----+ \
|  3APA3A  U  3APA3A   }
+-------------o66o--+ /
                    |/
http://www.security.nnov.ru