Skip to content
Naked Security Naked Security

Windows “Ping of Death” bug revealed – patch now!

No one has figured out how to run code with this bug yet - but if they do, you can bet that someone will turn it into a computer worm.

Every time that critical patches come out for any operating system, device or app that we think you might be using, you can predict in advance what we’re going to say.
Patch early, patch often.
After all, why risk letting the crooks sneak in front of you when you could take a resolute stride ahead of them?
Well, this month, the Offensive Security team at SophosLabs (that’s offensive as in the opposite of defensive, by the way, not as in the opposite of polite; and it’s the security that’s offensive anyway, not the team) has come up with some even more compelling “patch now” advice.
It’s in the form of a short video, and it shows an unpatched Windows 10 computer being crashed at will across the network by a simple bug-tripping Python script:

If the person running the script can aim a specially crafted IPv6 network packet at your computer – specifically, a booby-trapped ICMP packet – then they can bring you down without warning.
You see a Blue Screen of Death (BSoD), and any work you hadn’t saved is lost, probably forever.

ICMP is short for Internet Control Message Protocol, and it’s a low-level type of network packet that’s much simpler than setting up a regular TCP connection, and even simpler than UDP. The best known sort of ICMP message is probably a ping packet, generated by the ping utility that exists on almost every operating system. You ping a computer by its IP address and if it gets the packet, it sends a reply – a pong packet, if you like. Pinging checks whether you can communicate with another device at all, as a basic but useful starting point for network diagnostics. Loosely speaking, if someone can ping your unpatched Windows 10 or Windows Server 2019 computer from theirs, they can probably crash you with this bug.
We’re not going to go into any detail here – and even in the SophosLabs report our experts have avoided giving away enough for you start exploiting this vulnerability at will – but what you need to know is that this bug is denoted CVE-2020-16898.
The bug was discovered in a Windows component called TCPIP.SYS, and as the filename suggests, this isn’t just any old program.
TCPIP.SYS is a kernel driver, meaning that if you trigger this bug, you are exploiting a vulnerability inside the kernel itself, which is the very core of any running Windows system.
That’s why the system crashes with a BSoD rather than just shutting down one application with an error while leaving everything else running.
After all, shutting down the kernel means that there is no “anything else” to keep running, given that it’s the kernel that controls everything else.
So, a kernel crash, also known as a panic in Unix jargon, forces a total shutdown, typically followed by an automatic reboot.


Interestingly, the bug you see triggering in the video above that provokes the BSoD is caused by a buffer overflow.
TCPIP.SYS doesn’t correctly check the size of one of the data fields that can optionally appear in IPv6 ICMP packets, so you can shove too much data at it and corrupt the system stack.
Bang! Down it goes.
Two decades ago, almost any stack-based buffer overflow on Windows could be used not only to crash a system, but also, with a bit of care and planning, to take over the processor’s flow of execution and divert it into a program fragment – known as shellcode – of your own choosing.
In other words, Windows stack overflows in networking software almost always used to lead to so-called remote code execution exploits, where attackers could trigger the bug from afar with specially crafted network traffic, run code of their own choosing, and thereby inject malware without you even being aware.
But numerous security improvements in Windows, from Windows XP SP3 onwards, have made stack overflows harder and harder to exploit, and these days they can often only be used to force crashes, not to take over completely.
Nevertheless, a malcontent on your network who could crash any computers at will, servers and laptops alike, could cause plenty of harm just through what’s known as a denial of service attack, especially because recovering from each crash requires a complete reboot.
In theory, of course, a determined crook might be able to figure out how to exploit CVE-2020-16898 to take over a remote computer, not merely to crash it, so that Microsoft has classified this bug as critical, given it a severity rating of 9.8 (out of 10), and flagged it with an exploitability assessment of 1, short for “exploitation more likely”.

Slightly annoyingly, severity ratings get worse on a scale of 0 up to 10, while exploitability assessments get worse on a scale of 3 down to zero. 0 means “is already being exploited, so you are already in direct danger” and 3 means “this bug will probably amount to very little”. A value of 1 means that even if the bug turns out to be very hard to exploit, you can expect attackers to try really hard at it, because previous bugs of this sort have been exploited successfully.
In other words, even though CVE-2020-16898 hasn’t been turned into a working attack yet, you should patch right now, because you can bet your boots that cybercriminals are working on it.
In the vaguely militaristic jargon of cybersecurity research, this means that someone, somewhere, is trying to weaponise this bug right now.
For an explanation of why modern versions of Windows aren’t easy to exploit using this flaw, and for a justification of why our own Offensive Security Team thinks it’s unlikely – but not impossible! – that anyone will succeeed, please read the SophosLabs report.

What to do?

As we’ve said, you need to patch.
Although an exploit may never be found, it’s a fair bet that any working exploit that does turn up will be what’s called wormable, meaning that it could be used not only to break into your computer from someone else’s, but then also to break in to a third person’s computer automatically from yours.
That would allow the bug to be used to create a self-contained, self-replicating computer virus, or worm, that could spread both far and fast, entirely without human intervention.
If you genuinely can’t patch yet, there are two workarounds:

  • Turn off IPv6 in Windows. This is only an option if you have a pure IPv4 network.
  • Turn off the buggy ICMP feature in Windows, known as IPv6 ICMP RDNSS (short for Recursive DNS Server).

Instructions for turning ICMP RDNSS off (and back on after you have patched) can be found on Microsoft’s CVE-2020-16898 advisory page.


24 Comments

Since some time most of your RSS feed entries start showing up in duplicates: first one instance, then (the next day?) another one.
Feed URL: http://feeds.feedburner.com/nakedsecurity?format=xml
Reader: QuiteRSS 0.19.4
Example image: https://imgur.com/tbIC7cs
Bye
Jan

