Low
CVE-2020-1015
CVE-2020-1015
Description
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.
Add Assessment
Technical Analysis
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 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), I am unable to locate an action that would be “known evil” to allow blue team members to flag on it.
CVSS V3 Severity and Metrics
General Information
Vendors
- microsoft
Products
- windows 10 -,
- windows 10 1607,
- windows 10 1709,
- windows 10 1803,
- windows 10 1809,
- windows 10 1903,
- windows 10 1909,
- windows 7 -,
- windows 8.1 -,
- windows rt 8.1 -,
- windows server 2008 -,
- windows server 2008 r2,
- windows server 2012 -,
- windows server 2012 r2,
- windows server 2016 -,
- windows server 2016 1803,
- windows server 2016 1903,
- windows server 2016 1909,
- windows server 2019 -
