Posts Tagged

bug

In spite of the disappearing Windows desktop bug, now’s a good time to install the February patches

It’s frustrating when Microsoft refuses to acknowledge a widespread bug in one of its mainstream patches. This month we’re looking at a major bug that’s drawn a tiny mention on a Microsoft Answers Forum post — and that’s it. Such is the state of Windows transparency these days.

On the plus side, though, we have enough experience with the bug to be able to recognize and fix it should you be so unlucky as to encounter it.

Other than that one glaring (if infrequent) bug, there are some minor problems, but, on the whole, now would be a good time to get your system updated. Here’s how.

Make a full backup

Make a full system image backup before you install the latest patches.

There’s a non-zero chance that the patches — even the latest, greatest patches of patches of patches — will hose your machine. Best to have a backup that you can reinstall even if your machine refuses to boot. This, in addition to the usual need for System Restore points.

There are plenty of full-image backup products, including at least two good free ones: Macrium Reflect Free and EaseUS Todo Backup

Running Win10? I’m moving to version 1909 and suggest you do, too.

If you’re running Win10 version 1803, 1809, Server 1809, Server 2019 or any earlier version of Windows 10, I urge you to upgrade to Win10 version 1903 or 1909. (You can find your version by typing winver in the Search box in the lower left corner and pressing Enter.) There are detailed instructions for making the move in the article “Why — and how — I’m moving Win10 production machines to version 1903.”

Win10 1903 is far from perfect, but it seems to be relatively stable at this point. The one huge advantage to version 1903: It lets everybody pause updates with a few simple clicks. That feature has my vote for the most important (perhaps the only important) upgrade to Win10 in the past four years. 

It looks like Microsoft has finally fixed the glaring bug in Win10 version 1909 — the one that made File Explorer’s Search box completely useless. We saw a minor improvement in the January cumulative update, but the February cumulative update, KB 4532693, seems to fix the problem completely. Of course, there’s been no acknowledgment or even a description from Microsoft, but as best I can tell File Explorer Search is working now. Yes, the bug’s been in there since 1909 shipped.

At any rate, I’m moving my production machines to 1909. Moving from Win10 version 1903 to 1909 is quite easy. After making a full backup, click Start > Settings (the gear icon) > Update & Security. If you don’t see the Download and install link shown in the screenshot, click Check for updates and it should appear.

1909 download and install now updated Woody Leonhard/IDG

Click on the link marked Download and install and wait. When you reboot, Win10 will be on version 1909, build 18363.657. That’s the build of 1909 that corresponds to the February cumulative update. It does not include the “optional, non-security, C/D Week” patch KB 4535996, which you don’t want.  

Install the Win10 February Cumulative Update

If you just moved to Win10 version 1909, per the preceding section, you already have the February Cumulative Update, KB 4532693. Breathe easy.

If you’re staying with Win10 version 1903, I certainly sympathize. If you were already running Win10 version 1909, I admire your bravery. To get the February Cumulative Update installed, click Start > Settings > Update & Security. If you see a Resume updates box (screenshot), click on it.

1903 updates paused Woody Leonhard/IDG

That’s all you need to do. Windows, in its infinite wisdom, will install the February Cumulative Update at its own pace. If you don’t see a Resume updates box, you already have the February Cumulative update and all is right in this, the best of all possible worlds.

When your machine comes back up for air, don’t panic if your desktop doesn’t look right, or you can’t log in to your usual account. You got bit by the “temporary profile” bug, which we’ve known about — and complained about — for weeks. We have three separate threads on AskWoody about solving the problem [1, 2, 3] and if you need additional help, you can always post a question. (Thx, @PKCano.)

Note: According to a report on the GratisSoftwareSite.nl site,the “optional, non-security, C/D Week” patch for Win10 version 1903 and 1909, KB 4535996, has the same profile-eating bug as its predecessor. Caveat updator.

If you see an offer that says “Optional updates available,” just ignore it. You aren’t being paid enough to beta test Microsoft’s next set of patches.

While you’re mucking about in Windows Update, it wouldn’t hurt to Pause updates, to take you out of the direct line of fire the next time Microsoft releases a buggy bunch of patches. Click Start > Settings > Update & Security. Click “Pause updates for 7 days.” Next, click on the newly revealed link, which says “Pause updates for 7 more days,” four more times. That pauses all updates for 35 days, until early April. With a little luck that’ll be long enough for Microsoft to fix any bugs it introduces in March.

