Posts Tagged

Bugs

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

It’s been another strange patching month. The usual Patch Tuesday crop appeared. Two days later, we got a second cumulative update for Win10 1903 and 1909, KB 4551762, that’s had all sorts of documented problems. Two weeks later, on Monday, Microsoft posted a warning about (another) security hole related to jimmied Adobe fonts.

Predictably, much of the security press has gone P.T. Barnum.

The big, nasty, scary SMBv3 vulnerability

Patch Tuesday rolled out with a jump-the-gun-early warning from various antivirus manufacturers about a mysterious and initially undocumented security hole in the networking protocol SMBv3.

Later that day, Microsoft released a broad description of the SMBv3 security hole in Security Advisory ADV200005 – apparently trying to close the door after the cow escaped. And the crowd went wild. How could Microsoft tell these antivirus vendors about a forthcoming fix, then fail to deliver the fix – and not warn the AV folks in time to pull their press releases? Tales of impending doom ran rampant.

Then, on Thursday, we saw another cumulative update for Win10 versions 1903 and 1909. KB 4551762 patches the SMBv3 security hole and, being a cumulative update, includes all earlier patches. The rush was on to install the patch-of-a-patch, but we started seeing all sorts of problems: errors on installation; random reboots; performance hits; and the return of our old profile-zapping bug, which leaves folks with empty desktops and hidden files.

Here’s the punch line. (Tell me if you’ve heard this one before.) After all the sturm un drang, researchers (notably including Kevin Beaumont) discovered that they couldn’t effectively use the security hole to take over a system:

“Windows Defender, which is enabled by default, detects exploitation even if unpatched.”

As of this writing, I don’t know of any real-world attacks using the SMBv3 vulnerability. Certainly, one will appear sooner or later, but it isn’t a big deal right now.

The big, nasty, scary Adobe Type Manager font bugs

Yesterday, Microsoft released another Security Advisory. ADV200006  — Type 1 Font Parsing Remote Code Execution Vulnerability describes a security hole in the way Windows handles fonts. We’ve seen a lot of those in Windows over the years. This one came with the usual zero-day language, advising that Microsoft has seen “limited targeted attacks that could leverage un-patched vulnerabilities.” The advisory shows that every version of Windows – going back to Win7 – is vulnerable.

Once again, the blogosphere went nuts. Microsoft’s warning meeeeeeelions of Windows users that their systems are under attack!

Yeah. Sure.

When Microsoft says it’s seen “limited targeted attacks,” that means some well-heeled hacking group is using the security hole against a very specific target – usually a government agency or a high-stakes corporate group. For normal people, in normal situations, it’s not a big deal.

We’ve seen these “sky-is-falling” scenarios play out over and over again in the past year or so. Some security holes (e.g., for EternalBlue/WannaCry and BlueKeep) need to be plugged shortly after the patches are released. But in the vast majority of cases, waiting a week or two or three to install the latest crop of Windows and Office patches just makes sense.

Windows Defender ‘Items skipped during scan’

Many – but not all – Windows 10 users report that a manual scan by Windows Defender triggers this “Items skipped during scan” notification (screenshot).

Windows Defender items skipped during scan 2 Microsoft

It appears to be a bug. According to Lawrence Abrams at BleepingComputer:

“It seems that in the older Windows Defender engines network scanning was enabled by default… [in newer versions of the engine] you can see that the Windows Defender preferences show that network scanning has now been disabled by a newer engine. It is not known why Microsoft decided to make this change, but the alerts appear to just indicate that network scanning was skipped.”

Günter Born originally reported on the bug. He has come up with a manual workaround to enable network scanning.

Other developments

More on the patching front:

  • Microsoft has announced that it’s extending end-of-life for Win10 version 1709 Enterprise (and Education) to Oct. 13, 2020.
  • Abbodi86 has discovered a way to install the latest Windows 7 security patches, even if you haven’t yet set up Extended Security Updates. Many people, including Patch Lady Susan Bradley, are asking Satya Nadella to offer Win7 Extended Security Updates to all “genuine” Win7 customers, particularly because of the increase in work-from-home.
  • In the same vein, there’s a lot of discussion about throttling back on Windows auto updates, specifically to help keep work-from-home systems stable. Many advocate holding off on the inevitable Win10 version 2004 update. No indication that Microsoft has heard the pleas.

