This month’s Windows and Office security patches: Bugs and solutions


What happens when Microsoft releases eight – count ‘em, eight – concurrent beta test versions of Win10 version 1909 without fixing bugs introduced into 1903 on Patch Tuesday?

Pan. De. Moaaan. Ium.

The VB/VBA/VBScript debacle

No doubt, you recall the first wave of pain inflicted by the August 2019 patching regimen. Microsoft somehow managed to mess up Visual Basic (an old custom programming language), Visual Basic for Applications (for Office macros) and VBScript (a largely forgotten language primarily used inside Internet Explorer). Folks running applications in any of those languages would, on occasion, receive “invalid procedure call error” messages when using apps that had been working for decades.

Some companies’ commercial applications stopped working intermittently. More importantly, many large corporations’ internal custom programs turned belly-up.

The bug affects every single version of Windows – all the way from Win7 to Win10 version 1903. I think of it as Patching as a Keystone Kops Service.

If you’ve been following the details, you know that on Aug. 16, three days after Patch Tuesday, Microsoft released fixes for the bug in:

  • Win10 version 1709
  • Win7
  • 1
  • Server 2008
  • Server 2008 R2
  • Server 2012
  • Server 2012 R2

Then on Saturday (!), Aug. 17, we got fixes for:

  • Win10 1809
  • Win10 1703
  • Win10 1607
  • Win10 1507
  • Server 2016
  • Server 2019

And on Monday, Aug. 19, Microsoft released a fix for:

As of today, Aug. 30, we still don’t have a fix for Win10 1903, the latest version of the last version of Windows. It’s not clear why, but I have a guess that Microsoft’s so wrapped up in beta testing Win10 1903 that it somehow fell through the cracks. We still don’t have the second August cumulative update for Win10 1903 – the one that’s common called “optional non-security,” with varying degrees of accuracy. And therein lies a tale.

The unholy mess that is Win10 1909 beta testing

Normally, beta testing doesn’t have much of an influence over month-to-month patching. But this month it looks like we had a significant divergence of direction.

READ ALSO  Glitching LED Display Proves Crowd Favorite

For the past year, Microsoft has been testing its Win10 1903 patches thoroughly, using the Windows Insider Release Preview ring. That’s great – it’s what the Release Preview ring was made for.

During the month of August, though, the Microsoft beta people took over a corner of the Release Preview ring and pushed the beta version of 1909 onto (supposedly) 10% of the 1903 testers. The official announcement came on Aug. 26:

For a small subset of Insiders (around 10%) in the Release Preview ring, we have enabled the “seeker” experience for version 1909 [Editor’s note: MS calls it 19H2, just to confuse you]. For these Insiders, if they go to Settings > Update & Security > Windows Update, they will see that there is a Windows 10, version 1909 update available. They will be able to choose to download and install this update on their PC. After the update finishes, they will be on version 1909 [Editor’s note: I changed it again] Build 18363.327.

That seems complicated, but reasonable enough – until you realize that the Win10 1909 beta currently has eight different versions. Some of those versions are being distributed to people who are in the Release Preview ring. In particular, the 18362.327 preview of the Win10 1903 patch went out at the same time “the 10%” got a Win10 1909 patch called 18363.327 (see how 18362 changes to 18363?)

Apparently that build wasn’t good enough, so on Aug. 29 we got the latest bifurcated patch 18362.329 (for the 90%) and 18363.329 (for the 10%). It looks like we’re waiting until Microsoft gets the bifurcated patch to work on both Win10 version 1903 and on the beta of version 1909.

Regardless of the genesis, those of you waiting to get a fix for the VB/VBA/VBScript problem in Win10 version 1903 will have to wait a little longer.

READ ALSO  Google has achieved quantum supremacy. Here's why it matters

While DejaBlue simmers

All of this would be frustratingly academic, if it weren’t for the fact that DejaBlue – a new set of “wormable” security holes in Windows itself – made its debut this month. While I’ve read lots of Chicken Little reports that DejaBlue has been exploited, none of those warnings has come true. As of this moment, there are no publicly available DejaBlue exploits.

Of course, plenty of people are trying to build them.

Until Microsoft releases a fix for the VB/VBA/VBScript problem in Win10 1903, you have two choices – either patch, protect yourself from DejaBlue, but break VB. Or you can hold back on patching, keep VB working, but leave your system open to a DejaBlue infection.

Nice choice, eh?

From the oldies but goodies file

We’ve had loads of additional fun ‘n games this month:

  • Microsoft was blocking August Win7 patches on systems running Symantec/Norton antivirus, apparently because of the shift to SHA-2 encryption, which has been widely anticipated for six months. The block was lifted – but apparently nothing was changed. We still don’t know why.
  • There have been many reported problems with this month’s .NET updates.
  • We found out that the August Security-only Win7 patch does NOT contain the telemetry subsystem so evident in the July Security-only patch.
  • There’s a hue and cry about a 20-year-old security hole in MSCTF.DLL, which is apparently fixed in this month’s patches. I haven’t heard of any exploits in the wild.
  • Several folks have reported that the Win7 boot error 0xc0000225 happens if you haven’t properly installed the SHA-2 patch. Don’t worry about the alphabet soup, just install the BitLocker patch KB 3133977.

Have a patching problem? Don’t we all. Join us on AskWoody.com.



Source link

?
WP Twitter Auto Publish Powered By : XYZScripts.com