We’ll have new observations and suggestions as the month winds on.

Patch Win7, Win8.1, or associated servers

If you’ve paid for Win7 Extended Security Updates and you’re having trouble getting them installed, Microsoft has a new article called Troubleshoot issues in Extended Security Updates that may be of help. We’re also fielding questions on AskWoody.

If you haven’t paid for Extended Security Updates but want to keep WIn7 protected, 0patch has started publishing patches that cover some of the security holes plugged by the paid Extended Security Updates.

Windows 8.1 continues to be the most stable version of Windows around. To get this month’s puny Monthly Rollup installed, follow AKB 2000004: How to apply the Win7 and 8.1 Monthly Rollups. You should have one Windows patch, dated Feb. 11 (the Patch Tuesday patch). 

After you’ve installed the latest Monthly Rollup, if you’re intent on minimizing Microsoft’s snooping, run through the steps in AKB 2000007: Turning off the worst Win7 and 8.1 snooping. If you want to thoroughly cut out the telemetry, see @abbodi86’s detailed instructions in AKB 2000012: How To Neutralize Telemetry and Sustain Windows 7 and 8.1 Monthly Rollup Model.

Thanks to the dozens of volunteers on AskWoody.com who contribute mightily, especially @sb, @PKCano, @abbodi86 and many others.

We’ve moved to MS-DEFCON 3 on the AskWoody Lounge.

Copyright © 2020 IDG Communications, Inc.



Source link

With a fix for the ‘temporary profile’ bug still elusive, Win10 1903 and 1909 customers should check Pause Updates

By now you’ve probably heard about the disappearing-profile bug in this month’s Win10 1903 and 1909 cumulative update. The buggy patch went out on Tuesday, Feb. 11. Reports started rolling in shortly afterward about desktops that were wiped clean, wallpaper replaced, even files that disappeared. I wrote about it on Thursday morning:

Many people are in a tizzy — their desktop icons are gone, they can’t log onto their usual Admin account, and their files most definitely aren’t where they left them.

Since then we’ve seen many hundreds of complaints and dozens of articles about the mayhem. Ends up that the hapless victims had their Windows profiles swapped out, replaced by a temporary profile. The buggy patch moved their cheese and hid it where all but the most advanced Windows boffin would never find it.

Early on, Patch Lady Susan Bradley nailed the cause of the problem:

Loss of profile has historically been a race condition between the boot process and something holding files open. I personally have seen antivirus most often do this but it could be other things like antiransomware protection, group policy settings. Microsoft DOES test their patches, they really do. What they can’t do is test for the myriad of unknown ways that we set up our computers.

(Techy note: A race condition is a timing issue that arises when two or more independent programs stomp on each other. They’re very difficult to diagnose.)

Initial reports pointed the finger at a specific antivirus package as being the one that tangled with the KB 4532693 installer, but then we discovered that not all folks running that AV software were getting bit. Then we had a series of reports about local accounts (users who aren’t signed on with a Microsoft Account) getting the special treatment. Nope, that wasn’t the problem.

Microsoft hasn’t officially acknowledged the bug, as best as I can tell, aside from two posts on the Answers forum. On Feb. 12, Lawrence Abrams at BleepingComputer said that a Microsoft rep told him, “We are aware of the issue and are investigating the situation.” On Feb. 17, almost a week after the bug first appeared, Mayank Parmar at Windows Latest said:

In a conversation with Microsoft’s support team, multiple employees told us that Microsoft is aware of the issue and are actively investigating the situation. “Microsoft is aware of this known issue and our engineers are working diligently to find a solution for it,” a staff stated.

There have been multiple reports of users losing data because of the KB 4532693 patch. I haven’t seen that happen as yet, personally, so remain skeptical. Far more likely is that the data got stuffed into a .BAK or .000 or .003 folder inside the C:Users folder — the place Windows sticks profiles. If a Windows customer runs a Cleaner program while trying to fix the lost profile bug, the backup may well be gone.

Most distressing: Susan Bradley reports on a response to a Microsoft support case, in which a Microsoft technician specifically mentioned Windows Defender as a possible source of conflict:

