Patch Tuesday problems, fixes — but no cause for immediate alarm
Credit to Author: Woody Leonhard| Date: Thu, 10 May 2018 10:51:00 -0700
Results are starting to roll in about this month’s Patch Tuesday, and it’s quite a mixed bag. For those of you struggling with the new Windows 10 April 2018 Update, version 1803, there’s good news and bad news. The hand wringing about a new VBScript zero-day, thanks to our good old friend baked-in Internet Explorer, looks overblown for now. And if you can’t get RDP working because of “An authentication error has occurred” messages, you missed the memo.
First, the good news. As I anticipated earlier this week, this month’s cumulative update for 1803 is a must-have, warts and all. The new build 17134.48 replaces the old 17134.1 (which went to those who installed 1803 directly or fell into the seeker trap) and the old 17134.5 (for those upgrading with the Windows Insider builds). As Susan Bradley explains, 17134.48 claims to fix both the Chrome and Cortana freeze, as well as a major VPN bug.
My recommendation continues to be that you should roll back to 1709, but if you insist on using 1803 during its unpaid beta-testing phase, get this month’s cumulative update installed as soon as you can. If you can.
An anonymous poster on AskWoody notes:
1803 was installed without permission on 3 of my computers last week, 5/1/2018. Fortunately no problems, working great. Then in the early A.M. on 5/8/2108 the “fixed” 1803 was installed, once again without permission on all 3 computers (all running Windows 10 Pro). Bricked them all. I make 3 full backup images of each of my computers every day (2 local using Macrium and EaseUS and 1 cloud using Acronis). Restored all 3 computers, backed up data, and did clean installs which installed the latest fixed 1803. Recovered data and all is back to normal, just took a full day.
Assuming you can even get the installer to work. “Microsoft Agent” Lonnie_L on the Microsoft Answers forum says:
When attempting to upgrade to Window 10 April 2018 Update select devices with certain Intel SSDs may enter a UEFI screen reboot or crash repeatedly.
Microsoft is currently blocking some Intel SSDs from installing the April 2018 Update due to a known incompatibility that may cause performance and stability issues. There is no workaround for this issue. If you have encountered this issue, you can roll back to Windows 10, version 1709 and wait for the resolution before attempting to install the April 2018 Update again.
Microsoft is currently working on a solution that will be provided in a near future Windows Update, after which these devices will be able to install the April 2018 Update
We have a thread going on that topic on AskWoody.
The MS Answers forum has a monster thread, started by StephenPhillipsZY who says:
This update has some serious issues, specifically. Do NOT install this update after updating to Windows 10 version 1803. It will prevent your computer from booting up. I am stuck on the spinning circle for a long time. I have to use a Windows 10 USB to boot into the Troubleshooting and use Command Prompt to boot into safe mode. Please fix this update!
There are still many, many bugs in 1803. For example, Mr. Natural says:
I have 2 systems that I installed 1803 on and ever since they are unable to communicate with WSUS. Windows Update pointing to Microsoft works, but not WSUS. I had to manually install that even though my WSUS system has the patch ready to go.
Bogdan Popa at Softpedia tells of many people who try to apply this cumulative update and end up with bricked systems. He has three unbricking methods that may prove handy.
There are also extensive reports of build 17134.48 not being able to see WSUS update servers.
Oh, the joys of IE bound at the knees and elbows to Windows.
Microsoft released an explanation for the one “critical” Windows patch this month that is being actively exploited — a zero-day. Called CVE-21018-8174, the security hole involves the way Internet Explorer (mis)handles VBScript programs. Per Microsoft:
In a web-based attack scenario, an attacker could host a specially crafted website that is designed to exploit the vulnerability through Internet Explorer and then convince a user to view the website. An attacker could also embed an ActiveX control marked “safe for initialization” in an application or Microsoft Office document that hosts the IE rendering engine. The attacker could also take advantage of compromised websites and websites that accept or host user-provided content or advertisements.
Microsoft’s exposé credits both Qihoo 360 Core Security and Kaspersky with the discovery. And at that point, things get complicated.
Kaspersky’s Securelist shows an in-the-wild exploit, using an infected RTF file that on most machines would be opened by Word. The infected file then does its dirty deed through IE, no matter which browser you’ve chosen as default:
With CVE-2018-8174 being the first public exploit to use a URL moniker to load an IE exploit in Word, we believe that this technique, unless fixed, will be heavily abused by attackers in the future, as It allows you force IE to load ignoring the default browser settings on a victim’s system. We expect this vulnerability to become one of the most exploited in the near future, as it won’t be long until exploit kit authors start abusing it in both drive-by (via browser) and spear-phishing (via document) campaigns.
As best I can tell, Kaspersky doesn’t talk about a “web-based attack scenario” where the victim is using Internet Explorer. Instead, it relies on an RTF file — such fules have been carrying malware for years — to bring up Word, and to force Word to use the buggy VBScript engine in IE.
Qihoo 360 has a different explanation:
We code named the vulnerability as “double kill” exploit. This vulnerability affects the latest version of Internet Explorer and applications that use the IE kernel. When users browse the web or open Office documents, they are likely to be potential targets. Eventually the hackers will implant backdoor Trojan to completely control the computer.
Qihoo doesn’t specifically mention RTF-formatted documents, but the one exploit it has discovered is in a document, ostensibly in Yiddish, and “the attack affected regions in China are mainly distributed in provinces that actively involved in foreign trade activities. Victims include trade agencies and related organizations.”
(I asked Morty Schiller, a noted Hebrew/Yiddish scholar, about the language used and he says, “The few words that showed in the background of the image were Yiddish, not Hebrew. But some of the ‘words’ were Hebrew/Yiddish letters interlaced with English letters. So they may have been truncated, or just garbage. None of it seems to make any sense.”)
So as things stand, it looks as if you need to watch out for RTF files in Yiddish/Hebrew sent to Chinese trade agencies, but it’s likely that the technique will become more widespread in the not-too-distant future.
This “Double Kill” problem affects every version of Windows. It isn’t clear if redirecting RTF files to open in something other than Word will fix the document-based infection vector. (You can use Windows to change the default program assigned to the RTF filename extension, and make RTF files open in, say, WordPad — even in Windows 10.)
Back in the good old days, you could just pick out the patch that fixes the problem, install it, and deal with any bugs in the patch in isolation.
Nowadays, since the patchocalypse, that isn’t an option. If you want to protect against Double Kill, you have to install the entire month’s patches — and if you’re using Win10, you have to install both the security and the non-security updates at the same time.
We’ll be watching to see how quickly the Double Kill technique proliferates. If infected RTF files start appearing, we’ll let you know here in Computerworld.
Last week, noted security maven Alex Ionescu revealed yet another bug introduced in all of the Meltdown patches released this year for Win10 version 1709.
It turns out the #Meltdown patches for Windows 10 had a fatal flaw: calling NtCallEnclave returned back to user space with the full kernel page table directory, completely undermining the mitigation.
Microsoft quietly built a fix into Win10 version 1803 — and if you have version 1803, you don’t need to worry about the bug. But we didn’t discover until Patch Tuesday that Win10 version 1709 has the same bug. This month’s version 1709 fix solves it. Says Ionescu:
Incredible turnaround by @msftsecresponse to fix this issue (which only affected Fall Creators Update due to this API being introduced in 1709) in today’s Patch Tuesday. Customers on 1709 now protected just like on 1803.
Meltdown continues its march into the patching hall of fame.
I’ve seen many complaints about this month’s Windows patches triggering an error in Remote Desktop connections (see screenshot).
Those errors keep popping up after installing KB 4093492, the update that fixes CVE-2018-0886, a vulnerability in the CredSSP protocol. (If you don’t use Microsoft Remote Desktop with a server, you don’t need to worry about it.)
Long story short, as Susan Bradley says:
The problem is NOT with the KB 4093492 update. Rather the issue is that there’s a mismatch of patching levels. In March Microsoft released an update that began the process of rolling out an update to CredSSP used in Remote Desktop connection. In May the updates mandate that a patched machine can’t remote into an unpatched machine. If you dig into the KB there is a registry workaround to [TEMPORARILY] disable the mandate, but the better and wiser move is to update the server or workstation you are remoting into. Make sure the “thing” you are remoting into has an update.
If you see that “authentication error” message, check with the folks who maintain your server.
Admins rejoice. It looks like the SMB memory leak bug has finally been fixed. (If you aren’t an admin, you can go back to sleep now.)
Way back in January, the 2018-01 Monthly Rollup introduced a bug in Win7 and Server 2008 R2 that set up a memory leak.
After installing KB4056897 or any other recent monthly updates, SMB servers may experience a memory leak for some scenarios. This occurs when the requested path traverses a symbolic link, mount point, or directory junction and the registry key is set to 1:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesLanManServerParametersEnableEcp
Most people couldn’t care less, but for a significant subset of Server users, that memory leak was a show-stopper. Maybe that’s why some folks didn’t install the CredSSP fix?
The hunt continues for bugs and fixes. Join us on the AskWoody Lounge.