If there ever were a time for Windows patching stability, this is it.

We’ll keep pushing on AskWoody.com.





Source link

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

The real stinker this month, KB 4524244, rolled out the automatic update chute for four full days until Microsoft yanked it – leaving a trail of wounded PCs, primarily HP machines, in its wake. The other big-time bug in this month’s patches, a race condition in the KB 4532693 Win10 version 1903 and 1909 cumulative update installer, hasn’t been officially acknowledged by Microsoft outside of a blog post. But at least it’s well known and understood.

Folks running SQL Server and Exchange Server networks need to get patched right away.

Win10 UEFI update KB 4524244 blockages

Patch Tuesday brought KB 4524244 for Windows 10 owners, a bizarre single-purpose patch apparently directed at one specific UEFI bootloader. I talked about it last week.

The patch was pulled on Friday, but in the interim lots of people reported problems. Most notably, many folks running HP machines with Ryzen processors saw their machines hang, followed by an HP Sure Start Recovery message saying Sure Start had “detected an unauthorized change to the Secure Boot Keys.” HP has posted a list of affected machines:

HP EliteBook 735 G5 Notebook PC, 735 G6, 745 G5, 745 G6,  755 G5, and HP ProBook 645 G4 Notebook PCs. HP EliteDesk 705 35W G4 Desktop Mini PC, 705 65W G4 Mini PC, 705 G4 Microtower PC, 705 G4 Small Form Factor PC, 705 G4 Workstation Edition, 705 G5 Desktop Mini PC, 705 G5 Small Form Factor PC, HP mt44 Mobile Thin Client, mt45 Mobile Thin Client, and HP ProDesk 405 G4 Small Form Factor PC.

If you have any of those machines and left your PC open to Microsoft’s updates during Patch Week, you got clobbered. In addition, Microsoft documents a bug in the “Reset this PC” function but doesn’t give any details.

There’s nothing you can do about it now. If KB 4524244 installed successfully, everything’s OK. If it didn’t, you need to follow HP’s removal instructions or Microsoft’s removal instructions to get things working again.

Win10 Cumulative Update KB 4532693 clears desktops, moves files

Shortly after the Patch Tuesday patches arrived, we started seeing reports from folks who installed the Win10 1903 and 1909 cumulative update, KB 4532693, saying that their desktops got wiped out. A little poking revealed that all of their customizations had been tossed – icons, wallpaper – and many of their files weren’t where they left them.

Long story short, it looks like the patch gets ensnared in a race condition bug, which I wrote about last week. We’ve never been able to pin down which other programs trigger the race condition, but at least in some cases certain antivirus and “secure banking software” programs will leave your PC with a dangling temporary profile.

Microsoft hasn’t identified the offending software. Nor has it even acknowledged the problem either on the Knowledge Base article page or the Windows Release Information status page, two places that bugs like this are traditionally documented. (Perhaps Microsoft figures it’s the other software’s problem, so it has no need to report it?)

Fortunately, there’s a Microsoft Answers forum post that addresses the problem:

Microsoft is aware of some customers logging into temporary profile after installing KB4532693, on both versions 1903 and 1909.

Rebooting into Safe Mode* and then starting back in normal Mode should resolve this issue for most customers.

You may uninstall any secure banking software or anti-virus in the temporary profile which may resolve this if the above steps do not help.

If you didn’t accidentally find that explanation, or don’t know what a temporary profile is, or how it could get secure banking software, heaven help ya. But at least Microsoft “is aware” of the problem.

What’s the big deal?

How many people were affected by those high-profile bugs? I don’t know. Judging by the number of complaints online – hardly a reliable metric – both of the problems were widespread and became apparent shortly after release.

