linux-kernel - Re: [PATCH RFC v1 2/3] ipv6: move from sha1 to blake2s in address calculation

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: <CAHmME9pR+qTn72vyANq8Nxx0BtGy7a_+dRvZS_F7RCag8Rvxng@mail.gmail.com>
Date:   Fri, 14 Jan 2022 17:07:56 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:     Toke Høiland-Jørgensen <toke@...hat.com>,
        Netdev <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Ard Biesheuvel <ardb@...nel.org>,
        Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Erik Kline <ek@...gle.com>,
        Fernando Gont <fgont@...networks.com>,
        Lorenzo Colitti <lorenzo@...gle.com>,
        YOSHIFUJI Hideaki <hideaki.yoshifuji@...aclelinux.com>
Subject: Re: [PATCH RFC v1 2/3] ipv6: move from sha1 to blake2s in address calculation

Hi Hannes,

On Thu, Jan 13, 2022 at 12:15 PM Hannes Frederic Sowa
<hannes@...essinduktion.org> wrote:
> > I'm not even so sure that's true. That was my worry at first, but
> > actually, looking at this more closely, DAD means that the address can
> > be changed anyway - a byte counter is hashed in - so there's no
> > guarantee there.
>
> The duplicate address detection counter is a way to merely provide basic
> network connectivity in case of duplicate addresses on the network
> (maybe some kind misconfiguration or L2 attack). Such detected addresses
> would show up in the kernel log and an administrator should investigate
> and clean up the situation.

I don't mean to belabor a point where I'm likely wrong anyway, but
this DAD business has kept me thinking...

Attacker is hanging out on the network sending DAD responses, forcing
those counters to increment, and thus making SHA1(stuff || counter)
result in a different IPv6 address than usual. Outcomes:
1) The administrator cannot handle this, did not understand the
semantics of this address generation feature, and will now have a
broken network;
2) The administrator knows what he's doing, and will be able to handle
a different IPv6 address coming up.

Do we really care about case (1)? That sounds like emacs spacebar
heating https://xkcd.com/1172/. And case (2) seems like something that
would tolerate us changing the hash function.

> Afterwards bringing the interface down and
> up again should revert the interface to its initial (dad_counter == 0)
> address.

Except the attacker is still on the network, and the administrator
can't figure it out because the mac addresses keep changing and it's
arriving from seemingly random switches! Plot twist: the attack is
being conducted from an implant in the switch firmware. There are a
lot of creative different takes on the same basic scenario. The point
is - the administrator really _can't_ rely on the address always being
the same, because it's simply out of his control.

Given that the admin already *must* be prepared for the address to
change, doesn't that give us some leeway to change the algorithm used
between kernels?

Or to put it differently, are there _actually_ braindead deployments
out there that truly rely on the address never ever changing, and
should we be going out of our way to support what is arguably a
misreading and misdeployment of the feature?

(Feel free to smack this line of argumentation down if you disagree. I
just thought it should be a bit more thoroughly explored.)

Jason