Re: DCCP & port randomization

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Fernando,

Similar to TCP, DCCP is also connection-oriented and has a LISTEN state for server sockets. I also believe that implementations use the socket API for opening server DCCP sockets in a similar way that TCP does, so many issues are probably similar. But there is a relevant difference: DCCP service codes are intended to allow more flexible allocation of the ports, or even sharing a port by multiple applications. This might affect how one would like to phrase the issues below, in a case when two connections use different service codes. On the other hand, even then it might be safer to require that only unused DCCP ports are used as ephemeral ports, also in the interests of being consistent with TCP.

Thoughts, anyone?

- Pasi


On Jan 28, 2010, at 1:47 PM, Fernando Gont wrote:

Hello, folks,

Our port randomization I-D (draft-ietf-tsvwg-port-randomization) has
been shipped to the IESG.

Lars reviewed the I-D (see the current thread on the tsvwg mailing- list:
http://www.ietf.org/mail-archive/web/tsvwg/current/msg09679.html), and
asked a how a few specific issues would apply to transport protocols
other than TCP. So I'm posting the questions here in the hope that some
of you might know the answer and be so kind to help (see bellow).


Section 3.1., paragraph 10:
Port numbers that are currently in use by a TCP in the LISTEN state
should not be allowed for use as ephemeral ports.

(This to prevent an attacker from shijacking an incoming connection by
binding a port number on which a process is LISTENning for incoming
connections, and simulating a "simultaneous open" scenario). Are there
similar issues for DCCP?


Section 3.1., paragraph 13:
It should be noted that most applications based on popular
implementations of TCP API (such as the Sockets API) perform
"passive opens" in three steps.  Firstly, the application obtains a
file descriptor to be used for inter-process communication (e.g.,
by issuing a socket() call). Secondly, the application binds the
file descriptor to a local TCP port number (e.g., by issuing a
bind() call), thus creating a TCP in the fictional CLOSED state.
Thirdly, the aforementioned TCP is put in the LISTEN state (e.g.,
by issuing a listen() call). As a result, with such an
implementation of the TCP API, even if port numbers in use for TCPs
in the LISTEN state were not allowed for use as ephemeral ports,
there is a window of time between the second and the third steps in
which an attacker could be allowed to select a port number that
would be later used for listening to incoming connections.
Therefore, these implementations of the TCP API should enforce a
stricter requirement for the allocation of port numbers: port
numbers that are in use by a TCP in the LISTEN or CLOSED states
should not be allowed for allocation as ephemeral ports [CPNI-TCP]
[I-D.gont-tcp-security].

Are there similar issues for DCCP?

Thanks so much!

Kind regards,
--
Fernando Gont
e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1











[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux