netdev - Re: Question with secure_ipv4_port

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1335065393.3209.361.camel@deadeye>
Date:	Sun, 22 Apr 2012 04:29:53 +0100
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
CC:	<netdev@...r.kernel.org>
Subject: Re: Question with secure_ipv4_port_ephemeral() implementation

On Fri, 2012-04-20 at 21:30 +0900, Tetsuo Handa wrote:
> Commit 6e5714ea "net: Compute protocol sequence numbers and fragment IDs using
> MD5." removed periodic get_random_bytes() calls. After that commit,
> 
>   static u32 net_secret[MD5_MESSAGE_BYTES / 4] ____cacheline_aligned;
> 
> is filled with random bytes for only once upon boot and is never updated again.
> Then, shouldn't net_secret be marked as __read_mostly?
> 
> Just from curiosity... what was the reason for changing
> secure_ipv4_port_ephemeral() generate same return value for same arguments?
> Was periodically changing return value for same arguments unfriendly with NAT
> or something?

The commit message says:

> Furthermore, only having 24-bits of the sequence number be truly
> unpredictable is a very serious limitation.  So the periodic
> regeneration and 8-bit counter have been removed.  We compute and
> use a full 32-bit sequence number.

As I understand it, that 8-bit counter was used for all connections, so
in order to spoof the source of a TCP connection it was only necessary
to guess 24 bits of the ISN.  On a sufficiently fast network, it would
now be feasible to carry out a brute force attack that ACKs all possible
ISNs before the handshake times-out.  That's not yet feasible if the
attacker has to guess all 32 bits of the ISN.

The original reason for periodically regenerating the secret was that
the hash function was quite weak and the secret could presumably be
found in a reasonably short time.  So, without regeneration, the hash
also has to be stronger.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html