HP could probably come up with a tally of the number of afflicted machines and whether or not those machines installed the buggy UEFI patch. But the only organization that has comprehensive numbers about these bugs is Microsoft, and it’s not talking.

Think of all of that lovely telemetry we’re providing to Microsoft.

Odds ‘n Ends

That “exploited” Internet Explorer JScript hole, CVE-2020-0674 – the one that prompted computer security “experts” to tell you that you had to get patched RIGHT NOW? It hasn’t gone anywhere. This is the second month in a row that we’ve been inundated by Chicken Little warnings about the need to get patched immediately. Look where knee-jerk installation of new patches has left folks running HP Ryzen computers, or the unidentified “secure banking software,” this month.

Those of you running Windows 7, who haven’t paid for Extended Security Updates, should know that 0patch has released a micro patch for that particular security hole. It also has an online test you can use to confirm that your Win7/IE 11 system has properly swallowed the micro fix.

To be sure, there are major security holes that need your attention, but only if you’re in charge of a network running SQL Server or Exchange Server. That latter vulnerability is particularly vexing because anyone who can get access to any Exchange account on your server can take over Exchange. Seems that somebody forgot to delete hard-coded keys.

We’re looking into a report that Win10 version 1903 running Hyper-V is throwing “Synthetic_Watchdog_Timeout” errors. There are unconfirmed reports that there will be a fix in late March.

There seems to be a way to cheat the 35-day “Pause updates” limitation imposed in Win10 version 1903 and 1909. In a nutshell, if you tell Windows to Resume Updates, then unplug the computer from the internet, you may be able to reboot and get 35 more days paused, without installing the outstanding updates. In addition, @abbodi86 has a more complex but apparently foolproof way to wipe out the 35 day limitation.

Join the patch watch on AskWoody.com.



Source link

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

The big patching problems this month fell at the feet of admins who had to deal with an unholy mess of pressing exposures: Fixing the holes in Microsoft’s RD Gateway (CVE-2020-0610; see Susan Bradley’s Patch Watch, paywalled); dealing with Server 2008 R2 systems that booted to Recovery mode after installing the January patches; scrambling to pick up after breaches in Citrix networking products; or the 334 Oracle security patches. They all took a toll.

Those of us not in charge of multinational networks could breathe a little easier. In spite of a stellar advertising campaign from the National Security Agency (NSA), the Chain of Fools/CurveBall CVE-2020-0601 hole hasn’t turned into an active attack. As I said at the time, it’s a long way from a third-degree polynomial to working ransomware.

Yes, you need to patch sooner or later. But, no, the sky isn’t falling. Those reports of the internet’s impending CurveBall doom were just a little bit overblown.

As usual.

Still no ‘optional, non-security’ patches

I would conjecture that the January Patch Tuesday crop is relatively well-behaved because, at least apparently, they only contain security patches. Normally, Microsoft releases dozens of “optional, non-security” patches every month – bug fixes – but those annoying little gnats haven’t made an appearance since October.

I expect that will change shortly. We’ll no doubt see dozens – if not hundreds – of smaller patches out in the usual “C Week/D Week” cadence soon. Since we’ve seen no such infestation in three months, you’d be smart to avoid the “optional” patches, once they arrive, until they’ve been well vetted.

Common patching problems persist

Günter Born has put together a comprehensive list of printing problems associated with recent patches. They seem to come and go – many different printers, many different symptoms.

There are also many reports of January cumulative updates failing to install, with various error message.

None of the problems seem particularly remarkable – or even replicable – to me, but if you get stuck trying to install one of the January patches, your opinion may vary.

Upgrades to 1909 press forward, Microsoft continues to honor 1803 deferrals

If you “seek” by clicking on the “Check for updates” button in Win10 1809 or 1903, Microsoft warns that it may upgrade you to Win10 version 1909:

Current status as of Jan. 21:

Windows 10, version 1909 is available for any user on a recent version of Windows 10 who manually selects “Check for updates” via Windows Update. The recommended servicing status is Semi-Annual Channel.

