linux-kernel - Re: [PATCH 5.4 175/244] inet: use bigger hash table for IP ID generation

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]

Date:   Wed, 16 Jun 2021 15:58:06 +0200
From:   Willy Tarreau <w@....eu>
To:     David Laight <David.Laight@...LAB.COM>
Cc:     "'Amit Klein'" <aksecurity@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        "David S. Miller" <davem@...emloft.net>,
        Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 5.4 175/244] inet: use bigger hash table for IP ID
 generation

On Wed, Jun 16, 2021 at 01:42:17PM +0000, David Laight wrote:
> > This patch mitigates some techniques that leak internal state due to
> > table hash collisions.
> 
> As you say below it isn't really effective...

Actually it's Amit's attack which is really effective against anything
that is not 100% random. And as you mentioned yourself in another thread,
full randomness is not desirable as it can result in big trouble with ID
collisions, especially when limited to 16 bits only. The only remaining
factor to act on is thus the number of buckets to reduce the effectiveness
of the attack.

> > > Why should my desktop system 'waste' 2MB of memory on a massive
> > > hash table that I don't need.
> > 
> > In the patch's defense, it only consumes 2MB when the physical RAM is >= 16GB.
> 
> Right, but I've 16GB of memory because I run some very large
> applications that need all the memory they can get (and more).

Then by all means if your system is so tightly sized, buy this extra
2 MB DRAM stick you're missing, and install it next to your existing
16GB one.

> > Security-wise, this approach is not effective. The table size was
> > increased to reduce the likelihood of hash collisions. These start
> > happening when you have ~N^(1/2) elements (for table size N), so
> > you'll need to resize pretty quickly anyway.
> 
> You really have to live with some hash collisions.

Absolutely, and that's the principle, that at some point it costs
enough to the attacker for the attack to not be affordable or at
least be easily detectable. All this for 1/8192 of your total RAM
in the worst case, you will not notice more than when some fields
are added to certain important structures and probably much less
than when you simply upgrade whatever lib or binary. And probably
that you forgot to reduce the amount of RAM dedicated to the video
in your BIOS and can salvage no less than 32MB there!

Willy