It's Bugtober, with Adobe Flash crashes, numerous CVE vulnerability patches for Wi-Fi and routers, and an Intel SPI vulnerability patch for most Xeon D Supermicro SuperServers
Sometimes a home lab can be kept operational for months with minimal maintenance. This month, many things happened that required more immediate attention. Maybe this month should have been called Bugtober instead of Blogtober, and it ain't even over yet! None of these took terribly long to fix, but all are good to know about.
In order of first discovery, here's a summary of what I had to do, and what I will be doing soon. If you have some/all of the same gear, perhaps you should too! Back up your stuff first, of course.
Oct 06 2017 - Intel SPI vulnerability CVE-2017-05701
Only a concern for internal attacks, so please don't make too much of this, and it's not likely an issue at all for typical home labs, see securityfocus.com/bid/101257. On October 23rd, I received confirmation from Supermicro that this SPI vulnerability also affected Xeon D, not just the Intel NUC, which were patched with new BIOS releases back on Oct 6. Not a problem for Bundle 1/2/3 owners and most Xeon D SuperServer owners, with BIOS 1.2c already fixing this vulnerability, see also the release notes that are dated 09/19/2017, but the download spotted on Oct 19.
Note, there is one Supermicro SuperServer Xeon D system that hasn't been patched, the SYS-E300-8D with the X10SDV-TP8F Flex ATX motherboard and the SFP+ version of the Intel X552/X557 10GbE. Unfortunately, the last BIOS update for that system was released way back in August of 2016. In hindsight, I'm thankful that I choose not to help create a bundle of that model.
Details on the BIOS upgrade procedures just published:
Oct 09 2017 - Monitor for rare PSODs for upgraded 10GbE servers
I've not received any reports of PSODs from Xeon D owners at all, and quite possible that this issue doesn't apply to the now very common Intel X552/x557 10GbE that's baked right into the Xeon D. The rare Xeon D and Xeon E PSOD explained in KB 2146388 that some NSX users encountered about a year ago quickly surfaced via comments right on my site, and was fixed with a BIOS update. With 6.5U1 out since July and no PSODs reported to date, I'm fairly confident this isn't a priority for me to worry about, but I'll keep an eye out anyway.
Oct 02 2017 - Several critical CVEs discovered
Ubiquiti has moved to a much faster release cycle with their firmware updates this year, largely decoupling major feature releases from more frequent security-update-only releases. This is good. I'm that much more relieved that I've left consumer routers behind at this point, annoyed by their planned obsolescence through inevitable firmware neglect.
Here's the fix that took Ubiquiti only 9 days to create, and only about 10 minutes to apply to my ERLite-3.
- Direct Download
Upgrade dnsmasq to 2.78 to fix multiple security vulnerabilities (CVE-2017-14491, CVE-2017-14492, CVE-2017-14493, CVE-2017-14494, CVE-2017-14495, CVE-2017-14496, CVE-2017-13704).
My upgrade of my ERLite-3 on Oct 24 was uneventful, using the same procedure demonstrated on video here. This update requires a router reboot, which interrupted internet access for my entire home's network for less than 5 minutes.
FYI, pfSense got their KRACK-patching 2.4.1 Release out on October 24th.
Oct 14 2017 - Adobe Flash Crashes discovered
After our Twitter conversation, William got this one documented very quickly:
- “Shockwave Flash has crashed” workaround for vSphere Web (Flash) Client
Oct 15 2017 by William Lam at virtuallyGhetto
As for me, I'm not comfortable with back-leveling to vulnerable Flash versions, so I went ahead and fired up a fresh Windows 10 Version 1709 VM from my home lab's ready-to-roll template. I then installed 64 bit Chrome, then the beta Flash from here. This got me going again, and will help me get by until a proper Adobe Flash gets auto updated right in my Chrome, at which point all my handy "appified" Chrome vSphere shortcuts will simply resume working, with no more futzing around required. That's my hope anyway.
Oct 25 2017 Update - Fixed! Details below.
Oct 16 2017 - Wi-Fi WPA2 vulnerability disclosed
The fixes were uneventful and pretty fast. Microsoft fixed all modern Windows versions a week before we even knew about KRACK. The "client" OS is where this Wi-Fi vulnerability is biggest. The fix came down via the usual automatic Windows Updates mechanism.
Some details in this Apple forum thread.
Next up Fixed on my home's eero Wi-Fi very easily, with a beta immediately made available, and the GA level code available to manually pull arriving within a couple of days. Easy.
Fixes in iOS 11.1 are available now in beta, and in GA form later this week.
Google has promised to deploy an Android patch in the coming weeks, but it may be some time before that patch will reach non-Pixel devices. Even if your router isn’t patched, patching the device should be enough to stop an attacker from getting in the middle.
Today, Chrome automatically updated to Flash update 22.214.171.124, which seemed to resolve this issue documented in VMware KB 2151945:
where a system wide standalone Flash install of 126.96.36.199 or later is recommended. But what if you only use Chrome for vSphere sysadmin, don't care to enable Flash in other browsers, and don't wish to clutter Windows up with yet another auto-updater in Task Scheduler?
For most of my Windows 10 systems, no further action was required. The VMware vSphere Web Client suddenly just worked again, since the automatic Chrome updates had taken care of this Flash update to .183 too. But there was one system where I had to manually give its Chrome a gentle kick to do its component updating.
What about those auto-updaters in Task Scheduler? That won't work, since that's NPAPI, but it's your PPAPI that needs updating. Don't worry, updating your PPAPI is easy and doesn't hurt. This simple fix isn't a hack that could adversely affect other apps or system, it just updates Chrome's Flash. Here's the exact steps I followed:
Fix for vSphere Web Client
- Open a new Chrome tab.
- Copy-and-paste this special URL into the new Chrome tab:
- Look for
Adobe Flash Player - Version 188.8.131.52
and click on the button labeled
Check for update
- A few seconds later, it should say
Version 184.108.40.206(or later), and
- On your crashed vSphere Web Client window (sample screenshot above), click on
Reloadand tada, it works like it should (sample screenshot below), no Chrome restart required. Nice!
Sources - How to force Flash updates in Chrome by Martin Brinkmann at ghacks.net and “Shockwave Flash has crashed” workaround for vSphere Web (Flash) Client by William Lam at virtuallyGhetto.
Don't forget, this fragile reliance on Flash is going away, see:
- Goodbye, vSphere Web Client!
Aug 25 2017 by Martin Yip at VMware vSphere Blog
Customers should start transitioning over to the vSphere Client if they have not already done so as the vSphere Web Client will no longer be available after the next vSphere release.
Seeing eero's quick reaction to KRACK has been very reassuring. I can recall originally being somewhat skeptical about cloud management of my Wi-Fi’s firmware version. Over time, it's become apparent that eero’s management of firmware has some big advantages over relying on owners to have to do something, especially when they are critical, like the patch for KRACK.
Here's a bit of the behind-the-scenes by eero:
- Move fast, break nothing
POSTED ON OCTOBER 25, 2017
How we protected 100% of our customers in less than a week
Oct 25 2017
On October 16th, cyber security researchers publicly disclosed a vulnerability named KRACK in the WPA2 security protocol, which encrypts all traffic between modern WiFi access points and client devices. That same day, eero’s internal security and engineering teams rolled a fix out to our beta customers. A day later, we began rolling out the security patch to all customers. As of October 22nd, less than a week after the KRACK disclosure, 100% of eeros had been updated to protect against the security vulnerability. That’s faster than most companies even released a patch, let alone actually updated their products. In fact, all eero networks were updated before some companies even acknowledged the vulnerability at all.
October wasn't done yet! Reaper: IoT botnet 'worse than Mirai' infects one million organisations worldwide was the gist of many headlines, but maybe you didn't see these two additional articles:
- A New IoT Botnet Storm is Coming
Oct 19 2017 at Check Point Research
- A massive Botnet is forming to create a cyber-storm that could take down the internet.
- An estimated million organizations have already been scanned with an unknown amount actually infected.
- The Botnet is recruiting IoT devices such as IP Wireless Cameras to carry out the attack.
New cyber-storm clouds are gathering. Check Point Researchers have discovered a brand new Botnet, dubbed ‘IoTroop’, evolving and recruiting IoT devices at a far greater pace and with more potential damage than the Mirai botnet of 2016.
- IoTroop Botnet: The Full Investigation
Oct 29 2017 by Check Point Research
Last week, thanks to the Check Point web sensor network, our researchers discovered a new and massive IoT Botnet, ‘IoTroop’. Due to the urgency of this discovery, we quickly published our initial findings in order to alert the cyber security community. Since then, we have had time to digest and dissect the propagating malware and share our findings with you.
Patrick Norton discusses Reaper IoT botnet at this spot in this recent podcast episode, as well as the first Check Point Research article above:
This Week in Computer Hardware (MP3): 438: AMD Ryzen Laptops and the 1070 Ti
Remember above, where I wondered aloud if the Xeon D's embedded Intel X552/X557 10GbE might be affected by the PSOD warnings in kb.vmware.com/kb/2151749, optimistically hoping lack of any reports meant we might not need to worry? Well, that question got answered for me last night, as I kicked off a Windows Update on a Windows 10 1709 VM on my Intel Optane 900P's VMFS file system, and headed to bed, noticing it seemed a little slow. In the morning, noticed the ESXi server itself didn't respond to ping, so it was time to fire up Supermicro's embedded iKVM functionality to have a look see at the local console.
Well, wonder no more, my little Xeon D-1541 was clearly telling me that yes, the Intel X552/X557 10GbE user can be affected by this PSOD, even if you're not heavily hitting the network! This is both annoying and even a bit embarrassing. I work at VMware as a customer facing vSAN System Engineer, not a part of the group that works on ESXi itself. But I've reported this incident internally, and hope a proper ESXi fix in the form of a patch arrives soon.
Meanwhile, the KB article does have a workaround, which I will be using myself for now. This does put a wrinkle in my plans to test from my Optane 900P to a loaner Optane 900P that just arrived, using 10GbE between them.
- Ubiquiti EdgeRouter Lite (UBNT ERLite-3) Update - still works great for my family, and for my VMware vSphere, Windows, and Linux home lab
Jul 11 2017
- How to import your VCSA certificate so ALL VMware vSphere browser security warnings go away in Windows 10
Apr 26 2017
- VMware vSphere Taskbar Shortcuts Unleashed - profile switcher isolated and uncluttered Chrome Browser UIs act like native Windows apps!
Mar 27 2017
- Replaced my Linksys router with an eero 3 pack after also testing Luma mesh surround Wi-Fi, faster wireless in every room has arrived!
Aug 21 2016
- CVE-2017-13080 | Windows Wireless WPA Group Key Reinstallation Vulnerability
Oct 16 2017 by Microsoft
A spoofing vulnerability exists in the Windows implementation of wireless networking. An attacker who successfully exploited this vulnerability could potentially replay broadcast and/or multicast traffic to hosts on a WPA or WPA 2-protected wireless network.
Multiple conditions would need to be met in order for an attacker to exploit the vulnerability – the attacker would need to be within the physical proximity of the targeted user, and the user's computer would need to have wireless networking enabled. The attacker would then need to execute a man-in-the-middle (MitM) attack to intercept traffic between the target computer and wireless access point.
The security update addresses the vulnerability by changing how Windows verifies wireless group key handshakes.