CVE-2020-1015

An elevation of privilege vulnerability exists in the way that the User-Mode Power Service (UMPS) handles objects in memory, aka ‘Windows Elevation of Privilege Vulnerability’. This CVE ID is unique from CVE-2020-0934, CVE-2020-0983, CVE-2020-1009, CVE-2020-1011.

Recent assessments:

bwatters-r7 at May 18, 2020 3:48pm UTC reported:

This vulnerability came out recently and it is not only difficult to trigger, it also requires authentication and it would be unreliable and difficult to use for remote code execution. So to be clear, this is mostly just a very difficult way to sabotage a computer you’re already logged into. The top-level method to exploit this vulnerability is a race condition that results in a use-after-free bug. A write up exists here: <https://0xeb-bp.github.io/blog/2020/05/12/cve-2020-1015-analysis.html&gt; I’m super happy that the blog authors come out immediately and recognize the scope and utility of this vulnerability:

> This bug is likely not the most ideal candidate for a fully functioning and reliable exploit. Especially when taking in consideration other EoPs from the April 2020 security patches with an exploitability rating of 1.
Microsoft has classified this as a ‘2’ (<https://www.microsoft.com/en-us/msrc/exploitability-index):>
Microsoft analysis has shown that while exploit code could be created, an attacker would likely have difficulty creating the code, requiring expertise and/or sophisticated timing, and/or varied results when targeting the affected product. Moreover, Microsoft has not recently observed a trend of this type of vulnerability being actively exploited in the wild. This makes it a less attractive target for attackers. That said, customers who reviewed the security update and determined its applicability within their environment should still treat this as a material update. If they are prioritizing against other highly exploitable vulnerabilities, they could rank this lower in their deployment priority.

The exploit works because a critical code section was not properly defined during the deletion and freeing of a shared object in memory. A critical code section prevents other threads from accessing memory as it is being created and populated. Critical code sections increase runtime, but they secure objects in memory as they are being built. In this case, the critical code section takes place between the deletion and free of the object. It is possible to access the memory location after the contents are deleted, but before the contents are freed.

It is possible that an attacker can take advantage of the race condition and modify the data in the registrant structure:

struct registrant {
    // pointer to next
    next: usize,
    // pointer to prev
    prev: usize,
    // set to 1 after alloc
    count: u32, 
    // Flags
    flags: u32, 
    // handle we pass
    handle: usize, 
    // heap alloc which is size of service_name + 2 for null char
    service_name: usize,
    // sessionID
    session_id: u32,
    // unknown, might be two u16s
    unknown: u32,
}

While it may be possible to take over this structure and achieve RCE, the path is not immediately apparent, and according to Microsoft, it is likely unreliable.

Unfortunately, looking throught he PoC here (<https://github.com/0xeb-bp/cve-2020-1015/blob/master/cve_2020_1015.cpp&gt;), I am unable to locate an action that would be “known evil” to allow blue team members to flag on it.

Assessed Attacker Value: 2
Assessed Attacker Value: 2Assessed Attacker Value: 1