Re: FreeBSD listen()

[scut () NB IN-BERLIN DE (Sebastian)]

On Wed, 27 Oct 1999, 3APA3A wrote:

> Hello,

hi.

> 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.

may receive an error ECONNREFUSED (may, not will)

> <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.
> -=-=-=-=-

With listen() it is unfortunatly a bit more complicated. Posix.1g says
that backlog "defines the maximum length the queue of pending connections
may grow to.". It is unclear whether the SYN_RCVD or the ESTABLISHED state
is meant. The kernel keeps two lists, one of a completed (ESTABLISHED
state) connections and one of the still-to-be-completed connections (in
SYN_RCVD state).
According to Stevens the backlog parameter in listen() has historically
specified the maximum value of the sum of both queues.

For some unknown reasons berkeley derived implementations multiply backlog
with 1.5. (backlog = 5 will turn to 8 for example).

> 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).

mhh... don't know about this :(

> 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.

may receive an error ... or the request may be ignored.

> 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

Limiting the incoming connections through backlog is insecure, if you do
not want any clients connecting to your listening sockets, then close the
sockets. Either the backlog parameter is multiplied (1 will be 2 on
BSD systems, to take care of the SYN_RCVD and ESTABLISHED state), or
different implementations will behave differently. Just close the socket.

  And btw, since the first incoming connection will be used, you can still
mount any classic "ftp-file-stealing" attack, it will even be better with
a backlog of 1, because the real client will timeout on the connection.

> 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.

ciao,
scut / teso security
[http://teso.scene.at/]

--
- scut () nb in-berlin de - http://nb.in-berlin.de/scut/ -  - http://nb.in-berlin.de/scut/ - sacbuctd@ircnet  --
-- you don't need a lot of people to be great, you need a few great to be --
-- the best -----------------------------------------------------------------
--- nuclear arrival weapon spy agent remain undercover, hi echelon ----------