I discussed the case with my tech lead and confirmed this to be a bug — 25270101 … find the Windows Defender Advanced Threat Protection and Microsoft Defender Antivirus services, right-click each of them, select Properties, and change Startup Type to Disabled, selecting OK after each change. Restart your device in normal mode and attempt to sign in with your original profile.

It isn’t at all clear if Defender might be part of the two-to-tango race condition. 

And, of course, neither the Knowledge Base article nor the official Windows Release Status page says a word. Nine days later and the buggy patch is still being shoveled out the Windows Automatic Update chute.

Not all is doom and gloom.

If you’re using Pause Updates in Win10 1903 or 1909 to block Microsoft’s patches, and your “Resume updates” date is far enough out — today or later — you didn’t get either this buggy patch or the monstrous KB 4524244 UEFI “patch,” which was pulled last week. But if you’re relying on Pause Updates, now would be a very good time to make sure it’s set out to the end of the month or later. Heaven only knows when (if!) Microsoft is going to re-release KB 4532693 and fix the disappearing profile problem.

For most of you, pausing updates until March 9 seems like a very good idea. (If you’re running SQL Server, though, you need to get the February patches installed. Sorry.)

To adjust your Pause Updates setting, first make sure you’re running either Win10 version 1903 or 1909 (type winver down in the Search box and press Enter). If you are, click Start > Settings > Update & Security. You should see something like the screenshot.

defer to 03 09 2020 Woody Leonhard/IDG

If your “Updates will resume on” date is before March 9, click the “Pause updates for 7 more days” link. (March 9 is a lucky number because the next Patch Tuesday is on March 10. Presumably Microsoft will fix this mess prior to that date. Presumably.)

In the past, I haven’t recommended that you extend the “Resume updates” date by pressing the “Pause updates for 7 more days” link because Microsoft has long warned that you can only extend updates after you’ve installed the currently available updates: 

After the pause limit is reached, you’ll need to install the latest updates before you can pause updates again.

I’m delighted — and surprised — to tell you that, at least in my tests, that limitation no longer applies. It appears to me as if you can go back in and pause updates for seven more days at a clip, even if you already have Pause updates set.

That’s remarkably good news.

Questions? Observations? Vituperations? We’re all ears on AskWoody.

Copyright © 2020 IDG Communications, Inc.



Source link

Reports say the manual-install-only ‘Stretch’ bug fix for Win7 and 2008R2 deletes boot file

Remember the manual-download-only patch For Win7/Server 2008 released late last week? You may know it better as KB 4539602.  

Microsoft changed the downloadable installation files yesterday. Microsoft didn’t modify the Knowledge Base article, though, so we have no idea what changed, but that’s par for the course, eh?

Several admins on Reddit chimed in with ybillo, who said:

Check with your clients who have or are running Windows Server 2008. There is a windows update that is deleting boot file for windows. It was released after they had announced end of support for Server 2008 & Windows 7.

Microsoft update KB4539602

Microsoft released the update to fix issues with the Background but its causing more harm than its supposed to do. Yesterday (9th-feb) one of our clients [bank] we had an issue of the same on 3 Avaya servers running windows server 2008.

Kindly treat this as urgent.

There’s a chorus of agreement about the problem in that Reddit thread, but no acknowledgment in the official Knowledge Base article.

Richard Speed at The Register points the finger at Microsoft’s documented prerequisites:

In a nutshell, users must have the 23 September 2019 (or later) SHA-2 update installed as well as the servicing stack update from 12 March 2019 or later, before they unleash the fix. And naturally you’ll need to reboot after these updates. Because, hey, everyone loves rebooting a server, right?

Which is all well and good, but if your machine doesn’t have SHA-2 support, you shouldn’t be able to install the patch (which is signed with SHA-2). That’s been true for several months. 

The Servicing Stack Update is another matter altogether. Perhaps yesterday’s changes to the installation files ensured that the latest SSU was in place before installing the patch. Cart. Horse. You know.

At any rate, Microsoft hasn’t documented any of it, leaving many of us shaking our heads — and our fists — once again.

Join the shakeathon on AskWoody.com.

Copyright © 2020 IDG Communications, Inc.



Source link

Facebook’s iOS ‘bug’ secretly filmed users. IT, take note.