Of course, Microsoft disavowed any use of the bafflegab phrase “Semi-Annual Channel” a year ago. Consistency. Hobgoblins. Little minds. Microsoft may feel that 1909 is ready for widespread deployment, but I’m still seeing many reports of problems with Win10 version 1909 – the well-documented Search in File Explorer bugs, power problems, video problems, Your Phone oddities.

In addition, Microsoft has warned that it’s starting to force Win10 version 1809 customers onto 1909:

“We are starting the next phase in our controlled approach to automatically initiate a feature update for an increased number of devices running the October 2018 Update (Windows 10, version 1809) Home and Pro editions, keeping those devices supported and receiving the monthly updates that are critical to device security and ecosystem health. Our rollout process starts several months in advance of the end of service date to provide adequate time for a smooth update process.”

For reference, Win10 version 1809 is supposed to hit end of service on May 12. You 1809 users are getting four months shaved off of your promised end of life. As a Service.

Remarkably, tests by @PKCano show that Microsoft is still honoring the “Defer feature updates” setting in Win10 version 1803 Pro. It looks like the methods for staying on 1803, 1809, and 1903 as documented in How to block the Windows 10 November 2019 Update, version 1909, from installing still work. And if you want to upgrade to 1903, avoiding 1909 for the time being, the method described here also works.

Windows 7 gets its butt slapped on the way out

Everybody’s favorite whipping boy, Windows 7, got slapped with two bugs in the final round of free patches.

Anybody using Win7 who installs the January patches will find that their “stretched” desktop wallpaper comes out black, which can look disconcertingly like a Black Screen of Death. Lawrence Abrams has a full description, and a clever workaround, at BleepingComputer.

More alarmingly, Microsoft posted Security Advisory ADV200001 on Jan. 17. The Advisory details yet another security hole in Internet Explorer’s JScript engine, CVE-2020-0674. There’s a manual workaround with numerous side-effects, at least some of which have been overcome by a 0patch micropatch that you can install if you feel threatened.

Here’s the big open question: Will Microsoft fix Windows 7 later this month, in spite of the Jan. 14 end of service deadline? Or will Win7 drift into the sunset with a Black Screen bug and a known IE hole?

Seven semper fi.

Microsoft’s tone-deaf threat to hijack Google Chrome’s search engine

This isn’t a widespread problem. It only applies to those who are running Office 365 ProPlus, which is directed at (but not limited to) Enterprises with savvy admins. But it’s an astounding push nonetheless.

In an official post from ‘Softie Daniel Brown entitled, Microsoft Search in Bing and Office 365 ProPlus, Microsoft seems to be saying that everyone who installs the latest patch for Office 365 ProPlus will have their default search engine in Google Chrome changed to Bing.

I fully expect someone with some sense at Microsoft will swoop down in the next week or two and rescind the decision. But until that happens, this stands as a browser hijacking threat of unprecedented proportions.

Join us for the latest on AskWoody.com.



Source link

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

It was the kind of month admins dread: Mysterious problems on hundreds of machines, with no apparent cause or cure. Toss in the holidays, and we had a whole lot of Mr. and Ms. Grinches in the industry.

Fortunately, it looks like the problems have been sorted out at this point. Individual users had many fewer problems. Microsoft’s left and right hands still aren’t talking on the 1909 team, but what else is new…

Win7 hang on ‘Preparing to configure Windows’

Microsoft dropped a new Servicing Stack Update for Windows 7 on Dec. 10, and it gummed up the works for many. Here’s a good summary on Reddit from poster Djaesthetic:

“We had over 100 Windows 7 Professional endpoints all stuck on “Preparing to configure windows” screen. We couldn’t get beyond that error in any simplistic manner. We eventually got a remediation to get beyond that error (involving booting each one from an ISO and making several registry hive edits to TrustedInstaller). Unfortunately, even after we were able to log in, the entire OS is functionally broken….

