On 30/01/2010 20:35, Fernando Gont wrote:
Hello, Gorry,
Thanks so much for your response. Comments in-line...
A listening DCCP server process is bound to both a server-port AND a
service code(SC) (RFC 5595, section 3.3). As such in DCCP, an attacker
would need to guess not only the ports but also the SC. If well-known
ports are used, then I do not expect the SC mechanism to generally
provide additional protection, since this would normally make the SC
well-known.
So... in this case it seems the general motivation for port
randomization still applies... right?
Yes - the DCCP client-sized benefits seem like they could be useful.
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?
The base specification of DCCP defined in RFC 4340 does not provide a
method equivalent to the simultaneous open method of TCP. An update to
DCCP, specified in RFC 5956 added support for the DCCP-Listen packet.
This should have been RFC 5596.
This assists DCCP applications to communicate through middleboxes in a
way similar to the TCP Simultaneous-Open method.
The port randomisation procedure says on paged 10:
Port numbers that are currently in use by a TCP in the LISTEN state
should not be allowed for use as ephemeral ports. If this rule is
not complied, an attacker could potentially "steal" an incoming
connection to a local server application by issuing a connection
request to the victim client at roughly the same time the client
tries to connect to the victim server application [CPNI-TCP]
I think this particular attack may not apply to DCCP. If I understand
this right, the TCP attack above plays on the feature that TCP can send
an Open packet in both directions.
See Figure 8 (Page 32) of RFC 793. That scenario is unlikely to happen
"by chance" (as the "client" is using an ephemeral port that the server
doesn't know in advance). However, if the client port numbers are
predictable (or, well, he could do it brute force, too), an attacker on
the server-side could fake that scenario to hijack an incoming connection.
So the question in this regard wrt DCCP would be: if there's a process
"listening" for incoming connections (on, say "any IP address, port X"),
and an attacker on the same host is allowed to bind() a more-specific
socket (say, "IP address, port number X" or "IP address, port number X,
service code Y") to steal an incoming connection request?
I think this could be possible for DCCP - but one also needs to be aware
of the role of service codes here. Two or more server apps could use a
different DCCP Service Code value and also be bound to the same server
port(s). See also section 3.3.1 of RFC 5595.
So for DCCP - if there is a perceived need to update the rules
controlling which sockets can be bound to a port, this needs to be based
on the SC, NOT just the port number.
I'd like to make a note about both UDP and DCCP: There probably are
specific cases where port randomisation would interact with other specs.
Here is an example: Header compression could be a concern for DCCP
applications targeting multimedia over wireless, where predictable use
of port numbers could offer a little advantage. In some cases neither
port will be well-known and there is the case of so-called "symmetric"
RTP, where both ports are the same. I'm not saying any of these are a
show-stopper, far from it, I would have noted that earlier if I had
thought so - it is just a reminder that datagram protocols can have
different needs.
Wouldn't the app bind() the port it wishes to use, rather than simply
let the kernel select a port number for it?
Unless the app requests a specific ports, IMO the app would be very
non-portable (i.e., can you really depend on the underlaying ephemeral
port selection algorithm for your app to work properly?).
Perhaps, but I think it could also use a dynamic port value - there's
often more information than port # needed to setup a media flow - to do
any form of simultaneous-open, etc in DCCP you need a signaling
protocol (e.g. SDP record) to setup the server-side association, so you
could agree the ports when you agree RTP params. etc.
That said, the hash-based port-randomization algorithms do provide port
numbers that are predictable by the destination endpoint, but at the
same time are not predictable by an off-path attacker. (they use a
RFC1948-like scheme... therefore the properties of the "algorithm" are
the same as the ones of RFC1948 for ISN generation).
So, I think it is possible that an implementor could choose a DCCP
design at the client that uses different rules to those that will be
specified in this BCP for TCP - especially since SCs increase the
flexibility in using ports (as Pasi mentioned - this can include sharing
well-known ports between Apps).
As mentioned above, recommending port randomization (when the port
number is selected by the kernel) doesn't preclude an app from bind()ing
a specific port it wishes to use.
Good.
Thanks!
Kind regards,
Gorry