News reports last week — subsequently confirmed by a Facebook executive’s tweet — that the Facebook iOS app was videotaping users without notice should serve as a critical heads up to enterprise IT and security execs that mobile devices are every bit as risky as they feared. And a very different bug, planted by cyberthieves, presents even more frightening camera-spying issues with Android.

On the iOS issue, the confirmation tweet from Guy Rosen, who is Facebook’s vice president of Integrity (go ahead and insert whatever joke you want about Facebook having a vice president of integrity; for me, it’s way too easy a shot), said, “We recently discovered our iOS app incorrectly launched in landscape. In fixing that last week in v246, we inadvertently introduced a bug where the app partially navigates to the camera screen when a photo is tapped. We have no evidence of photos/videos uploaded due to this.”

Please forgive me if I don’t immediately accept that this filming was an error, nor that Facebook has no evidence of any photos/videos being uploaded. When it comes to being candid about their privacy moves and the real intentions behind them, Facebook executives’ track record isn’t great. Consider this Reuters story from earlier this month that cited court documents establishing that “Facebook began cutting off access to user data for app developers from 2012 to squash potential rivals while presenting the move to the general public as a boon for user privacy.” And, of course, who can forget Cambridge Analytica?

In this case, though, intentions are irrelevant. This situation merely serves as a reminder of what apps can do if no one is paying enough attention.

This is what happened, according to a well-done summary of the incident in The Next Web (TNW): “The problem becomes evident due to a bug that shows the camera feed in a tiny sliver on the left side of your screen, when you open a photo in the app and swipe down. TNW has since been able to independently reproduce the issue.”

This all began when an iOS Facebaook user named Joshua Maddux tweeted about his scary discovery. “In footage he shared, you can see his camera actively working in the background as he scrolls through his feed.”

It seems as though the FB app for Android does not do the same video effort — or, if it does happen on Android, it’s better at hiding its stealthy behavior. If it is the case that this only happens on iOS, that would suggest that it might indeed be just an accident. Otherwise, why wouldn’t FB have done it for both versions of its app?

As for iOS vulnerability — note that Rosen didn’t say that the glitch was fixed or even promise when it would be fixed — it seems to depend on the specific iOS version. From the TNW report: “Maddux adds he found the same issue on five iPhone devices running iOS 13.2.2, but was unable to reproduce it on iOS 12. ‘I will note that iPhones running iOS 12 don’t show the camera, not to say that it’s not being used,’ he said. The findings are consistent with [TNW’s] attempts. [Although] iPhones running iOS 13.2.2 indeed show the camera actively working in the background, the issue doesn’t appear to affect iOS 13.1.3. We further noticed the issue only occurs if you have given the Facebook app access to your camera. If not, it appears the Facebook app tries to access it, but iOS blocks the attempt.”

How rare it is that iOS security actually comes through and helps, but it appears to be the case here.

Looking at this from a security and compliance perspective, though, is maddening. Regardless of Facebook’s intent here, the situation is allowing the videocamera on the phone or tablet to come alive at any point and start capturing what is on the screen and where the fingers are positioned. What if the employee is working on an ultra-sensitive acquisition memo at that moment? The obvious problem is what happens if Facebook is breached and that particular video segment winds up on the dark web for thieves to purchase? Want to try explaining that to your CISO, the CEO or the board?

Even worse, what if this isn’t an instance of a Facebook security breach? What if a thief sniffs the communication as it travels from your employee’s phone to Facebook? One can hope that Facebook security is fairly robust, but this situation permits the data to be intercepted enroute.

Another scenario: What if the mobile device is stolen? Let’s say that the employee properly created the document on a corporate server accessed via a good VPN. By video-capturing the data while typing, it bypasses all security mechanisms. The thief can now potentially access that video, which offers images of the memo. 

What if that employee downloaded a virus that shares all phone content with the thief? Again, the data is out.

There needs to be a way for the phone to always flash an alert whenever an app attempts access and a way to shut it down before it happens. Until then, CISOs are unlikely to sleep well.

On the Android bug, other than accessing the phone in a highly naughty way, the problem is very different. Security researchers at CheckMarx published a report that made it clear how attackers could sidestep all security mechanisms and take over the camera at will.