“…We are having this same issue on 111 different Windows 7 machines, each one consistently having the same environment problems. We are unable to roll back the KB4530734 Windows Update, likely because the Windows Module Installer (TrustedInstaller.exe) service itself is broken… I’ve been working non-stop all weekend. Currently waiting for (yet another) callback from Microsoft….

As Djaesthetic later posts, the problem is triggered by the Dec. 10 Servicing Stack Update, KB 4531786:

“In our investigation we confirmed the problem having to do with KB4530734 (December Monthly Rollup for Windows 7 Service Pack 1). More specifically, we believe it had something to do with KB4531786 (Servicing stack update for Windows 7 SP1 and Server 2008 R2 SP1: December 10, 2019) applying out of order. Interestingly, if you look at the notes for the December rollup it specifies a recommendation to install the SSU afterward (not a requirement). Lastly, we found some (not all) machines in various states of “Uninstall_Pending” regarding the November Monthly Rollup….”

Those of you using plain old single-system Monthly Rollups won’t encounter the problem. But if you or your system’s admin is manually installing patches, getting them in the wrong order can cause all sorts of problems. Manually installing the Servicing Stack Update can be particularly vexing because SSUs won’t show up until you’ve installed (or hidden) all outstanding patches.

Server 2012 (not R2) reboots

There were lots of reports of Server 2012 (not R2) servers going into reboot loops after last month’s updates. I originally reported on AskWoody that the problem appeared to be with KB 4533096, the “Security and Quality Rollup for .NET Framework 3.5, 4.5.2, 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2, 4.8 for Windows Server 2012.” But I now think that a bad Malicious Software Removal Tool (MSRT) version may have been at fault.

Manually rebooting cleared up the issue. And the mid-December version of MSRT is long gone. There’s no official confirmation or explanation that I can find.

Win10 version 1909 bugs continue

The December patch didn’t fix the long-decried File Explorer Search bug in Win10 version 1909. You may recall that Microsoft’s known about the bug – which makes Search in File Explorer unusable – since 1909 shipped. They fixed the bug in a Win10 version 2004 beta test version

Microsoft still hasn’t confirmed the bug in the official Release Information Status page. I’ve seen Twitter threads where Microsoft employees claim no knowledge of the problem – in spite of the fact that the bug’s been reported over and over again in many different places (including the Feedback Hub) for months. @navh2009 nails it:

“If they are going to keep half baking these new changes, then they should stop making changes to things [that] were never broken. File Explorer search didn’t need windows search. Delete key still doesn’t work. How does basic functionality like this get forgotten every time?”

@railmeat goes on to say:

“These kinds of problems reoccur [due] to inadequate testing. These should be found in regression and functionality testing. Microsoft has the resources to do that testing, but apparently chooses not to.”

@abbodi86 has an explanation:

“In 1909, the upper bar of File Explorer (address + search box) no longer belongs to the Win32 platform. It’s a hybrid WinRT (UWP) feature. It’s half-baked, ugly, slow, and requires some prerequisite tasks to even semi-function (clipboard and other services including the MsCtfMonitor task schedule).”

I still recommend that folks avoid 1909 for precisely this reason.

Join us for the latest on AskWoody.com.





Source link

Bugs continue to haunt Win10 version 1909

Remember the hype about the Win10 version 1909 upgrade — how this fall’s Win10 1903 update would contain all of the 1909 features, lacking only the flip of a light switch to turn them on? Here’s how Microsoft puts it:

Windows 10, versions 1903 and 1909 share a common core operating system with an identical set of system files. Therefore, the new features in Windows 10, version 1909 were included in the latest monthly quality update for Windows 10, version 1903 (released October 8, 2019), but are in an inactive and dormant state. These new features will remain dormant until they are turned on through the “enablement package,” a small, quick-to-install “master switch” that activates the Windows 10, version 1909 features.

Demonstrably, two well-documented bugs in 1909 have nothing to do with master switches. To quote a noted industry authority, “Bah! Humbug!”

The first bug, a persistent wake-up call, only occurs on some machines, but it’s very annoying. An anonymous poster on AskWoody describes it this way:

