Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

[R1] Microsoft Windows 10 lsass.exe Empty SID Lookup Handling Remote DoS

Medium

Synopsis

While using Nessus for routine auditing, a customer discovered a case where their Nessus configuration caused a credentialed scan to crash a Windows 10 host. When Nessus performed a check that queries for a blank value in a user right, Windows would crash. During evaluation of the issue, Tenable engineers determined that this was not merely a one-off case that led to a local denial of service, rather it was a more severe vulnerability that can allow a remote unauthenticated attacker to crash the host, depending on the configuration.

The issue is in the LsapLookupSids() function of the lsasrv.dll library. Inside this function, LocalAlloc() is called to allocate a block of memory based on the number of SIDs passed to the function. When zero SIDs are passed to the function, LocalAlloc() tries to allocate zero bytes, but it still returns a non-null buffer pointer, and the memory pointed by that pointer can contain non-zero bytes. Later, when the buffer is freed with LocalFree(), dynamically allocated data structures associated with it are also freed. Below shows the function checks if a pointer at offset 4 of the buffer is null and attempts to free it if it is non-null. Because the pointer at offset 4 is non-null, pointing to a location that is not allocated by LocalAlloc(), it passes the NULL pointer check, and the function tries to free both the buffer and the buffer at offset 4. Because LocalFree() is passed with an invalid memory block (i.e., 0x80000), it eventually results in a null pointer dereference.

This can be reached remotely, and a reliable remote denial of service condition exists. Depending on the configuration of the Windows 10 host, this will either require authentication or allow an unauthenticated attacker to carry out the attack. If the following configuration options are set, an attack does not require authentication:

  1. Network access: Named pipes that can be accessed anonymously -> lsarpc
  2. Network access: Restrict anonymous access to Named Pipes and Shares -> Disabled
  3. HKLM\SYSTEM\CurrentControlSet\Control\Lsa\TurnOffAnonymousBlock (DWORD) -> 1
  4. Network Access: Allow anonymous SID/Name translation -> Enabled

If any of these configuration options are not present, then the attack would require authentication.

Tenable only performed a quick evaluation of this issue before reporting it to Microsoft. Once reported, the MSRC team did more digging and determined that in addition to a remote DoS, it could lead to local privilege escalation as well, as the issue "appears to be calling free on invalid memory hence resulting in local EOP".

Solution

Microsoft has released patches for Windows 10 to address this issue. Do that Patch Tuesday thing to auto-update and mitigate this issue.

Disclosure Timeline

2015-12-09 - Vendor Informed via [email protected]
2015-12-10 - Vendor confirms receipt, assigns MSRC Case 31979 TRK:0001002465
2015-12-11 - Vendor requests NASL PoC
2015-12-13 - Tenable sends PoC and PCAP (it happened!)
2015-12-15 - Vendor confirms and reproduces issue, finishing investigation.
2016-02-17 - Ping vendor for update
2016-02-29 - Vendor confirms they can reproduce, pursuing a fix
2016-03-09 - Completed investigation, patch in next month's Patch Tuesday
2016-04-12 - Vendor releases MS16-046 / MSKB 3148538 / CVE-2016-0135, calling it LPE not DoS, credits wrong person
2016-04-12 - Ping vendor for creditee fix and clarity on impact
2016-04-13 - Vendor fixes creditee, gives a brief explanation for LPE vs Remote DoS

All information within TRA advisories is provided “as is”, without warranty of any kind, including the implied warranties of merchantability and fitness for a particular purpose, and with no guarantee of completeness, accuracy, or timeliness. Individuals and organizations are responsible for assessing the impact of any actual or potential security vulnerability.

Tenable takes product security very seriously. If you believe you have found a vulnerability in one of our products, we ask that you please work with us to quickly resolve it in order to protect customers. Tenable believes in responding quickly to such reports, maintaining communication with researchers, and providing a solution in short order.

For more details on submitting vulnerability information, please see our Vulnerability Reporting Guidelines page.

If you have questions or corrections about this advisory, please email [email protected]