“After a detailed analysis of the Google Camera app, our team found that by manipulating specific actions and intents, an attacker can control the app to take photos and/or record videos through a rogue application that has no permissions to do so. Additionally, we found that certain attack scenarios enable malicious actors to circumvent various storage permission policies, giving them access to stored videos and photos, as well as GPS metadata embedded in photos, to locate the user by taking a photo or video and parsing the proper EXIF data.This same technique also applied to Samsung’s Camera app,” the report said. “In doing so, our researchers determined a way to enable a rogue application to force the camera apps to take photos and record video, even if the phone is locked or the screen is turned off. Our researchers could do the same even when a user was is in the middle of a voice call.”

The report drills into the specifics of the attack approach.

“It is known that Android camera applications usually store their photos and videos on the SD card. Since photos and videos are sensitive user information, in order for an application to access them, it needs special permissions: storage permissions. Unfortunately, storage permissions are very broad and these permissions give access to the entire SD card. There are a large number of applications, with legitimate use-cases, that request access to this storage, yet have no special interest in photos or videos. In fact, it’s one of the most common requested permissions observed. This means that a rogue application can take photos and/or videos without specific camera permissions, and it only needs storage permissions to take things a step further and fetch photos and videos after being taken. Additionally, if the location is enabled in the camera app, the rogue application also has a way to access the current GPS position of the phone and user,” the report noted. “Of course, a video also contains sound. It was interesting to prove that a video could be initiated during a voice call. We could easily record the receiver’s voice during the call and we could record the caller’s voice as well.”

And yes, more details make this even more frightening: “When the client starts the app, it essentially creates a persistent connection back to the C&C server and waits for commands and instructions from the attacker, who is operating the C&C server’s console from anywhere in the world. Even closing the app does not terminate the persistent connection.”

In short, these two incidents illustrate stunning security and privacy holes within a huge percentage of smartphones today. Whether IT owns these phones or the devices are BYOD (owned by the employee) makes little difference here. Anything created on that device can be easily stolen. And given that a rapidly increasing percentage of all enterprise data is moving to mobile devices, this needs to be fixed and fixed yesterday.

If Google and Apple won’t fix this — given that it’s unlikely to impact sales, since both iOS and Android have these holes, neither Google nor Apple has much financial incentive to act quickly — CISOs must consider direct action. Creating a homegrown app (or convincing a major ISV to do it for everyone) that will impose its own restrictions might be the only viable route.

Copyright © 2019 IDG Communications, Inc.





Source link

Microsoft confirms yet another Search bug in the latest Win10 1903 patch

Remember last month, when Microsoft kinda-sorta announced there was a Cortana/SearchUI redline bug in its second August cumulative update, KB 4512941? Although complaints about the bug poured in within hours of the patch’s release, it took Microsoft four days to ‘fess up, with the first notification in a tweet. Several more days would pass before we had any details.

Early this morning, two days after the September 2019 cumulative update appeared, Microsoft has acknowledged a similar bug with a slightly different profile.

Win10 version 1903 cumulative update KB 4515384, released on Patch Tuesday, says that it:

Addresses an issue that causes high CPU usage from SearchUI.exe for a small number of users. This issue only occurs on devices that have disabled searching the web using Windows Desktop Search.

Once again this month, we started getting complaints about 1903 Search misbehaving shortly after the Patch Tuesday patch appeared. In addition to reports of the latest cumulative update triggering SearchUI redlining, again, IndyPilot80 reported that when he tried to type in the Search box, a black pane appeared, and Search froze.

Mayank Parmar at WindowsLatest reported on the general Search problem, and published a screenshot of the bug in action. 

Within the past two hours, Microsoft updated its Release Information Status page to include this mea culpa:

 Some users report issues related to the Start menu and Windows Desktop Search

Microsoft has received reports that some users are having issues related to the Start menu and Windows Desktop Search.

Affected platforms:

  • Client: Windows 10, version 1903

Next steps: We are presently investigating and will provide an update when more information is available.

It isn’t clear if the bug is related to the trigger for last month’s bug, turning off Windows 10’s infernal tendency to search the web for everything you type in the Search box.

As of this writing, the Knowledge Base article says 

Microsoft is not currently aware of any issues with this update.

Par for the course.

Thx, @etguenni

Join us for the ongoing patch roast on AskWoody.com.

Copyright © 2019 IDG Communications, Inc.



Source link