Second Try at LSASS Patch Addresses Vulnerability

Microsoft’s second try at patching a vulnerability in a critical Windows process apparently is more successful than its first attempt.

Yesterday, as part of its monthly Patch Tuesday release of security bulletins, Microsoft sent out an update that fixed a denial-of-service vulnerability in the Windows Local Security Authority Subsystem Service (LSASS). The update was in response to a private disclosure from researcher Nicolas Economou of Core Security, who reported that a patch released in November for the same bug was incomplete.

Core Security confirmed to Threatpost this morning that it had tested the patch and that the issue was resolved.

LSASS enforces Windows security policies around authentication and login verification. It’s a critical process that cannot be terminated without consequences.

Yesterday’s bulletin, MS17-004, was rated important by Microsoft for Vista, Windows Server 2008 (and R2), and Windows 7. An attacker using a specially crafted authentication request could remotely cause an automatic system reboot. Microsoft said it changed the way LSASS handles such requests.

The original patch, released Nov. 8 in MS16-137, was privately disclosed by researcher Laurent Gaffie, who said the bug affects all versions of Windows, from XP to Windows 10. Gaffie describe the bug in his original report:

> “This vulnerability affects both LSASS client and server and can be triggered remotely via SMBv1 and SMBv2, during the NTLM message 3 (Authenticate) message. Incoming NTLM messages via SMB are using ASN1 and DER encoding, the first ASN length field can be set to unsigned int by using 0x84.
>
> “This allows an attacker to remotely allocate a huge chunk of memory, for a message never larger than 20000 chars. The secondary trigger is to set any string fields (User, Domain, session Key, MIC, etc) with a long string (80-140 chars), leading LSASS.exe to crash.”

Gaffie said it was also possible that an attacker could leverage the crash for local privilege escalation; he published a proof-of-concept exploit once the first patch was distributed.

Core Security’s Economou, however, said he discovered that once he analyzed Gaffie’s PoC that the vulnerability was misunderstood. In a technical description published today, Economou said the fix was improperly applied.

Economou said as well that the vulnerability can also be triggered in Windows 8 and 10. To do so, he said, an attacker would have try to exhaust memory in the LSASS service rather than use a “giant” memory allocation that would fail in older versions of Windows.

“I had been able to confirm that this vulnerability can be triggered in Windows 7 and 2008 R2 by establishing several SMB connections and sending evil sizes with values like 0x1000000 (16 MB). The problem is that in the case of the latest Windows versions, it’s not possible to use this kind of sizes, because as I said before, the limit is 64KB,” Economou said. “So, the only way to trigger this vulnerability should be by producing a memory exhaustion in the LSASS service. It may be possible to do so by finding a controllable malloc in the LSASS authentication process, creating multiple connections and producing a memory exhaustion until the “LsapAllocateLsaHeap” function fails. Maybe, this memory exhaustion condition could be easily reached in local scenarios.”

This incomplete patch left users exposed for two months. During that time, Microsoft said it was not aware of any public exploits targeting this flaw. The new patch has resolved the vulnerability, he said.

“If we diff against the latest “lsasrv.dll” version (v6.1.7601.23642), we can see that the vulnerability was fixed by changing the “NegGetExpectedBufferLength” function,” Economou said. “Basically, the same 64KB packet size check used by Windows 8.1 and Windows 10 was now added to the rest of the Windows versions.”