It's 2020 and a rogue ICMPv6 network packet can pwn your Microsoft Windows machine Microsoft's Update Tuesday patch dump for October 2020 has delivered security patches that attempt to address 87 CVEs for a dozen Redmond products. Nadella's security crew has identified 22 remote code execution (RCE) CVEs though the most worrisome looks like CVE-2020-16898, Windows TCP/IP RCE, which is rated 9.8 out 10 in …
It's over fifteen years since I did things with Windows. However, what I hear from people who currently administer Windows networks is that, whenever you call on Microsoft Support to help troubleshoot an issue and they discover that you've switched off IPv6, they won't be able to help you until you switch IPv6 back on. Everything is designed with a functioning IPv6 in mind and switching it off could cause weird issues. Perhaps because it's used for local discovery or localhost (:1) loop back etc.
I can't quickly find the MS guidance, but in essence what I've read is that Microsoft does not regression-test anything with IPv6 disabled. (Seems like they don't do any regression testing these days...)
I don't explicitly run public IPv6 on any enterprise networks at this time. The only thing that I do is make sure that on my domain controllers, I remove the ::1 entry for the primary IPv6 DNS entry after promotion.
This seems to prevent unexpected DNS results... the primary issue I see is occasionally getting only quad-A responses out of DNS instead of A and AAAA responses when ::1 is listed as a DNS server.
the primary issue I see is occasionally getting only quad-A responses out of DNS instead of A and AAAA responses when ::1 is listed as a DNS server.
just did a test on a windows 7 box - with FBSD running bind (as 'named') and serving up requests for IPv4 and IPv6, using 'ping' got me the IPv6 address, and nslookup showed both IPv6 and IPv4, with IPv6 listed first.
when I told nslookup to look specifically at the name server's ::1 address, the results were the same. But DHCP tells the windows 7 box that the DNS server has an IPv4 address on the LAN. So I'm not entirely sure how to reproduce that on my network... maybe manually set up the DNS with an IPv6 address? Or it just may be a matter of which one's specified first in the list o' DNS servers for DHCP/DHCPv6 or however it is that Windows 7 is grabbing its IPv6 info [I got DHCPv6 and 'auto address' and other support on the network, so Apple AND Android devices have no trouble with it]
Also, in my case, the ::1 DNS server returns the same A and AAAA records that the x.x.x.x one does. So maybe it's just a 'Micros~1 quirk' ? I'd be interested in what nslookup results look like for your domain controller, especially when you explicitly tell it which name server to use.
netsh interface ipv6 show prefixpolicies
netsh interface ipv6 set prefixpolicy
Let you select what type of address Windows uses first. The default is to use the IPv6 address.
You can also set some registry keys:
https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-ipv6-in-windows
The fact that a DNS server is IPv4, IPv6 or both is irrelevant, all of them can return both A and AAAA results.
I believe the different answers depend on the authoritative DNS server's behavior to AAAA queries coming from an IPv4 source. Or perhaps a behavior within the windows DNS resolver on a domain controller not asking for the A RR along with the AAAA RR, if the authorative doesn't automagically provide both an A and AAAA response to a query.
Never really dug into it that much, since I don't manage any production networks (my home doesn't count) with public IPv6.
Since IP6 came out for windows then mine was turned off on the PC and router, it all that time I have not had any problems, admittedly I also turn off server, print spooler, image acquisition and workstation amongst others since it is a gaming machine, hence no need for MS networking, printing, scanning or anything other than what I use it for.
You lot are bitching about MS networked machines you are paid to maintain, and yes, MS is of course going to want IP6 for tackling those hard to reach areas behind NAT.
What I found most entertaining was getting downvoted for expressing my personal opinion/preferance, based upon my own usage.
I mean seriously, who still trusts MS with any real/saleable data
This post has been deleted by its author
This post has been deleted by its author
Good luck with that. Win10 turns them back on by itself.
I have a VM which is used exclusively for CCTV monitoring. (The otherwise-venerable 'ISpy' software is, much to my disgust, written in .NET, which means it will never run in WINE, etc. so it has tro be a VM).
I have rigged a little Arduino-based relay board (KMP Electronics ProDino) to turn on a light in my garage when the camera starts recording.. If I ever walk into the garage and the light doesn't turn on, then I know there's something wrong with the CCTV. 90% of the time, it's Windows Update.
> .NET software can be ran on Mono.
This can't, because it relies heavily on WPF...
> but there is software written *for* linux that is written in .Net
Yes, and it's all shit.
Embrace, Extend, Extinguish... Doesn't matter if we can't sort out basic things like Network Security.. In fact, that's in many cases a bonus.
With .NET 6, you will find Mono is redundant and all older .NET architecture-independent code will indeed work on Linux, with a lot of native code working on Wine. With that said, .NET 5 will probably fix what you’re after. Try it, it’s at RC2 already. It should work inside and outside of Wine.
Even though Linux is very much viable and has been for a long time, I’m still not sure why folks expect not to be shafted by their constant, short-lived technology swap-outs in the Year of Our Linus 2020. For every bit of freedom gained by having source code access, freedom is lost when they break your stuff because they don’t feel like maintaining a given API. That’s ignoring constant ABI changes which break old binaries unnecessarily, as in breaking the code you actually run!
If you’re a non-gaming home user and you’re upset about Windows 10 as it’s normally shipped, you’re still better off pirating an LTSC release and a copy of Office 2016/2019. The customisations you make will work for a good 10 years and doing things this way means you can just get on with life.
it's a fair bet that Windows 7 is vulnerable, right??
Good thing I don't web surf (especially via IPv6) with it. In case anyone forgot, an IPv6 address is NEARLY ALWAYS routeable from 'teh intarwebs'.
I may have to adapt my (FreeBSD) firewall rules to block incoming ICMPv6 packets, just in case.
This IPv6/ICMPv6 vulnerability sounds as bad as 'WinNuke".
Yes, IPv6 is routeable. As is IPv4. That's why we have things called "firewalls" that we put between our privates and the untrusted network. They work just as well with IPv6 as they do with IPv4.
You didn't think that NAT offered any form of protection, did you??
...and the fundamental of firewalling form the basis of NAT.
FTFY, as they say.
And for the record, yes, I have seen Windows Server (2008R2) *fail* to block 192.168.x.y packets at its NAT and thereby screw up the network on the other side. Just because you aren't using routable addresses doesn't mean you are golden. The correct blocking of packets is the key step. Remapping addresses is just icing on the cake.
>That's why we have things called "firewalls"
Well until now I never really considered my ISP providing only IPv4 connectivity to the Internet to be their contribution to my firewall policy ie. default disable inbound/outbound IPv6 communications with WAN...
hmmm... double-checked my firewall config, looks like I'd already disabled incoming ICMPv6 for types 133 through 137, which includes all of the NDP protocol stuff, to the best of my recollection...
heh, dodged a bullet there. /me wipes sweat from brow
https://en.wikipedia.org/wiki/ICMPv6
Ping of Death was the best bug ever.
an accidental script ran in response to the firewall detecting certain kinds of intrusion activity... accidental. Allegedly. Heh.
Your post reminded me of Code Red. it opened up a port on the intruding/probing server that had direct access to a CMD shell. Sending commands via that port COULD cause IIS to shut down, thereby stopping the probing for vulnerabilities... and maybe (allegedly) put a file called "IDIOT.TXT" on the logged in desktop, and MAYBE pop up a dialog box that announces the machine is infected with a virus and then name the virus and tell them to patch their system or shut off IIS ... {allegedly)
I ran the ping-of-death page when it was all going on.
It was quite an easy one to patch I think, and the first patches started coming in within a day or so. But it was so far ranging, taking out network stacks on everything from printers to mainframe systems I'd never heard of, plus at leat a dozen UNIX variants (remember when there were a dozen UNIX variants?). I'm pretty sure there was one dedicated firewall on the list too. A noticeable exception was Windows, which could send the packet but wasn't vulnerable to it on receipt.
I had a guy in california kernel panic a machine in London with a single packet while testing. Simple bugs, good times.
It really be like that.
error[E0382]: borrow of moved value
"But," you say out loud after the 20th borrow checker error, "if you won't let me use that structure there, I have to refactor the whole thing. Can I move this to that line there?"
error[E0382]: borrow of moved value
"oh, ok, fine"
--------
It's basically all for your own good. The compiler often gives you the option of cloning/copying an object if you really want to use it in tricky situations but then... it's a copy of the data and that copying is also unnecessarily expensive.
Better just to write it properly the first time, as you should. Good Rust code should be known for its sharp edges -- no cut corners.
C.
XP didn't even exist then.
"24th August 2001, and broadly released for retail sale on 25th October 2001."
Few people had it before 2002. I held off till April 2002 and even then it was only workstations, because the SERVER version didn't come out till 2003. Generally people only connected secured servers to the Internet, and even then might have used a firewall with port forwarding.
Windows 2000? Clue in the name. Late 1990s was only NT3.51 and NT4.0
they note in their security bulletins and CVEs that not only have they patched their broken code, but that *also* they have diagnosed why their automated code scanners and fuzzers didn't catch that flaw previously, and have fixed those tools, and re-checked their entire code base. Y'kno, feedback that "here's a stupid code pattern!" to find the _other_ places that bit of stupidity lurks.
Haven't we been here before? I remember years ago we had something along the lines of "Ping of death" or something like that where you could pwn a machine with pings and such. I don't remember vary clearly. But it was a very large number of years ago now.
I thought that issue was fixed years ago too?
I read
"The specific flaw exists within the parsing of HTML content in an email," explained Childs. "The issue results from the lack of proper validation of the length of user-supplied data"
and thought
"It's 2020 and apparently MS are still producing code that doesn't validate user data correctly and produces what reads like a classic buffer overflow condition which we tried to stop doing last century".
Why was I even surprised?
They haven't coped well with security since Worries for Workgroups.
As a matter of fact, their inability almost seems suspiciously deliberate. Might explain why they were so keen to help establish the Cloud Act in the US.
God help the Americans with any voting systems running on Windows..
"The specific flaw exists within the parsing of HTML content in an email,"
Why would you even want to parse HTML in an email? I'm pretty sure HTML is not part of the email RFCs.
I use alpine for email -- I eschew WebMail because of all the inherent insecurities. However, at my Current Place of Employment, whenever I reply to an IT incident ticket it gets logged in the system as "No Comment" -- I have to remember to explicitly include the assigned responder in my CC: list or they don't see my reply. I can only assume that this is because they are trying to parse HTML tags...
IPv6 is a hideously complicated, over engineered, difficult to administer disaster of a protocol which is why 25 years after it was introduced company IT depts still have to be dragged kicking and screaming into (knowingly) using it on their internal networks.
I'm absolutely horrified that these simple buffer overflow bugs are still present in Windows networking code, or any code which could be exposed directly to the internet. These low-level stacks and protocols should've been devoid of these kinds or bugs decades ago!
I find this inexcusable and simple negligence on Microsoft's part.
You'll find that malware and ransomware makers will have a field day with this as most organizations will simply not have sufficient time to patch these bugs.
I happened to go into Windows Update yesterday, 3 mandatory ones and about 8 optional ones showed up.
Didn't exactly inspire confidence though, as 3 of the optional ones (all Intel drivers) were dated either sometime in 1968 or 1/1/1970.
Quite what's going on there I don't know, but suffice it to say those didn't get picked (indeed only one of the optional ones did - a bios firmware update) but it did kinda have me crossing my fingers that the system would survive the install and reboot...
That's actually deliberate, and quite clever.
The dates are used to figure out whether your current driver is better or worse.
Many manufacturers have stopped producing any drivers for their hardware at all, so Microsoft have taken over support. But they need to make sure their driver doesn't replace a good driver you got by other means...
I'm not sure I follow the logic here. Either the MS driver is better than the last one the vendor produced, in which case it should post-date it and supersede it, or it is not in which case MS should simply ship the last known good.
(Oh, and the OP said that these were Intel drivers, but that doesn't change my argument. Ship something better or don't ship. Pick one.)
I once ran a test team and took the stance that I was an end user not a clued in techie.
Hardly any of the products passed my tests so after a long "fight" and surprisingly at the urging of the development teams, the company totally changed the testing regime and programs started checking for invalid input which was dealt with before it crashed the systems.
This was the UK back in the 70s.
The other thing the company learnt was that by developing the code in a higher language, it did not preclude the necessity for the best programmers who knew what they were doing.
Along came the Charlie Chaplin advert and the IBM PC and MSDOS resultant world dominance by the U/S even though it was never the best PC and certainly not the best OS.
Here we nearly 40 (yes FORTY!) years later still at major risk from junior programmer level coding errors.
And they want to program driverless vehicles!
That's one of the two contributions that I made in all the betas I did over a few decades of testing. The other was using the manual exactly and feeding corrections to the documentation team.
Of course my own code assumed that anything went as far as what a user might do.
I mean IPv6 is not inherently more complex than IPv4, in fact it's much easier in many regards (like stateless auto configuration for networks without DHCP).
My guess is that it's because of the "hype" people which crammed more and more "experimental and optional" (read unused) features into it like "IP Mobility" or "NAT64" or "NAT46". However nobody really uses that. In reality IPv6 is not much different to IPv4. It's a separate network sharing some infrastructure, it codifies some nifty ideas you have in IPv4 in a cleaner way (e.g. your local nameserver should always listen to a fixed local anycast address so you don't need to configure it). Nobody uses those advanced features except for experiments.
Hackers do, but that's no reason for the rest of us to enable support for those experiments on our line of business systems. OTOH, the bug reported here was in router advertisement, which isn't one of those weird features.
Maybe the story here is that IPv6 isn't a can of mutant worms, but it is still vulnerable to poor code quality. A rubbish headline, but probably true.
"we would not tolerate this BS in the physical world!!"
Ummm, there's plenty of BS in the physical world. No matter what your beliefs (religious, political, social, etc.) actually are, you can find plenty of people who in your considered opinion are ten different kinds of BS all at once.
"87 CVEs is significantly less than the 129 Microsoft addressed in September" and signifcantly less than the 15 that SAP had in one applicaton compared to Microsoft's large software stack which seems to have escaped your wrath.
Temper your enthusiasm for MS baiting with some solid reporting rather than the easy "me too" MS bashing you seem to enjoy. All these other vendors have code stacks much less than a 10th the size and range (and age) of Microsoft but propotionally more patches and you just ignore them because 15 is such a small number it really can't be that bad.
Oh and have you ever tried patching a SAP server? Nightmare. Just patching the clusterd SQL back end makes it fall over and eat itself.
El Reg,
That sarcastic joke has served you well in the past. It's 2019 and - funny. It's 2018 and - funny. Et cetera. But it really is 2020. Effing 2020. It's not funny this year. Trump didn't shoot anyone on 5th avenue, but he has killed hundreds of thousands of Americans. Johnson's killed even more Britons per capita.
Mentioning 2020 at all in terms of an IT fiasco seems as tasteless as comparing it to a genocide. This is a 20/20 vision of damnation. Let's not mention that again until we can say, "It's 2022, we are still alive, and there are still stupid IT vulnerabilities."
[Hogmanay Edinburgh 2020: I have never played Grand Theft Auto, but I get the gist and do have access to a vehicle. Feel free to party on the streets.]
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
