Proof-of-concept code released for zero-click critical IPv6 Windows hole Windows users who haven't yet installed the latest fixes to their operating systems will need to get a move on, as code now exists to exploit a critical Microsoft vulnerability announced by Redmond two weeks ago. The flaw, CVE-2024-38063, has a CVSS score of 9.8 since it would allow an unauthenticated attacker to run code …
I mean if IPv6 is not configured(but still enabled on the windows system), and there are no IPv6 routers on the local network, no other devices running IPv6, it's not as if you can just configure IPv6 on a single system and expect to connect to anything using that protocol? That said, on Linux at least I do go out of my way to disable IPv6(kernel option ipv6.disable=1), just to make things simpler because there is no IPv6 network to connect to(don't anticipate that changing in the next 5+ years) and I just prefer it to be more clean. There is inbound IPv6 support to the e-commerce website I support but that is NAT'd to IPv4 at the CDN transparently.
I remember back in 2001, the Extreme Networks Summit 48 I had for our office at the time had a protocol support thing. Default was all protocols but then you could restrict it to say just I want to say IP traffic or something like that? I recall setting that option, everything worked fine, except one or two people that used Macs complained due to whatever protocol Mac was using(forgot the name) was being rejected by the switch so I went to the switch and just allowed all. Haven't seen that particular feature in switches since (though I'm sure could be handled manually using ACLs, this was a simple drop down box selection in the web UI).
Well guys, have you tried to turn off ipv6 on a window system?
Disable it in the ncpa.cpl (yea, back way to network config) and then watch it with another system running Wireshark.
Baby will do anything to phone home to mom.
You can only truly kill it with a firewall or router.
Unless you explicitly disable IPv6, Windows automatically generates a link-local address. In which case, even if you have v6 disabled on your gateways, the vulnerability can be exploited by anyone on the same network segment.
End of the day yesterday, I had much fun tormenting the handful of my colleagues who were still unpatched.
"The only workaround is to disable IPv6 and rely instead on IPv4, - which isn't realistic for many people."
Erm, using IPv6 is unrealistic for me... very few consumer-level broadband providers in the UK even bother with it, it seems. Because of this, my (non-supplier-provided) router has it completely turned off. So I'm guessing I'm safe...?
Depending on your set up you are probably already using IPv6 on your LAN, for local network not necessary for router to support IPv6.
On my network, Windows tends to prefer IPv6 when talking to printers over IPv4, naturally I don’t see this as either the printer wizard has done it for me or Mopria (what underpins the Windows 10 universal print system) does it.
As others have noted, Windows wants to create at least a link-local IPv6 interface.
The question is really "can an attacker inject IPv6 traffic into your unpatched Windows system?". For a lot of home systems, that might be difficult — though if you have a vulnerable router, perhaps not. (Whether anyone would bother is another question.) For a lot of corporate systems exposed to IPv6 on the Internet, it's much more feasible.
Incidentally, I recommend Hutchins' blog post (which I read before this Register story appeared; his blog is in my RSS feed). As usual, it provides some nice insight into how patch reverse-engineering and exploit development can be done. It's also interesting to see how Microsoft's fix for this issue is "prevent going down the vulnerable code path" rather than actually fixing that path. (The underlying bug is setting the packet size to 0 when encountering certain invalid options, followed by an integer underflow when processing a list of packets, and that's not what they fixed.)
You're right – I just checked and it has indeed got a link-local address set up. But that's all, because my Beryl is set to not assign v6 addresses or route v6 traffic (even locally). (As noted, I have no outbound IPv6 pipe, and there's really no need for it internally when I have a dozen LAN clients, tops. It just simplifies the setup (plus, I can remember all the IPv4 addresses I need to...).) So, I reckon remotely injecting IPv6 traffic onto anything would be a struggle, even if the local link is enabled. And if they can do it on the local link, well, they're basically already in, as far as I can see, so no point shutting that stable door.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