Since the [1909 upgrade], my computer wakes up every day around 10 AM (it could be worse..), Using “powercfg/lastwake” in a command shell I found it was waking due to a scheduled task:

‘NT TASKMicrosoftWindowsUpdateOrchestratorUniversal Orchestrator Start’

It appears that an Admin account running Task Scheduler (Admin mode) can’t edit or disable the two apps that contain “wake to run” settings. In other forums, people have found that various “fixes” get reset by Windows. This acts like malware. The worst thing is that the computer STAYS ON ignoring any sleep times you have set in your Power & Sleep setting.

Resident expert @abbodi86 says he knows of ways to disable the task, but they’ll get re-enabled during Windows Update scans. Nothing you can do about it.

Does that sound like a flipped “master switch” to you?

The second bug is far more widespread — indeed, ubiquitous. Many people consider it a deal breaker. Mayank Parmar at Windows Latest has a thorough analysis:

Windows 10 version 1909 includes an updated File Explorer that allows you to quickly preview the search results of local and OneDrive contents. While the new search bar is useful, it freezes for a long period of time and this has been confirmed by a good number of users … [version 1909] also disables right-click in the File Explorer and users cannot paste text in the search bar with the mouse.

Doesn’t sound like a “master switch” to me. In fact, it sounds like somebody decided to replace the code that implements File Explorer Search — and botched it. But the infamy doesn’t stop there. It looks like Microsoft has known about the problem since shortly after (or maybe before) 1909 shipped, and has been sitting on its thumbs. Per Parmar:

In the changelog of Windows 10 20H1 Build 19013, Microsoft noted that it has resolved an issue where it is not possible to set focus to File Explorer’s search box.

> We fixed an issue where you could get into a state where it wasn’t possible to set focus to File Explorer’s search box in order to type your query.

Sure sounds like Microsoft knows all about at least part of the problem — and fixed it in beta build 19013, which went out on Oct. 29. Consider, though, that Microsoft officially shipped Win10 1909 on Nov. 12, apparently with at least part of the bug intact. There’s been one cumulative update since then, on Dec, 10, and it didn’t fix the File Explorer Search bug either.

Parmar goes on to note that Microsoft fixed yet other manifestations of the File Explorer Search bug(s) in beta build 19536, released on Dec. 16:

We’ve updated the new File Explorer search experience to enable you to remove previous searches via an option if you right click the entry in the dropdown.

We fixed an issue resulting in the first character of your query getting dropped when “automatically type into the search box” File Explorer setting was enabled.

Parmar’s optimistic about the future:

We don’t know when Microsoft is planning to backport the fixes to Windows 10 November 2019 Update, but it’s likely to happen in January 2020.

Wish I shared his optimism.

@abbodi86 explains what’s going on behind the scenes:

In 1909, the upper bar of File Explorer (address + search box) no longer belongs to the Win32 platform. It’s a hybird WinRT (UWP) feature. It’s half-baked, ugly, slow, and requires some prerequisite tasks to even semi-function (clipboard and other services including the MsCtfMonitor task schedule).

By the way, there is a way to turn this feature off and restore the old behavior, using the third party tool mach2.exe. But even with that, the system will revert to the new buggy, bad version after a short amount of time, or on reboot.

There’s been no acknowledgment of either bug in the Official Known Issues list

We can jump through all sorts of semantic hoops, but to me we aren’t looking at “a common core operating system with an identical set of system files.” At least with the File Explorer Search bug(s), we’re looking at substantially different modules — one of which appears to be an attempt to change from Win32 to WinRT — with disastrous results.

I’ve come to the conclusion that the “master switch” is another piece of marketing drivel. Don’t get me wrong: I greatly appreciate the subdued nature of the 1909 upgrade and hope and pray to all that is Winholy that Microsoft will switch to major upgrades once a year. But 1903 and 1909 are two different code bases, no matter how you slice it.

I still won’t install 1909 on my production machines. 

Join us for the Ghost of Christmas Present on AskWoody.com.

Copyright © 2019 IDG Communications, Inc.



Source link