bugtraq - RE: TCP Port randomization paper

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Tue, 11 Dec 2007 15:56:31 +0200
From: Amit Klein <amit.klein@...steer.com>
To: bugtraq@...urityfocus.com
Cc: fernando.gont@...il.com
Subject: RE: TCP Port randomization paper

Hi Fernando+list

I'm glad to see that someone takes aim at this issue.

However, it seems that your proposal only attempts to address one 
consequence of predictable TCP source ports, namely blind TCP attacks 
(in all fairness, it appears that the object of your proposal is to 
solve the blind TCP attacks, rather than the issue of predictable TCP 
source ports; I look at it the other way around...). Naturally this is a 
major outcome, but there are still other consequences, perhaps less 
severe, such as traffic analysis. For example, the naïve (and as 
explained in your draft, flawed) algorithm in Fig. 1 of your IETF draft 
advances next_ephemeral globally. Therefore, if the attacker can force 
the target host to periodically establish a new TCP connection to an 
attacker controlled machine (or through an attacker observable routing 
path), the attacker can subtract consecutive source port values to 
obtain the number of outoing TCP connections established globally by the 
target host within that time period (up to wrap-around issues and 
5-tuple collisions, of course).

However, note that algorithm #3 in your proposal is also susceptible to 
the same technique.

Algorithm #4 is affected as well, to some degree. The "table" array 
compartmentalize the space into TABLE_LENGTH sections. An attacker can 
perform traffic analysis for any section into which the attacker has 
"visibility", namely that the attacker can force the server to establish 
connection whose G(offset) points to this section. The attacker has 
little control over to which section exactly the host will map the 
attacker's traffic, but once there, the attacker can monitor traffic 
volumes (new outgoing TCP connections) for this arbitrary section.

Again, I don’t know if this is in scope for your draft, but I do believe 
that looking at the generic problem here, this should be a factor.

Thanks, and good luck,
-Amit

 > -----Original Message-----
 > From: Fernando Gont [mailto:fernando.gont@...il.com]
 > Sent: Friday, December 07, 2007 02:45
 > To: bugtraq@...urityfocus.com
 > Subject: TCP Port randomization paper
 >
 > Folks,
 >
 > We have published a revision of our port randomization paper.
 > This is the first revision of the document since it was accepted as a
 > working group item of the tsvwg working group of the IETF (Internet
 > Engineering Task Force). Any feedback on the proposed/described
 > algorithms will be welcome.
 >
 > The document is available at:
 > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-rand
 > omization-00.txt
 >
 > Additionally, it is available in other fancy formats (PDF and HTML)
 > at: http://www.gont.com.ar/drafts/port-randomization/index.html
 >
 > Thanks,
 >
 > --
 > Fernando Gont
 > e-mail: fernando@...t.com.ar || fgont@....org PGP
 > Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
 >
 >
 >
 >
 >
 >