I have started putting popular articles for day (X-1) into the feed for day (X), now we’re doing fewer articles, so they appear a second time in the newsletter…
…but each article only ever appears once in the RSS feed (check the raw XML at https://nakedsecurity.sophos.com/feed).
When I view the feed in my browser it comes out fine – no duplicates. All I can think of is that your RSS reader sees the second appearance of the same URL and adds it to its own local cache of the feed as a duplicate. (To make the article re-appear in the newsletter, I usually move its timestamp from “just before 6pm UK time”, when the newsletter snaphot is taken, to “just after 6pm UK time”, which rolls it into next day’s 24-hour window. So the <pubDate> tag in the RSS feed would change for that article… but the <link> and the <guid> tags do not.)
Is there a way you can tell your RSS reader to recognise new articles by their <link> or their <guid> tags only, which won’t change if the article timestamp is adjusted? Or tell it to replace its own copy of the feed instead of updating or merging the new entries with its local copy?

Actually, I don’t dare patch any Windows machine before a week or so after patch Tuesday, due to the problematic Windows updates. By then I’ll know of any serious bugs. The bug described here can only be activated by software running locally. The workarounds don’t require rebooting at least.

The bug doesn’t _require_ local access, or even LAN access. If someone can send you a booby-trapped ICMP packet – which is true of many servers that respond to pings from the internet – you are at risk.

Not a ping packet. RDNSS service.

Router Advertisement packets, in fact. The RDNSS data is an optional part of ICMP packets of that sort that has a variable use, and handling the RDNSS part is where the bug is.
The idea of using the word “Ping” is that it’s the most likely sort of ICMP packet that people have heard of (even if they don’t know that ping echoes and replies are ICMP packet types).
Loosely speaking, if I can ping you I can get ICMP packets to your devices and therefore I can probably CVE-2020-16898 you instead.

Does this attack Window 8.1?
I didn’t see it in the patches done today.

I don’t think so. At least, the CVE-2020-16898 page doesn’t seem to mention it, just Windows 10 and Server 2019.
(Is anyone still using Windows 8, given that you could upgrade for free to Windows 10?)

Some companies will still be using 8.1 because migrating and checking all of their applications on a new OS is a big project. We have a couple of critical applications which have problems on Win 10. Fixing these takes time and we have to provide uninterrupted service throughout.
Home users should have already upgraded, sure, but not necessarily corporations.

I must say I am shocked to hear of any companies running Windows 8/8.1. From my experience it was a disaster and not really workable in an enterprise. I’d prefer to run Win7 and pay for support than deal with the train wreck called Windows 8.

Wow, just wow! Back in 2008 when I was a developer on the Windows Server team I was assigned the task to update all buffer manipulation code in the admin apps to be “safe.” This makes me wonder if the MS leadership did not apply this same rigor to the kernel drivers or if this is a regression introduced recently. Either way, it’s rather concerning that such a bug exists in kernel code!

Would this impact if your network is built for IPv4 with IPv6 not being in use?

If your computer has an IPv6 network address and is therefore listening out for IPv6 traffic (and it probably is if you haven’t expressly told it not to) then I would say that you are definitely at risk, even if no legitimate users on on your network are knowingly making IPv6 connections. Anyone on your LAN who can generate raw network packets and find out your IPv6 address could produce a booby-trapped packet and fling it at your network card – it’s you receiving it in the first place that pokes the bug.

I’d say there is something more in the mechanics of the exploit that is required to trigger the BsoD .
I did a little python that constructs ICMPv6 Router advertisement package with Recursive DNS type (Type 25) and the Length field which is even number > 3 . And it does not crash Windows 2019, so I believe there is something else in terms of conditions to trigger the crash. Wireshark indicated malformed packet when LEngth was even (and processed all ok when it was odd).

We deliberately didn’t publish our own Python code because it would be so easy to abuse, but as the video shows, it can be done. When I said “you can send a bloated packet and crash the kernel” I was being truthful… but purposefully incomplete :-)
FWIW, any RDNSS option field that is an odd number of bytes long is, of necessity, invalid. In fact, you can be stricter than that. By definition (see RFC 8106), the RDNSS field _must_ be 1 + 1 + 2 + 4 + (16N) bytes long, where N is a positive integer (1, 2, 3 etc.) That comes out at 8 + 16N, which also comes out as 8 x (1+2N). So any valid RDNSS field is always a multiple of 8 bytes long (and any multiple of 8 is even, and any number that is even cannot be odd).

In the old IPv4 version of this, you had to send a packet of data that was over the normal packet size, which you could do, because it is a ping. I don’t know about this one.
I have had IPv6 disabled on my windows computers ever since they started including it.

Deja vu all over again, I remember “ping of death” back on Windows 95 and NT, plus the more on topic 2013 CVE-2013-3183 for ICMPv6 on Windows Vista, 7 XP etc.

I can remember dealing with “pings of death” in the early 1990s, before there was linux, before the unix wars had been settled, and just as Windows for Workgroups was becoming a thing. You’d generate an ICMP packet with a broadcast IP address and a broadcast IP address. 1 packet. Every computer within listening range would respond with an ICMP packet with a broadcast destination packet and its own address as the source. My company built a “flat” network that was about 100 miles long and you could see broadcast packets start at one end, propagate to the other end, and travel back down to the original end.
You can’t really blame Windows for that one. I think in the 1980s, it never occurred to anybody that somebody would ping a broadcast address.

Is there any good reason for the average company to run IPv6 internally? To me it’s basically just a second network that no one is monitoring (or really even understands), can be leveraged by attackers, and should generally be blocked at the firewall. Am I missing anything?

Comments are closed.

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?