Some feedback and ping back

[tijldeneut]

Hi, got it to work perfectly, even managed to crash Win Server 2022 with Firewall enabled. Tested on VMware Workstation.

I expanded your work a little bit with some scripts of my own:

• Created a checker to safely assess a vulnerable system, this requires a disabled Firewall, but works perfectly when run on Windows
• In my research a MAC address seems to be required for Scapy, so I wrote a IPv6 Neighbor Discovery routine to try and find the MAC address
• I managed to get it working on Windows too, when run as administrator. But timing is tricky so your mileage may vary, for exploitation, Linux is better

Checker: https://github.com/tijldeneut/Security/blob/master/CVE-2024-38063-Checker.py Exploit: https://github.com/tijldeneut/Security/blob/master/CVE-2024-38063-DOS.py

Thanks again, love the work.

[ynwarcs]

hey, thanks for the feedback.

• In local testing (host -> VM) scapy does seem to need an explicit mac address, but was able to work it out on its own when I tested it against a live server. Using ND is definitely better than having to find it manually or relying on IPv6 ping-backs so your script is definitely helpful in that regard. I was quite lazy to do it myself and verify it's correct in most cases, so I suggested the manual method as it's foolproof :)
• As far as I see (didn't test), your checker works by sending a malformed destination options helper and expecting an ICMPv6 error response in return. However, this behaviour should also be present on a fully patched system, as the IppSendError call is still there. To find out whether the system is vulnerable, we would need to determine if an error is thrown out for more than just the initial destination options packet, as this would be in line with the behaviour of IppSendErrorList. For example, we could send a packet with a malformed destination options header followed by a packet with a properly formed one. Analyzing the number of response packets would then tell us whether the system is vulnerable. The main obstacle though is the fact that we don't know whether the packets were coalesced, so it's possible we'll be receiving only a single error, not due to the system being patched, but due to the fact that packets aren't being coalesced.
• I haven't had much trouble running the scripts on either Windows or Linux but I know there can be trouble due to Windows preventing packet modifications on some layers, so I'd definitely suggest sticking with linux.

I want to leave the original poc in this bare bones format to keep it simple, but I wouldn't mind linking to your work in the readme, so that others can make use of them. I won't be doing much more work on this vulnerability as I have to focus on something else, but I can give a quick test to the scripts and link to them if you'd like that. It would also be pretty nice to have a script that tells us whether the system is coalescing packets, but I think a checker script that analyzes the number of responses to a malformed+proper packet duo would also work in that case, as long as we know the system is vulnerable.