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 20:15:48 -0300
From: "Fernando Gont" <fernando.gont@...il.com>
To: "Amit Klein" <amit.klein@...steer.com>
Cc: bugtraq@...urityfocus.com, "Fernando Gont" <fernando@...t.com.ar>
Subject: Re: TCP Port randomization paper

Hello, Amit,

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

Not really. While the motivation of the draft was motivated by the
blind attacks that received some attention in the last few years, it's
not necessarily limited to addressing blind attacks. The draft does
mention (and provides references to) blind attacks because they have
received some attention during the last few years, and because the
IETF has ongoing work on those issues. But I think the issues you
raise are well within the scope of our draft.

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

Good point. I will try to add some text about this issue in the next
revision of the draft.

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

Good point, too.

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

Well, I guess this is the point at which an engineering decision is
made. I mean, if one is concerned with traffic analysis, then make
TABLE_LENGTH as large as possible. e.g., with only 2KB of memory, you
could compartmentalize the port sapce into 1024 sections.

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

Agreed. I will try to address the issues you raised in the next
revision of the draft.

Thanks!

Kind regards,
Fernando Gont