Hello, On Fri, Jan 14, 2022, at 17:07, Jason A. Donenfeld wrote: > On Thu, Jan 13, 2022 at 12:15 PM Hannes Frederic Sowa > <hannes@xxxxxxxxxxxxxxxxxxx> 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. Taking a step back, there is the base case where we don't have duplicate addresses on the network nor an attack is on-going. We would break those setups with that patch. And those are the ones that matter most. In particular those stable-random addresses are being used in router advertisements for announcing the next-hop/default gateway on the broadcast domain. During my time in IPv6 land I have seen lots of setups where those automatic advertisements got converted into static configuration for the sake of getting hands on a cool looking IPv6 address on another host (I did that as well ;) ). In particular, in the last example, you might not only have one administrator at hand to handle the issue, but probably multiple roles are involved (host admin and network admin maybe from different organizations - how annoying - but that's a worst case scenario). Furthermore most L2 attacks nowadays are stopped by smarter switches or wifi access points(?) anyway with per-port MAC learning and other hardening features. Obviously this only happens in more managed environments but probably already also at smaller home networks nowadays. Datacenters probably already limit access to the Layer 2 raw network in such a way that this attack is probably not possible either. Same for IoT stuff where you probably have a point-to-point IPv6 connection anyway. The worst case scenario is someone upgrading their kernel during a trip away from home, rebooting, and losing access to their system. If we experience just one of those cases we have violated Linux strict uAPI rules (in my opinion). Thus, yes, we care about both, (1) and (2) cases. I don't think we can argue our way out of this by stating that there are no guarantees anyway, as much as I would like to change the hash function as well. As much as I know about the problems with SHA1 and would like to see it removed from the kernel as well, I fear that in this case it seems hard to do. I would propose putting sha1 into a compilation unit and overwrite the compiler flags to optimize the function optimized for size and maybe add another mode or knob to switch the hashing algorithm if necessary. >> 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. This is a very pessimistic scenario bordering a nightmare. I hope the new hashing algorithm will protect them. ;) > 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? Given the example above, users might hardcode this generated IP address as a default gateway in their configs on other hosts. This is actually a very common thing to do. > (Feel free to smack this line of argumentation down if you disagree. I > just thought it should be a bit more thoroughly explored.) I haven't investigated recent research into breakage of SHA1, I mostly remember the chosen-image and collision attacks against it. Given the particular usage of SHA1 in this case, do you think switching the hashing function increases security? I am asking because of the desire to decrease the instruction size of the kernel, but adding a switch will actually increase the size in the foreseeable future (and I agree with Toke that offloading this decision to distributions is probably not fair). Maybe at some point the networking subsystem will adapt a generic knob like LD_ASSUME_KERNEL? ;) Bye, Hannes
