Credit to Author: Woody Leonhard| Date: Mon, 01 Jul 2019 04:36:00 -0700
How many bugs could a WinPatcher patch, if a WinPatcher could patch bugs?
Ends up that June’s one of the buggiest patching months in recent memory – lots of pesky little critters, and the ones acknowledged by Microsoft led to even more patches later in the month.
In June, we saw eight single-purpose Windows patches whose sole mission is to fix bugs introduced in earlier Windows patches. I call them silver bullets – all they do is fix earlier screw-ups. If you install security patches only, these eight have to be installed manually to fix the bugs introduced earlier. It’s a congenital defect in the patching regimen – bugs introduced by security patches get fixed by non-security “optional” patches, while waiting for the next month’s cumulative updates to roll around.
Every modern version of Win10 except 1903 – which is to say, versions 1607, 1703, 1709, 1803, 1809, Server 2016 and Server 2019 – all got three cumulative updates this month. The third cumulative update for June resolves this one issue:
Devices may have issues connecting to some Storage Area Network (SAN) devices using Internet Small Computer System Interface (iSCSI) after installing KB4497934. You may also receive an error in the System log section of Event Viewer with Event ID 43 from iScsiPrt and a description of “Target failed to respond in time for a login request.”
In other words, it’s a silver bullet – an optional patch that fixes a bug introduced in an earlier patch that you’ll only get if you download and install it manually, or if you click on “Check for updates.”
What’s strange about this bevvy of patches is the timing. Apparently, the bug arrived with the third May cumulative updates on May 21. I first saw mention of it on a Dell support forum, on June 11 and posted about it on June 19. Microsoft hadn’t acknowledged the bug at the time. (The first official announcement I saw was on June 26, the date all four silver bullets appeared.)
That’s more than a little disconcerting because Microsoft should be warning us about these problems quickly on the Release Information Status page.
On June 20, Microsoft released silver bullet patches for Win7, 8.1, Server 2008 R2 SP1, 2012, 2012 R2, and Internet Explorer 11 to fix bugs introduced in the June 11 Monthly Rollups and Security-only patches.
“Addresses an issue that may display the error, ‘MMC has detected an error in a snap-in and will unload it.’ when you try to expand, view, or create Custom Views in Event Viewer. Additionally, the application may stop responding or close. You may also receive the same error when using Filter Current Log in the Action menu with built-in views or logs.”
Cumulative Update for Internet Explorer 11 KB 4508646
“Addresses an issue that causes Internet Explorer 11 to stop working when it opens or interacts with Scalable Vector Graphics (SVG) markers, including Power BI line charts with markers.”
The bug fixes are not included in the June Monthly Rollups or Security-only patches (June 11, 2019), but are included in the Preview Monthly Rollups released on June 20.
Once again, bugs introduced by security patches are getting the latest fixes in non-security patches.
The second monthly cumulative update for Win10 1903 appeared late, as usual, on June 27. KB 4501375 includes fixes for several acknowledged bugs, including the MMC error with Custom Views described in the preceding section.
Based on my tests… KB4501375 (18362.207) behaves exactly the same way that Feature Updates behave on 1809 and 1803 – the “download and install now” behavior. In other words, KC 4501375 will be bundled and offered as [a] secondary update with any available update even if you don’t “Check for updates.” It’s possible that the latest .NET cumulative update will trigger this behavior.
That said, deferring Feature Updates (version updates) for just 1 day makes KB4501375 go away.
We’re still in a quandary about the behavior of Win10 1903’s update deferrals.
In Win10 1903 Pro, if you go into Windows Update, advanced options, you get a pane that looks like this.
Windows 10 1903 Pro update advanced settings.
Several of you have noted that if you specify deferral options as I have here (non-zero numbers in either of the two bottom boxes), the entire “Choose when updates are installed” part of the advanced options dialog disappears.
@abbodi86 has undertaken some experiments with the settings. Here’s what he has concluded:
Yep, the Feature Update deferral box disappears once i change the entries to non-zero. Maybe it’s an intentional move so the user cannot change the period frequently? 🙂
Anyway, the Feature Update deferral period can be still controlled with registry setting
Group policy can be used to show you the feature update deferral period. The box will show up greyed, but at least you can know the period
@abbodi goes on to say that he tested changing the Quality Update deferral period the same way, with the same result — if you set it to anything other than zero, the whole section disappears. It may be related to an internal conflict with the way Semi-Annual Channel (Targeted) was removed.
Maybe, just maybe, this is the way it’s supposed to work. If so, I’d like to nominate this particular behavior for the “Harebrained Design” hall of fame. Giving a user an option, any option, then forcing them to dig into Group Policy to modify it, stinks.
If you’ve been struggling with the “Intel” microcode updates for Meltdown/Spectre and other “Side Channel vulnerabilities,” you aren’t alone. The latest twist appears with Karl-WE’s enormous leg work, posted on GitHub, that brings some sense to the ongoing litany of patches.
In particular, Karl notes – and MS Security Response Center guru Jorge Lopez confirms – that the phrase in KB 4346085 that says:
Important Install this update for the listed processors only.
is, quite simply, wrong. Some of the updates apply to processors that are not listed. You’re better off trusting Windows Update to pick the ones that are right for your machine. Says Lopez:
“The team didn’t want to mislead anyone reading this KB in isolation to think that installing this KB/deploying across a fleet would mean they have met the requirement for microcode for these side-channel issues – that is only true for the processors listed on the KB. We will update the line, that’s not the right way to provide that warning. So yes, you don’t have to go through some complicated deployment matrix on this KB, but you still have to do so to determine what is protected or not (vuln scanning tools should help). The logic to apply or not a microcode update is part of the boot sequence in the OS – if the processor has a microcode revision that is older than what the OS has, the OS will update the CPU microcode as part of the boot sequence.
Expect to see a correction to the KB article shortly.
To end on a positive note… remember the BlueKeep vulnerability? The one that had me crying that the sky is falling and you needed to install the May patches, like, right away? Kevin Beaumont (Twitter’s @GossiTheDog) has good news:
If anybody is pondering why there’s no public BlueKeep Remote Code Execution exploit, it’s a mix of difficulty [There’s a high bar for exploitation – in theory it is ‘just’ a use after free bug, but to be able to kernel spray you have to reverse engineer the RDP driver. There’s no documentation on how to do it for this.] and a handful of people in the InfoSec world being very responsible.
Yes, you still need to make sure you have the fix installed. You should’ve done it in May. When the exploit hits it’ll be painful. But at least we’ve been spared a bloodbath of unprecedented proportions.
Join us for more thrilling Tales from the Crypt on the AskWoody Lounge.