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: <1335104462.3209.377.camel@deadeye>
Date:	Sun, 22 Apr 2012 15:21:02 +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 Sun, 2012-04-22 at 14:20 +0900, Tetsuo Handa wrote:
> Ben Hutchings wrote:
> > 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.
> 
> So, the purpose was to make the initial sequence number more random. OK.
> 
> > 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.
> 
> My concern is the purpose of making the automatic local port number selection
> algorithm less random. That commit removed uptime factor from factors that
> determine starting point of available local port scanning (due to removal of
> periodic get_random_bytes() calls).
> 
> 368 static inline u32 inet_sk_port_offset(const struct sock *sk)
> 369 {
> 370         const struct inet_sock *inet = inet_sk(sk);
> 371         return secure_ipv4_port_ephemeral(inet->inet_rcv_saddr,
> 372                                           inet->inet_daddr,
> 373                                           inet->inet_dport);
> 374 }
> 
> secure_ipv4_port_ephemeral() no longer depends on uptime.
> 
> 565 int inet_hash_connect(struct inet_timewait_death_row *death_row,
> 566                       struct sock *sk)
> 567 {
> 568         return __inet_hash_connect(death_row, sk, inet_sk_port_offset(sk),
> 569                         __inet_check_established, __inet_hash_nolisten);
> 570 }
> 
> inet_sk_port_offset() no longer depends on uptime.
> It returns same port offset for same addresses.
[...]

All this randomisation is concerned with preventing spoofing attacks by
attackers that can't see any packets routed to the spoofed address.  If
they can see the return packets then this is all in vain, which is why
we generally want cryptography at the transport or application level.
But if they can't then the port offset remains secret - right?

(Port randomisation is not very useful on it own due to the small number
space, but see
<http://en.wikipedia.org/wiki/DNS_cache_poisoning#Prevention_and_mitigation>.)

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