🔒
There are new articles available, click to refresh the page.
Before yesterdayZero Day Initiative - Blog

ZDI-21-502: An Information Disclosure Bug in ISC BIND server

16 June 2021 at 15:27

Last year, we received a submission of a remote code execution vulnerability in the ISC BIND server. Later, that same anonymous researcher submitted a second bug in this popular DNS server. Similar to the first bug, it exists within the Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO) component, and its location is quite close to the previous submission. The vendor categorized this bug as low severity, so they did not issue any CVE or advisory. However, this bug is still interesting and worth a closer examination.

This vulnerability affects BIND version prior to 9.11.31 and 9.16.15. It can be triggered remotely and without authentication. It leads to out-of-bounds (OOB) read on heap memory and could allow an information disclosure to remote attackers. It might be possible to leverage this vulnerability in conjunction with the previous submission to execute arbitrary code on an affected BIND server.

The Vulnerability

The root cause is in the der_match_tag_and_length() function. It is used for matching a tag and geting the following length field from network packet. Based on the normal usage of der_get_length() in BIND, the parsed length field, length_ret, should be validated by the caller. However, der_match_tag_and_length() is one of the exceptions.

The length_ret at (1) is under control and has not yet been validated. Let's see one of the callers for der_match_tag_and_length():

The untrusted len is then used to decode the negTokenInit at (2). Many checks within decode_NegTokenInit() are based on len. Now, those checks are incorrect, and could lead to OOB access on different sub-fields, such as mechTypes, reqFlags, mechToken, etc.

The Trigger

The configuration used to reproduce this bug is the same as in the previous submission. The following screenshot is the crafted SPNEGO request for this bug.

Figure 1 - Wireshark view of the crafted SPNEGO request

Figure 1 - Wireshark view of the crafted SPNEGO request

The length_ret at (1) is controlled from offset 0xa5 as 0x91929394. The sub-field mechToken is an octet string. Its length is the crafted value 0x727374, appearing at offset 0xcd.

Upon receiving this crafted request, an OOB read is triggered within the handling of the mechToken field. The following call stack is based on BIND version 9.16.13.

The Exploitation Plan

Here’s one possible method for gaining information disclosure on an affected server.

After decode_NegTokenInit() parses the negTokenInit and its sub-fields, the loop at (3) searches for valid OIDs within the parsed mechTypes. If a valid OID is found, the server responds with an accept message at (4). Otherwise, the server responds with a reject message at (5). This gives us the ability to get the offset for some heap chunks. It’s possible this bug could be used in conjunction with the heap overflow from the previous submission, but this requires more research.

The Patch

From version 9.16.15, the ISC implementation of SPNEGO was removed from BIND 9 source code. Instead, BIND 9 now always uses the SPNEGO implementation provided by the system GSSAPI library when it is built with GSSAPI support. Because of this, the related bugs are also removed. This feature change was also applied to version 9.11.31.

You should verify you have a patched version of BIND as many OS distributions provide BIND packages that differ from the official ISC release versions. In particular, it is not uncommon for a distribution to choose a stable base version for their BIND package then selectively apply chosen patches for only those issues they think merit inclusion.  A consequence of this is that BIND may contain a fix even if the version number is different (and possibly less) than the version number in which ISC patched the vulnerability.

Conclusion

ISC BIND is the most popular DNS server on the internet. The scope of impact is quite large, especially since the vulnerability can be triggered remotely and without authentication. All are advised to update their DNS servers as soon as possible. This same anonymous researcher also reported a remote code execution bug within the handling of TKEY queries, which was also fixed recently.

We are also looking forward to seeing a reliable full exploit method at some point. As a reminder, ISC BIND is a part of our Targeted Incentive Program and could earn some big payouts for full exploits. We certainly hope to see some in the future.

You can find me on Twitter @_wmliang_, and follow the team for the latest in exploit techniques and security patches.

ZDI-21-502: An Information Disclosure Bug in ISC BIND server

The June 2021 Security Update Review

8 June 2021 at 17:31

It’s the second Tuesday of the month, which means the latest security updates from Adobe and Microsoft are here. Take a break from your regularly scheduled activities and join us as we review the details for their latest security offerings.

Adobe Patches for June 2021

For June, Adobe released 10 patches addressing 39 CVEs in Adobe Connect, Acrobat and Reader, Photoshop. Photoshop Elements, Experience Manager, Creative Cloud, RoboHelp, Premiere Elements, Animate, and After Effects. A total of nine of these bugs came through the ZDI program. The two patches that stand out are the fixes for Reader and After Effects. In the case of Adobe Reader, the Critical-rated CVEs could allow code execution if an attacker can convince a user to open a specially crafted PDF file with an affected version of Reader. For the use-after-free (UAF) bugs reported through our program, the specific flaw exists within the handling of AcroForm fields. The issue results from the lack of validating the existence of an object prior to performing operations on the object. The update for After Effects fixes a large mix of Critical- to Moderate-rated bugs. The worst of these could allow code execution at the level of the logged-on user.

None of the bugs fixed this month by Adobe are listed as publicly known or under active attack at the time of release.

Microsoft Patches for June 2021

For June, Microsoft released patches for 50 CVEs in Microsoft Windows, .NET Core and Visual Studio, Microsoft Office, Microsoft Edge (Chromium-based and EdgeHTML), SharePoint Server, Hyper-V, Visual Studio Code - Kubernetes Tools, Windows HTML Platform, and Windows Remote Desktop. A total of eight of these bugs came through the ZDI program. Of these 50 bugs, five are rated Critical and 45 are rated Important in severity. According to Microsoft, six of these bugs are currently under active attack while three are publicly known at the time of release.

Let’s take a closer look at some of the more interesting updates for this month, starting with some of the bugs listed as under active attack:

-       CVE-2021-33742 - Windows MSHTML Platform Remote Code Execution Vulnerability
This bug could allow an attacker to execute code on a target system if a user views specially crafted web content. Since the vulnerability is in the Trident (MSHTML) engine itself, many different applications are impacted – not just Internet Explorer. It’s not clear how widespread the active attacks are, but considering the vulnerability impacts all supported Windows versions, this should be at the top of your test and deploy list.

-       CVE-2021-31199/CVE-2021-31201 - Microsoft Enhanced Cryptographic Provider Elevation of Privilege Vulnerability
These two bugs are linked to the Adobe Reader bug listed as under active attack last month (CVE-2021-28550). It’s common to see privilege escalation paired with code execution bugs, and it seems these two vulnerabilities were the privilege escalation part of those exploits. It is a bit unusual to see a delay between patch availability between the different parts of an active attack, but good to see these holes now getting closed.

-       CVE-2021-31956 - Windows NTFS Elevation of Privilege Vulnerability
This is another of the bugs listed as under active attack this month. This was reported by the same researcher who found CVE-2021-31955, an information disclosure bug also listed as under active attack. It's possible these bugs were used in conjunction, as that is a common technique - use a memory leak to get the address needed to escalate privileges. These bugs are important on their own and could be even worse when combined. Definitely prioritize the testing and deployment of these patches.

-       CVE-2021-31962 - Kerberos AppContainer Security Feature Bypass Vulnerability
This bug allows an attacker to bypass Kerberos authentication and potentially authenticate to an arbitrary service principal name (SPN). This vulnerability earns the highest CVSS for June at 9.4. This could allow an attacker to potentially bypass authentication to access any service that is accessed via an SPN. Given that SPN authentication is crucial to security in Kerberos deployments, this patch should be given highest priority.

Here’s the full list of CVEs released by Microsoft for June 2021:

CVE Title Severity CVSS Public Exploited Type
CVE-2021-33742 Windows MSHTML Platform Remote Code Execution Vulnerability Critical 7.5 Yes Yes RCE
CVE-2021-33739 Microsoft DWM Core Library Elevation of Privilege Vulnerability Important 8.4 Yes Yes EoP
CVE-2021-31199 Microsoft Enhanced Cryptographic Provider Elevation of Privilege Vulnerability Important 5.2 No Yes EoP
CVE-2021-31201 Microsoft Enhanced Cryptographic Provider Elevation of Privilege Vulnerability Important 5.2 No Yes EoP
CVE-2021-31955 Windows Kernel Information Disclosure Vulnerability Important 5.5 No Yes Info
CVE-2021-31956 Windows NTFS Elevation of Privilege Vulnerability Important 7.8 No Yes EoP
CVE-2021-31968 Windows Remote Desktop Services Denial of Service Vulnerability Important 7.5 Yes No DoS
CVE-2021-31985 Microsoft Defender Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2021-31963 Microsoft SharePoint Server Remote Code Execution Vulnerability Critical 7.1 No No RCE
CVE-2021-31959 Scripting Engine Memory Corruption Vulnerability Critical 6.4 No No RCE
CVE-2021-31967 VP9 Video Extensions Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2021-31957 .NET Core and Visual Studio Denial of Service Vulnerability Important 5.9 No No DoS
CVE-2021-31944 3D Viewer Information Disclosure Vulnerability Important 5 No No Info
CVE-2021-31942 3D Viewer Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31943 3D Viewer Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31972 Event Tracing for Windows Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-31962 Kerberos AppContainer Security Feature Bypass Vulnerability Important 9.4 No No SFB
CVE-2021-31978 Microsoft Defender Denial of Service Vulnerability Important 5.5 No No DoS
CVE-2021-33741 Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability Important 8.2 No No EoP
CVE-2021-31939 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31980 Microsoft Intune Management Extension Remote Code Execution Vulnerability Important 8.1 No No RCE
CVE-2021-31940 Microsoft Office Graphics Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31941 Microsoft Office Graphics Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31949 Microsoft Outlook Remote Code Execution Vulnerability Important 6.7 No No RCE
CVE-2021-31965 Microsoft SharePoint Server Information Disclosure Vulnerability Important 5.7 No No Info
CVE-2021-26420 Microsoft SharePoint Server Remote Code Execution Vulnerability Important 7.1 No No RCE
CVE-2021-31966 Microsoft SharePoint Server Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2021-31948 Microsoft SharePoint Server Spoofing Vulnerability Important 7.6 No No Spoofing
CVE-2021-31950 Microsoft SharePoint Server Spoofing Vulnerability Important 7.6 No No Spoofing
CVE-2021-31964 Microsoft SharePoint Server Spoofing Vulnerability Important 7.6 No No Spoofing
CVE-2021-31938 Microsoft VsCode Kubernetes Tools Extension Elevation of Privilege Vulnerability Important 7.3 No No EoP
CVE-2021-31945 Paint 3D Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31946 Paint 3D Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31983 Paint 3D Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31974 Server for NFS Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2021-31975 Server for NFS Information Disclosure Vulnerability Important 7.5 No No Info
CVE-2021-31976 Server for NFS Information Disclosure Vulnerability Important 7.5 No No Info
CVE-2021-31960 Windows Bind Filter Driver Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-31969 Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31954 Windows Common Log File System Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-26414 Windows DCOM Server Security Feature Bypass Important 4.8 No No SFB
CVE-2021-31953 Windows Filter Manager Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31973 Windows GPSVC Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31971 Windows HTML Platform Security Feature Bypass Vulnerability Important 6.8 No No SFB
CVE-2021-31977 Windows Hyper-V Denial of Service Vulnerability Important 8.6 No No DoS
CVE-2021-31951 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31952 Windows Kernel-Mode Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31958 Windows NTLM Elevation of Privilege Vulnerability Important 7.5 No No EoP
CVE-2021-1675 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31970 Windows TCP/IP Driver Security Feature Bypass Vulnerability Important 5.5 No No SFB

Looking at the remaining Critical-rated bugs, the update for Defender stands out even though you likely won’t need to take any action. Microsoft regularly updates the Malware Protection Engine, so if your system is connected to the Internet, it should have already received an update. You should still verify the version and manually apply the update if needed. Similarly, the update for the VP9 codecs should be automatically updated through the Microsoft store. Again, if you’re in a disconnected environment, you’ll need to manually apply the patch. The remaining Critical-rated bugs include a browse-and-own bug in the scripting engine and a remote code execution vulnerability in SharePoint. The SharePoint bug requires no user interaction but does require some level of privilege. The attack complexity is listed as high, but considering the target, attackers are likely to do everything possible to turn this into a practical exploit.

Moving on to the Important-rated updates, there are a couple of SharePoint code execution bugs here as well. One of these came through the ZDI program, and we’ll post more details about it in the near future. We blogged about a similar bug last week, so you can check that out in the meantime. There are several patches impacting Office components with the most notable being the update for Outlook. Fortunately, the Preview Pane is not affected. An attacker would need to convince someone to open a specially crafted file with an affected version of Outlook. Those using Microsoft Intune for device management should ensure they apply the patch as soon as possible. While the attack scenario is not defined, it does not require authentication or user interaction. If you use Intune, I recommend treating this patch as Critical and deploy it quickly. The Important-rated code execution patches are rounded out by a couple of patches for the 3D Viewer and Paint 3D. One of the Paint bugs was reported by ZDI researcher Mat Powell and exists within the parsing of STL files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated data structure.

There are 10 additional elevation of privilege (EoP) bugs receiving patches this month beyond those previously mentioned. The bug fixed by the Desktop Windows Manager (DWM) patch is also listed as publicly known and under active attack. Again, it’s not clear how widespread these attacks are, but they are likely more targeted at this point. The update for the Chromium-based Edge actually went live on Friday, June 4. It’s not clear how this bug is an EoP rather than code execution, but either way, user interaction is required. The other EoPs addressed this month require the attacker to run their code on an affected system to escalate privileges. Several Windows components are impacted by these bugs, including the Windows Kernel and Microsoft’s Kubernetes tools.

There are seven patches fixing information disclosure bugs this month, with the vulnerability for the Windows Kernel listed as under active attack. For the most part, all of these bugs only lead to leaks consisting of unspecified memory contents. The one exception is the info leak in SharePoint that could lead to exposing Personally Identifiable Information (PII).

There are five patches fixing denial-of-service (DoS) bugs in the release. The most notable affected components are Hyper-V and Windows Defender. Again, you should have already received the Defender update. Even if you have Defender disabled, a vulnerability scanner may detect systems as vulnerable due to the presence of the impacted files. However, Microsoft states systems with Defender disabled are not in a “vulnerable state.” The DoS bug fixed in the Windows Remote Desktop Protocol is listed as publicly known, but it’s not clear what public information is available.

Four security feature bypasses are fixed in this month’s release, including the previously mentioned Kerberos bypass. The update for Windows DCOM requires special attention. The patch doesn’t automatically fix the vulnerability. Instead, it provides enterprises the ability to enable hardening for protections from the bug. Microsoft plans another release in Q4 2021 that enables the protections by default while allowing the hardened to be disabled via the registry. In late 2021 or early 2022, the ability to disable the protections will be removed. It seems Microsoft anticipates some application compatibility problems may arise from this fix, so definitely test this update thoroughly.

This month’s release is rounded out by three patches to address spoofing bugs in SharePoint Server. As per usual, the servicing stack advisory (ADV990001) was revised for versions of Windows 10 and Server 2019. No new advisories were released this month.

Looking Ahead

The next Patch Tuesday falls on July 13, and we’ll return with details and patch analysis then. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

The June 2021 Security Update Review

CVE-2021-31181: Microsoft SharePoint WebPart Interpretation Conflict Remote Code Execution Vulnerability

In May of 2021, Microsoft released a patch to correct CVE-2021-31181 – a remote code execution bug in the supported versions of Microsoft SharePoint Server. This bug was reported to the ZDI program by an anonymous researcher and is also known as ZDI-21-573. This blog takes a deeper look at the root cause of this vulnerability.

Before this patch being made available, this vulnerability could be used by an authenticated user to execute arbitrary code on the server in the context of the service account of the SharePoint web application. For a successful attack, the attacker must have SPBasePermissions.ManageLists permissions on any SharePoint site. By default, any authenticated user can create their own site where they have the necessary permission.   

The Vulnerability

This attack is possible due to insufficient validation of user input in the EditingPageParser.VerifyControlOnSafeList() method. This method verifies user input against a list of unsafe controls and should raise an exception if any control is not marked as safe by the SafeControl elements as specified in web.config.

A good example of an unsafe control that is forbidden by SharePoint is System.Web.UI.WebControls.XmlDataSource. This control is dangerous because it would allow an attacker to get information from an arbitrary XML file on the server. As we will see, this could be used not only for information disclosure but even for code execution.

We can see that it is marked as unsafe via a SafeControl element in web.config:

Because of this, an attacker should not be able to instantiate this control. However, we will see how we can bypass verification in EditingPageParser.VerifyControlOnSafeList().

EditingPageParser.ParseStringInternal() parses user input (dscXml) and populates hashtable with information from Register directives and hashtable2 with values from tags that represent server controls. In the next step, it tries to create a Type object for each element from hashtable2 and checks it against an allowed list of SafeControls. However, it will ignore the tag of the server control if the Type cannot be resolved. Normally, this would not create a hazard. If a Type cannot be resolved at the verification stage, then it should similarly fail to resolve later during the actual processing of markup. However, an inconsistency between the code in EditingPageParser and TemplateParser breaks this assumption.

Let’s look closer at how the values in hashtable are populated, and let’s pay attention to the namespace attribute of the Register directive:

The value of the namespace attribute will be stored in triplet.First. Let’s suppose that we have Namespace="System.Web.UI.WebControls " (note the trailing space) in our Register directive, and a tag named XmlDataSource. As you can see, there are no Trim() calls for the namespace attribute. Due to the trailing space, VerifyControlOnSafeList will not be able to resolve the Type System.Web.UI.WebControls .XmlDataSource and consequently it will not be blocked. Later, though, during actual processing of the Register directive, the following code executes:

At this stage, the Namespace will be trimmed and a Type for System.Web.UI.WebControls.XmlDataSource will be successfully resolved. This means the unsafe control will be processed by the server.

For our attack, we will use the WebPartPagesWebService.RenderWebPartForEdit webapi method. It is accessible via the /_vti_bin/WebPartPages.asmx endpoint. It takes ASPX markup as an input, verifies it using EditingPageParser.VerifyControlOnSafeList, and, if there are no unsafe elements, processes the markup in Design mode. The resulting HTML will be returned to the web client.

We will use the WebPart Microsoft.SharePoint.WebPartPage.XsltListFormWebPart with our unsafe XmlDataSource, specifying a simple XSL transformation to copy the result verbatim to our output. In this way we can obtain the contents of an arbitrary XML file from the server. We choose to disclose the contents of web.config. This will provide us with the validation key needed to forge a VIEWSTATE parameter, providing a path to remote code execution.

To proceed, we will also need to provide the Title of any existing SPList from the current site, as well as the site’s webID. These can be obtained easily. We will see how to do this in the PoC section.

Here is an example of a RenderWebPartForEdit request:

We can use the machinekey section from web.config to create a valid VIEWSTATE parameter that causes an arbitrary OS command to be executed when the ViewState is deserialized on the server.

Proof of Concept

For this demonstration, we use Microsoft SharePoint Server 2019 installed with all default options on Windows Server 2019 Datacenter. The server’s computer name is sp2019.contoso.lab and it is a member of the contoso.lab domain. The domain controller is a separate virtual machine. It has been updated to January 2021 Patch (Version 16.0.10370.20001‎) and a couple of users have been added, including “user2” as a regular, unprivileged user.

On the attacker side, we need any supported Web Browser, our PoC application for sending SOAP requests to the server, and the ysoserial.net tool. For this demonstration, we are using Firefox as our browser.

Getting Remote Code Execution

Let’s begin by visiting our SharePoint Server and authenticating as “user2”.

Picture1.png

Let’s create a site so that we will be the owner and have all permissions.

Click on “SharePoint” on the top panel:

Picture2.png

Now click the “+ Create Site” link:

Picture3.png

Choose Team Site.

Choose a name for the new site. In this example, it is ts01.

Picture4.png

Click “Finish” and the new site will be created:

Picture5.png

Now let’s get the webId for the site. This can be done with a request to /_api/web/id :

Picture6.png

In this example, it is 6e7040c8-0338-4448-914d-a7061e0fc347.

We also need the title of any existing SPlist in the current site. The “Documents” SPlist is available on most sites, but we can use any item from the /_layouts/15/viewlsts.aspx page:

Picture7.png

Now we use our PoC to send a request to the server. We need to provide the base URL for our site, valid user credentials, the title of an SPList, and the webId. In our case:

>PoC.exe http://sp2019/sites/ts01/ user2 [email protected] contoso "Documents" "{6e7040c8-0338-4448-914d-a7061e0fc347}"

If this step successful, we will get the machineKey section of web.config:

Picture9.png

For our RCE attack, we need the value of validationKey. In this example it is:

validationKey=”FAB45BC67E06323C48951DA2AEAF077D8786291E2748330F03B6601F09523B79”

We can also see the algorithm: validation="HMACSHA256"

Using this information, we can proceed to get remote code execution. Before the actual attack, let’s go to the target SharePoint Server and open C:\windows\temp folder:

Picture10.png

Note that there is no PoC_SPRCE01.txt file yet.

Now let’s go back to the attacker machine. We need to collect one more piece of information, which is the value of __VIEWSTATEGENERATOR. We can get this by browsing to the success.aspx page on our site. In this example, the URL is http://sp2019/sites/ts01/_layouts/15/success.aspx:

Picture11.png

Viewing the source code, we can find the value of __VIEWSTATEGENERATOR:

Picture12.png

In this example it is AF878507.

In summary, the values needed to forge a VIEWSTATE are as follows:

__VIEWSTATEGENERATOR=AF878507 validationKey=FAB45BC67E06323C48951DA2AEAF077D8786291E2748330F03B6601F09523B79 validationAlg=HMACSHA256

We provide these values on the command line of ysoserial, as follows:

>ysoserial.exe -p ViewState -g TypeConfuseDelegate -c "echo RCE > c:/windows/temp/PoC_SPRCE01.txt" --generator="AF878507" --validationkey="FAB45BC67E06323C48951DA2AEAF077D8786291E2748330F03B6601F09523B79" --validationalg="HMACSHA256" --islegacy --minify

Picture13.png

The result is a valid VIEWSTATE.

We need to URL-encode this ViewState and send it as a __VIEWSTATE parameter to our server. For example, this can be done by composing a URL with a __VIEWSTATE query string parameter, as follows:

Browsing to this URL, an error page is returned.

Picture14.png

However, when we check the C:\Windows\temp folder on the SharePoint server:

Picture15.png

Our target file was successfully created, demonstrating that we achieved code execution. In the same way, an attacker can execute any OS command in the context of the SharePoint web application.

Conclusion

Microsoft patched this in May and assigned identifier CVE-2021-31181, with a CVSS score of 8.8. SharePoint continues to be an attractive target for researchers and attackers alike, and several SharePoint-related disclosures are currently in our Upcoming queue. Stay tuned to this blog for details about those bugs once they are disclosed.

Until then, follow the team for the latest in exploit techniques and security patches.

CVE-2021-31181: Microsoft SharePoint WebPart Interpretation Conflict Remote Code Execution Vulnerability

CVE-2021-31440: An Incorrect Bounds Calculation in the Linux Kernel eBPF Verifier

27 May 2021 at 16:00

In April 2021, the ZDI received a Linux kernel submission that turned out to be an incorrect bounds calculation bug in the extended Berkeley Packet Filter (eBPF) verifier. This bug was submitted to the program by Manfred Paul (@_manfp) of the RedRocket CTF team (@redrocket_ctf). Manfred Paul had successfully exploited two other eBPF verifier bugs in Pwn2Own 2020 and 2021 respectively.

This particular bug bypassed the eBPF verification and resulted in an out-of-bounds (OOB) access in the Linux kernel. The researcher exploited this bug and demonstrated a Kubernetes container escape. The patch was recently released as CVE-2021-31440 . Linux kernel versions from 5.7 and on were affected.

The Vulnerability

After CVE-2020-8835, one significant change was added to the verifier, namely 32-bit bound tracking. For the unsigned and signed minimum and maximum bounds, the 32-bit bounds u32_min_value, u32_max_value, s32_min_value and s32_max_value additionally and exclusively apply to the lower 32 bits of each tracked register.

However, a very similar mistake was reintroduced in __reg_combine_64_into_32(). This function uses the known bounds on a 64-bit register to infer bounds for the register’s lower 32 bits.

If the smin_value and smax_valueat (1) are both within in the range of signed 32-bit integers, the 32-bit signed bounds are updated accordingly. In all other cases the 32-bit signed bounds remain in the “unbounded” state. This logic is proper. However, in the corresponding logic for unsigned bounds, the checks on umin_value and umax_value are performed separately at (2) and (3). This logic is incorrect. For example, consider what happens if a register has umin_value = 1 and umax_value = 1<<32. data-preserve-html-node="true" At (2), the verifier will set u32_min_value to 1. At runtime, the register’s actual value can be 1<<32, data-preserve-html-node="true" making the lower 32 bits equal to 0. This violates the correctness of the register’s bounds, which indicate that the minimum value of the lower 32 bits is 1.

Notably, there was already a fix for the case of signed bounds at (1) from December 2020, but it missed the case of unsigned bounds.

Exploitation

The bug can be exploited as follows. Begin with these eBPF instructions:

These instructions set BPF_REG_2 as 1<<32. data-preserve-html-node="true" The two successive NEG instructions cause the verifier to lose track of all bounds for BPF_REG_2, while keeping its runtime value unchanged.

Next:

This conditional branch tests whether BPF_REG_2 is greater than or equal to 1. For the true side of the branch, the verifier sets the register’s umin_value to 1. Furthermore, the verifier calls __reg_combine_64_into_32(), which sets u32_min_value to 1 as well. This is the branch that will be followed at runtime.

Next:

This second conditional branch tests whether BPF_REG_2 is less than or equal to 1, so for the true side of the branch, the verifier sets the register’s u32_max_value to 1. At this point, for the true path, u32_max_value and u32_min_value are both set to 1, meaning that the verifier believes that the value of the lower 32 bits is known to be exactly 1. Recall, though, that the runtime value of BPF_REG_2 has been set to 1<<32 data-preserve-html-node="true" from the beginning, so that the true value of the lower 32 bits is 0. Thus, the verifier has inferred incorrect bounds for the register.

Finally, we can use this to produce an out-of-bounds access:

The BPF_MOV32_REG extends the wrong knowledge to the whole 64-bit register. After two ALU (arithmetic) operations, the register value is believed by the verifier to be 0, but is actually 1. This situation is the same as in the exploit steps in CVE-2020-8835, and the later steps of that exploit can be reused here. The out-of-bounds read/write access is achieved by using the wrongly bounded register, followed by an arbitrary read/write, and privilege escalation to root.

Demonstrating Exploitation

Since the Kubernetes container by default allows access to all system calls, a container escape can be achieved by exploiting this bug. The researcher set the current UID and GID to 0 and obtained the CAP_SYS_MODULE capability. This allowed the program to load an arbitrary kernel module outside of the container.

Conclusion

The eBPF module is still a good place for kernel bug hunting. It was also recently introduced to Windows. This attack surface is usable not only for local privilege escalation but also for container escapes. Those running systems affected by this bug should apply this mitigation, or even better, upgrade the kernel to an unaffected version. Thanks again to Manfred Paul(@_manfp) of the RedRocket CTF team (@redrocket_ctf) for submitting this bug. He’s submitted a few other reports to the program, and each has been great. We hope to see more from him in the future.

You can find me on Twitter @_wmliang_, and follow the team for the latest in exploit techniques and security patches.

CVE-2021-31440: An Incorrect Bounds Calculation in the Linux Kernel eBPF Verifier

CVE-2021-22909- Digging into a Ubiquiti Firmware Update bug

25 May 2021 at 16:12

Back In February, Ubiquiti released a new firmware update for the Ubiquiti EdgeRouter, fixing CVE-2021-22909/ZDI-21-601. The vulnerability lies in the firmware update procedure and allows a man-in-the-middle (MiTM) attacker to execute code as root on the device by serving a malicious firmware image when the system performs an automatic firmware update. The vulnerability was discovered and reported to the ZDI program by the researcher known as awxylitol.

This vulnerability may sound contrived; a bad actor gives bad firmware to the device and bad things happen. However, insecure download vulnerabilities have been the backbone of multiple Pwn2Own winning entries in the router category since its inception. The impact of this vulnerability is quite nuanced and worthy of further discussion.

How exactly does the router perform a firmware update?

According to Ubiquiti documentation, the new templated operational command add system image can be used to update the firmware of the router through the command line interface (CLI). A templated operational command allows the user to quickly modify the operational state of the router without fiddling with complex command-line parameters. This simplifies the process for day-to-day operations and minimizes user errors. I am sure we have all heard of horror stories of system administrators who accidentally deleted critical files, locked themselves out of equipment that is far away from civilization, and so forth. Templated commands attempt to mitigate these issues.

The templating system used by the Ubiquiti EdgeRouter is provided by the vyatta-op package. The command add system image is defined in the /opt/vyatta/share/vyatta-op/templates/add/system/image/node.def file.

By running this operational command, the user is effectively invoking the ubnt-fw-latest script with the --upgrade option. This option causes the ubnt-fw-latest script to run the upgrade_firmware() function, which will check with a Ubiquiti update server to get information about the latest firmware release, including the firmware download URLs.

The function proceeds to parse and compare the results from the server with the current firmware version. If an update is available, the script will invoke ubnt-upgrade to fetch the firmware from the fw-download.ubnt.com domain provided by the upgrade server. It will then perform the actual firmware upgrade.

The Bug - ZDI-21-601

The issue lies in the way the /usr/bin/ubnt-upgrade bash script downloads the firmware. The get_tar_by_url() function uses the curl command to perform the fetch. However, the developers specified the -k option (also known as the –insecure option), which disables certificate verification for TLS connections.

Since /usr/sbin/ubnt-upgrade does not check for the validity of the certificate, an attacker can use a self-signed certificate to spoof the fw-download.ubnt.com domain without triggering any warnings or complaints on the device to alert the user. This vulnerability significantly reduces the skill barrier needed to launch a successful attack.

To exploit this vulnerability, the attacker can modify an existing EdgeRouter firmware image and fix up the checksum contained in the file. In the submitted proof-of-concept, the researcher modified the rc.local file to connect back to the attacker with a reverse shell. A reboot is part of the upgrade process, triggering the rc.local script.

Conclusion

If an attacker inserts themselves as MiTM, they can then impersonate the `fw-download.ubnt.com` domain controlled by Ubiquiti. However, to successfully serve up malicious firmware from this domain, the attackers would normally need to obtain a valid certificate with private key for the domain. To proceed, the attackers would probably need to hack into Ubiquiti or convince a trusted certificate authority (CA) to issue the attackers a certificate for the Ubiquiti domain, which is no insignificant feat. However, due to this bug, there is no need to obtain the certificate.

The heart of the problem is the lack of authentication on the firmware binary. The function of a secure communications channel is to provide confidentiality, integrity, and authentication. In TLS, encryption provides confidentiality, a message digest (or AEAD in the case of TLS 1.3) provides integrity, and certificate verification provides authentication. Without the verification of certificates, clients are foregoing authentication in the communications channel. In this scenario, it is possible for the client to be speaking to a malicious actor “securely”, as it were.

It should also be noted how checksums are not replacements for cryptographic signatures. Checksums can help to detect random errors in transmission but do not provide hard proof of data authenticity.

One final consideration is the possibility that a vendor's website could become compromised. In that case, the firmware along with its associated hash could both be replaced with malicious versions. This situation can be mitigated only by applying a cryptographic signature to the firmware file itself. Perhaps Ubiquity will make the switch to signing their firmware binaries cryptographically, which would improve the overall security of its customers.

Ubiquity addressed this bug in their v2.0.9-hotfix.1 security update by removing the -k (--insecure) flag from the templated command.

This was the first submission to the program from awxylitol, and we hope to see more research from them in the future. Until then, you can find me on Twitter @TrendyTofu, and follow the team for the latest in exploit techniques and security patches.

Footnote

Cautious users of the EdgeRouter seeking advice on how to upgrade the device properly should avoid the use of automatic upgrade feature for this update. They may want to download the firmware file manually from a browser and verify the hashes of the firmware before performing a manual upgrade by uploading the firmware file to the device through the web interface.

CVE-2021-22909- Digging into a Ubiquiti Firmware Update bug

CVE-2021-31166: A Wormable Code Execution Bug in HTTP.sys

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Kc Udonsi and Yazhi Wang of the Trend Micro Research Team detail a recent code execution vulnerability in the Microsoft Internet Information Services (IIS) for Windows. The bug was originally discovered by the Microsoft Platform Security & Vulnerability Research team. The following is a portion of their write-up covering CVE-2021-31166, with a few minimal modifications.


The Internet Information Services (IIS) for Windows Server is a flexible, scalable, secure, and manageable web server for hosting static as well as dynamic content on the web. IIS supports various web technologies including HTML, ASP, ASP.NET, JSP, PHP, and CGI. IIS features an HTTP listener as part of the networking subsystem of Windows. This functionality is implemented as a kernel-mode device driver called the HTTP Protocol Stack (HTTP.sys). This driver is responsible for parsing HTTP requests and crafting responses to the clients.

Note that the driver http.sys is a mature technology that provides the robustness, security, and scalability of a full-featured web server. It is also used by Windows Remote Management WS-Management (WinRM) and Web Services for Devices (WSD) associated with Network Discovery. It could also be used by any other web servers that need to be exposed to the internet without using IIS. Therefore this vulnerability is reachable via any system utilizing http.sys.

HTTP is a request/response protocol described in RFCs 7230 - 7237 and other RFCs. A request is sent by a client to a server, which in turn sends a response back to the client. An HTTP request consists of a request line, various headers, an empty line, and an optional message body:

where CRLF represents the new line sequence Carriage Return (CR) followed by Line Feed (LF) and SP represents a space character. Parameters can be passed from the client to the server as name-value pairs in either the Request-URI or in the message-body, depending on the Method used and Content-Type header. For example, a simple HTTP request passing a parameter named “param” with value “1”, using the POST method might look like this:

If there is more than one parameter/value pair, they are encoded as &-delimited name=value pairs:

Of relevance to this vulnerability is the HTTP request header “Accept-Encoding”. This header advertises to a web server compression algorithm it can understand. The server selects a proposal from advertised choices, uses it, and informs the client of its decision using the HTTP response header “Content-Encoding”.

The advertised compression algorithms are known as content-coding. The content-codings could be specified in the order of preference with qvalue weighting which describes the order of priority of values in a comma-separated list.

The “Accept-Encoding” HTTP header Field-Value has the following format:

Example "Accept-Encoding" headers are as follows:

where the Field-Value strings are gzip, identity, *, deflate, gzip;q=1.0, *;q=0.5
In HTTP.sys the routines HTTP!UlAcceptEncodingHeaderHandler, HTTP!UlpParseAcceptEncoding and HTTP!

UlpParseContentCoding are responsible for parsing the "Accept-Encoding" HTTP request header.

Upon receiving an HTTP request, the routine HTTP!UlAcceptEncodingHeaderHandler is invoked for each “Accept-Encoding” header present in the request headers. This routine then invokes HTTP!UlpParseAcceptEncoding on the “Accept-Encoding” HTTP header Field-Value.

The HTTP!UlpParseAcceptEncoding routine walks the Field-Value string by invoking HTTP! UlpParseContentCoding. The HTTP!UlpParseContentCoding routine, among other functionalities, returns a reference to the next content-coding string within the Field-Value for the next iteration and determines if the current reference into the Field-Value string is either an unknown, a supported, or an invalid content-coding string.

A valid content-coding string is a well-formatted string according to the “Accept-Encoding” HTTP header Field- Value format illustrated above. It can either be unknown or supported. A supported content-coding string is a valid content-coding string specifying a compression algorithm supported by IIS.

In the following “Accept-Encoding” HTTP request header example:

       Accept-Encoding: gzip, aaaa, bbbb;

“gzip” is a supported content-coding string, “aaaa” is an unknown content-coding string, and finally “bbbb;” is an invalid content-coding string because it is improperly formatted.

During the processing of the Field-Value string, the routine HTTP!UlpParseAcceptEncoding maintains a circular doubly linked list of unknown content-codings. However, the presence of an invalid content-coding string will result in an HTTP Bad Request server response.

A circular doubly linked list is a data structure that exhibits properties of both doubly linked lists and circular linked lists. In a circular doubly linked list, two consecutive nodes are connected by previous and next links. Distinctively, the last node connects to the first node by its next link and the first node connects to the last node by its previous link. If the circular doubly linked list contains only one node, the next and previous links connect to itself.

A remote code execution vulnerability exists in the HTTP Protocol Stack for Microsoft Internet Information Services implemented in http.sys. The vulnerability is due to a design flaw in the maintenance of a circular doubly linked list in UlpParseAcceptEncoding.

In the routine HTTP!UlpParseAcceptEncoding, the list of unknown content-codings is initialized to contain just a root node. This root node resides in the function's stack memory region. While processing the Field-Value string, subsequent nodes are allocated for unknown content-codings in the paged memory pool (i.e virtual memory addresses that can be paged in and out of the system). In the event that HTTP!UlpParseAcceptEncoding failed to acquire memory within the paged pool or that HTTP!UlpParseContentCoding determined that a content-coding string is invalid, nodes allocated within the paged pool will be freed and in all but one case, immediately by the routine HTTP!UlFreeUnknownCodingList via the root node residing on the function's stack memory region (original root node).

The routine HTTP!UlFreeUnknownCodingList unlinks and frees nodes in the order they were added to the circular doubly linked list. It begins with the first non-root node and will perform various integrity checks on the node to be deleted effectively in a bid to determine if the circular doubly linked list has been corrupted. If the checks succeed, the node will be freed otherwise the routine aborts with __fastfail leading to a kernel crash.

After fully parsing all content-codings specified in the Field-Value string, if the list of unknown content-codings contains additional nodes, the additional nodes are unlinked from the root node that resides on the function's stack memory region and relinked to a root node in an internal structure. During unlinking, HTTP! UlpParseAcceptEncoding failed to reset the next and previous links of the initial root node such that they connect to itself. Hence, the next and previous links of the original root node still connected to the now migrated nodes.

An attacker could craft an “Accept-Encoding” HTTP request header such that the unknown content-coding list is migrated to the internal structure but also passed to HTTP!UlFreeUnknownCodingList via the original root node as a result of an invalid content-coding string passed to HTTP!UlpParseContentCoding. This scenario occurs because a special error code 0x0c0000225 is returned by HTTP!UlpParseContentCoding when the only non-tab, non-space character in the content-coding string currently being processed is the comma character (,). This error code does not result in the immediate freeing of the unknown content-coding list in HTTP!UlpParseAcceptEncoding. The unknown content-coding list will still be migrated to the internal structure before the error is handled.

Since the original root node's next and previous links still connect to the migrated nodes, the free operation will be performed for the first added node connected by the original root's next link because the integrity checks performed on the node will succeed. However, since the first node is connected to the internal structure’s root node via its previous link, the routine HTTP!UlFreeUnknownCodingList unlinks this node from the internal structure root node instead of the passed in the original root node. On the next iteration, the same node is to be freed again since the routine parses the passed-in initial root node. This time, a non-crashing use-after-free occurs, the integrity checks are performed again on the node but this time they fail. This is because when the routine checks the node connected to the previous link of the already deleted and unlinked node, it finds the internal structure's root node. However, when it checks the node connected to the internal structure root node's next link, it finds a node different from the one specified for freeing. The routine HTTP!UlFreeUnknownCodingList aborts via __fastfail with FAST_FAIL_CORRUPT_LIST_ENTRY. This results in a blue screen of death (BSOD) with stopcode KERNEL SECURITY CHECK FAILURE.

A remote, unauthenticated attacker can exploit this vulnerability by sending a crafted Accept-Encoding HTTP header in a web request to the target system. Successful exploitation of this vulnerability can result in denial-of-service conditions or code execution with kernel privileges in the worst case.

Conclusion

Microsoft addressed this vulnerability in the May patch release cycle. They recommend prioritizing the patching of affected servers.

Special thanks to Kc Udonsi and Yazhi Wang of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit http://go.trendmicro.com/tis/.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the ZDI team for the latest in exploit techniques and security patches.

CVE-2021-31166: A Wormable Code Execution Bug in HTTP.sys

The May 2021 Security Update Review

11 May 2021 at 17:26

It’s the second Tuesday of the month, which means the latest security updates from Adobe and Microsoft are released. Take a break from your regularly scheduled activities and join us as we review the details for their latest security offerings.

Adobe Patches for May 2021

For May, Adobe released 12 patches addressing 44 CVEs in Experience Manager, InDesign, Illustrator, InCopy, Adobe Genuine Service, Acrobat and Reader, Magento, Creative Cloud Desktop, Media Encoder, After Effects, Medium, and Animate. A total of five of these bugs came through the ZDI program.

The update for Acrobat and Reader should be given the highest priority. One of the 14 CVEs fixed by this patch is listed as being currently used in the wild. The bug (CVE-2021-28550) is one of three use after free (UAF) bugs addressed by this patch. These and other vulnerabilities could lead to code execution if someone were to open a specially crafted PDF with an affected version of Acrobat or Reader. The update for InDesign also stands out. These bugs result from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated structure. An attacker can leverage this vulnerability to execute code in the context of the current process.

Beyond the one Reader bug, none of the other vulnerabilities patched by Adobe this month are listed as publicly known or under active attack at the time of release.

Microsoft Patches for May 2021

For May, Microsoft released patches for 55 CVEs in Microsoft Windows, .NET Core and Visual Studio, Internet Explorer (IE), Microsoft Office, SharePoint Server, Open-Source Software, Hyper-V, Skype for Business and Microsoft Lync, and Exchange Server. A total of 13 of these bugs came through the ZDI program. Of these 55 bugs, four are rated as Critical, 50 are rated as Important, and one is listed as Moderate in severity. According to Microsoft, three of these bugs are publicly known but none are listed as under active exploit at the time of release.

Let’s take a closer look at some of the more interesting updates for this month, starting with a bug sure to garner a lot of attention:

-       CVE-2021-31166 - HTTP Protocol Stack Remote Code Execution Vulnerability
This patch corrects a bug that could allow an unauthenticated attacker to remotely execute code as kernel. An attacker would simply need to send a specially crafted packet to an affected server. That makes this bug wormable, with even Microsoft calling that out in their write-up. Before you pass this aside, Windows 10 can also be configured as a web server, so it is impacted as well. Definitely put this on the top of your test-and-deploy list.

-       CVE-2021-28476 - Hyper-V Remote Code Execution Vulnerability
With a CVSS of 9.9, this bug scores the highest severity rating for this month’s release. However, Microsoft notes an attacker is more likely to abuse this vulnerability for a denial of service in the form of a bugcheck rather than code execution. Because of this, it could be argued that the attack complexity would be high, which changes the CVSS rating to 8.5. That still rates as high severity, but not critical. Still, the bugcheck alone is worth making sure your Hyper-V systems get this update.

-       CVE-2021-27068 - Visual Studio Remote Code Execution Vulnerability
This patch fixes an unusual bug in Visual Studio 2019 that could allow code execution. It’s unusual because it’s listed as not requiring any user interaction, so it’s unclear how an attacker would leverage this vulnerability. It does appear that the attacker would need to be authenticated at some level, but the attack complexity is listed as low. If you are a developer running Visual Studio, make sure you grab this update.

-       CVE-2020-24587 - Windows Wireless Networking Information Disclosure Vulnerability
We don’t normally highlight info disclosure bugs, but this one has the potential to be pretty damaging. This patch fixes a vulnerability that could allow an attacker to disclose the contents of encrypted wireless packets on an affected system. It’s not clear what the range on such an attack would be, but you should assume some proximity is needed. You’ll also note this CVE is from 2020, which could indicate Microsoft has been working on this fix for some time.

Here’s the full list of CVEs released by Microsoft for May 2021:

CVE Title Severity CVSS Public Exploited Type
CVE-2021-31204 .NET Core and Visual Studio Elevation of Privilege Vulnerability Important 7.3 Yes No EoP
CVE-2021-31200 Common Utilities Remote Code Execution Vulnerability Important 7.2 Yes No RCE
CVE-2021-31207 Microsoft Exchange Server Security Feature Bypass Vulnerability Moderate 6.6 Yes No SFB
CVE-2021-31166 HTTP Protocol Stack Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2021-28476 Hyper-V Remote Code Execution Vulnerability Critical 9.9 No No RCE
CVE-2021-31194 OLE Automation Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2021-26419 Scripting Engine Memory Corruption Vulnerability Critical 6.4 No No RCE
CVE-2021-28461 Dynamics Finance and Operations Cross-site Scripting Vulnerability Important 6.1 No No XSS
CVE-2021-31936 Microsoft Accessibility Insights for Web Information Disclosure Vulnerability Important 7.4 No No Info
CVE-2021-31182 Microsoft Bluetooth Driver Spoofing Vulnerability Important 7.1 No No Spoofing
CVE-2021-31174 Microsoft Excel Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-31195 Microsoft Exchange Server Remote Code Execution Vulnerability Important 6.5 No No RCE
CVE-2021-31198 Microsoft Exchange Server Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31209 Microsoft Exchange Server Spoofing Vulnerability Important 6.5 No No Spoofing
CVE-2021-28455 Microsoft Jet Red Database Engine and Access Connectivity Engine Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-31180 Microsoft Office Graphics Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31178 Microsoft Office Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-31175 Microsoft Office Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31176 Microsoft Office Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31177 Microsoft Office Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31179 Microsoft Office Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31171 Microsoft SharePoint Information Disclosure Vulnerability Important 4.1 No No Info
CVE-2021-31181 Microsoft SharePoint Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-31173 Microsoft SharePoint Server Information Disclosure Vulnerability Important 5.3 No No Info
CVE-2021-28474 Microsoft SharePoint Server Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-26418 Microsoft SharePoint Spoofing Vulnerability Important 4.6 No No Spoofing
CVE-2021-28478 Microsoft SharePoint Spoofing Vulnerability Important 7.6 No No Spoofing
CVE-2021-31172 Microsoft SharePoint Spoofing Vulnerability Important 7.1 No No Spoofing
CVE-2021-31184 Microsoft Windows Infrared Data Association (IrDA) Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-26422 Skype for Business and Lync Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2021-26421 Skype for Business and Lync Spoofing Vulnerability Important 6.5 No No Spoofing
CVE-2021-31214 Visual Studio Code Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31211 Visual Studio Code Remote Development Extension Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31213 Visual Studio Code Remote Development Extension Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-27068 Visual Studio Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-28465 Web Media Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31190 Windows Container Isolation FS Filter Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31165 Windows Container Manager Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31167 Windows Container Manager Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31168 Windows Container Manager Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31169 Windows Container Manager Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31208 Windows Container Manager Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-28479 Windows CSC Service Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-31185 Windows Desktop Bridge Denial of Service Vulnerability Important 5.5 No No DoS
CVE-2021-31170 Windows Graphics Component Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31188 Windows Graphics Component Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31192 Windows Media Foundation Core Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31191 Windows Projected File System FS Filter Driver Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-31186 Windows Remote Desktop Protocol (RDP) Information Disclosure Vulnerability Important 7.4 No No Info
CVE-2021-31205 Windows SMB Client Security Feature Bypass Vulnerability Important 4.3 No No SFB
CVE-2021-31193 Windows SSDP Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31187 Windows WalletService Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2020-24587 Windows Wireless Networking Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2020-24588 Windows Wireless Networking Spoofing Vulnerability Important 6.5 No No Spoofing
CVE-2020-26144 Windows Wireless Networking Spoofing Vulnerability Important 6.5 No No Spoofing

There’s a flurry of Exchange patches in this month’s release, and some are related to bugs disclosed during the recent Pwn2Own contest. Two of the patches correct remote code execution bugs. While it appears these bugs result from Pwn2Own submissions, the exploits used during the contest did not require user interaction. The write-up from Microsoft does list user interaction in the CVSS score, however they may be scoring just this piece of the exploit chain. There’s also a spoofing bug and a security feature bypass that were used at the contest as part of a multi-bug chain. More Exchange patches are expected as not everything disclosed at the contest has been addressed. We’re working with Microsoft to get further clarification.

Moving on to the two remaining Critical-rated patches, both involve browsing to a website to get code execution. One bug impacts Internet Explorer while the other occurs when an attacker invokes OLE automation through a web browser. In both cases, the attacker would somehow have to lure the victim to their website.

Looking at the Important-rated patches, 18 involve remote code execution (RCE) of some form. One of the publicly known bugs falls into this category, although the disclosure occurred several months ago. The common utilities (common_utils.py) had an update checked in to GitHub back in December. If you use the Neural Network Intelligence open-source toolkit, make sure you have the latest version. There are several open-and-own style bugs in various Office components. There are three code execution bugs in Visual Studio Code, but these require a user to open a malicious file in a directory. If an attacker can convince such an act, they can execute their code at the level of the logged-on user.

Another RCE was reported by ZDI researcher Hossein Lotfi and impacts the Jet Red Database Engine and Access Connectivity Engine. To completely address this vulnerability, you’ll want to apply the update and restrict access to remote databases. Failing to restrict access can still expose your database to potential SQL adhoc/injection flaws. Microsoft published KB5002984 to provide guidance on restricting access.

There are 11 elevation of privilege (EoP) bugs receiving patches this month, and most are in the Windows Container Manager Service. Another EoP fix for .NET Core and Visual Studio is listed as publicly known, but Microsoft does not say where the disclosure occurred. One bug reported through the ZDI program affects the Wallet Service. By creating a directory junction, an attacker can abuse the service to create a file in an arbitrary location. An attacker can leverage this vulnerability to escalate privileges and execute code in the context of SYSTEM. Two other EoP bugs in the Windows Graphics component were reported by ZDI researcher Lucas Leong. The vulnerability result from the handling of Palette and Font Entry objects.

This month’s release includes 10 patches for information disclosure bugs, including the one previously mentioned. For the most part, these only lead to leaks consisting of unspecified memory contents. There are some notable exceptions. The info disclosure bugs in SharePoint could lead to unauthorized file system access or exposing Personally Identifiable Information (PII). Again, the info disclosure bug in Wireless is the most severe of this bunch.

There are eight spoofing bugs in May, and two were reported by the same researcher who reported the Wireless info disclosure bug. These also impact the Wireless component, but it’s not clear how the spoofing occurs. These also have CVEs from 2020, so again, it’s an indicator that these bugs have been in the works for a while. Other spoofing bugs being fixed this month affect SharePoint Server, Bluetooth, and Skype for Business and Lync.

In addition to the previously mentioned Exchange security feature bypass, there’s a fix for a bypass in the SMB client. In SMBv2, guest fallback is not disabled by default. The patch disables guest fallback access to enforce the OS and Group Policy settings. You can also disable guest access via the registry. The May release is rounded out with a cross-site scripting (XSS) bug in Dynamics Finance and Operations and a DoS bug in Windows Desktop Bridge.

Finally, the servicing stack advisory (ADV990001) was revised for all versions of Windows. No new advisories were released this month.

Looking Ahead

The next Patch Tuesday falls on June 8, and we’ll return with details and patch analysis then. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

The May 2021 Security Update Review

CVE-2021-26900: Privilege Escalation Via a Use After Free Vulnerability In win32k

In March 2021, Microsoft released a patch to correct a vulnerability in the Windows kernel. The bug could allow an attacker to execute code with escalated privileges. This vulnerability was reported to the ZDI program by security researcher JeongOh Kyea (@kkokkokye) of THEORI. He has graciously provided this detailed write-up and Proof-of-Concept detailing ZDI-21-331/CVE-2021-26900 and how it bypasses the fix for CVE-2020-1381, which was patched in July 2020.


DirectComposition

The DirectComposition component was added in Windows 8 and enables efficient support for graphical effects such as image conversion and animations. A presentation on finding vulnerabilities in DirectComposition was given by @360Vulcan at CanSecWest 2017 - Win32k Dark Composition [PDF].

DirectComposition can be accessed via win32k system calls that begin with NtDComposition. Before Windows 10 RS1, the caller makes a separate system call for each action, such as creating or releasing a resource. After Windows 10 RS1, these are merged into one system call, NtDCompositionProcessChannelBatchBuffer, which processes several commands in batch mode. The work presented by @360Vulcan at CanSecWest 2017 fuzzes this function to find vulnerabilities. Since then, many vulnerabilities related to DirectComposition have been discovered, including a Pwn2Own bug, CVE-2020-1382.

There are three essential system calls for triggering any DirectComposition vulnerability: NtDCompositionCreateChannel, NtDCompositionProcessChannelBatchBuffer and NtDCompositionCommitChannel.

To create DirectComposition objects, the caller must first create a channel using the NtDCompositionCreateChannel system call.

After creating the channel, several commands can be sent using the NtDCompositionProcessChannelBatchBuffer system call. Each command has its own format with various sizes.

The mapped section address, pMappedAddress, is used for storing a batch of commands. After storing several commands at pMappedAddress, the caller can invoke NtDCompositionProcessChannelBatchBuffer to process the commands.

To trigger the vulnerability, we need to use 3 commands: CreateResource, SetResourceBufferProperty, and ReleaseResource.

First, CreateResource is used to create a specific type of object. The size of the CreateResource command is 16 bytes and the format is as follows. The resource type may be different according to the Windows version. You can easily get the resource type number by analyzing the win32kbase!DirectComposition::CApplicationChannel::CreateResource function.

Table-1.png

Second, SetResourceBufferProperty is used to set the data for a target object. The size and format of this command depends on the resource type.

Table-2.png

Finally, ReleaseResource is used to release the resource. The size of the ReleaseResource command is 8 bytes and the format is as follows.

Table-3.png

NtDCompositionCommitChannel system call sends these commands, after serialization, to the Desktop Window Manager (dwm.exe) through the Local Procedure Call (LPC) protocol. After receiving the commands from the kernel, the Desktop Window Manager (dwm.exe) will render these commands to the screen.

The Vulnerability

The CVE-2021-26900 vulnerability is related to CInteractionTrackerBindingManagerMarshaler and CInteractionTrackerMarshaler. This vulnerability is very similar to CVE-2020-1381, so we will explain CVE-2020-1381 first before discussing CVE-2021-26900.

CVE-2020-1381

CVE-2020-1381/ZDI-20-872 was patched in July 2020. The vulnerability occurs in the DirectComposition::CInteractionTrackerBindingManagerMarshaler::SetBufferProperty function, which is the handler for the SetResourceBufferProperty command of a CInteractionTrackerBindingManagerMarshaler object.

The CInteractionTrackerBindingManagerMarshaler object takes 12 bytes as data for a SetResourceBufferProperty command. The data consists of three DWORDs: resource1_id, resource2_id, and new_entry_id

This function first retrieves resources from resource1_id and resource2_id specified by the user ([1]). It then checks that the type of each of these resources is 0x58, which is the resource type of CInteractionTrackerMarshaler ([2]).

Next, the pair of CInteractionTrackerMarshaler resources is appended to the tracker list of the CInteractionTrackerBindingManagerMarshaler object. As indicated by their names, the two object types, CInteractionTrackerMarshaler and CInteractionTrackerBindingManagerMarshaler, are related to each other. The CInteractionTrackerBindingManagerMarshaler object keeps a list of pairs of CInteractionTrackerMarshaler objects, and each of these CInteractionTrackerMarshaler objects has a pointer back to the CInteractionTrackerBindingManagerMarshaler object.

When the DirectComposition::CInteractionTrackerBindingManagerMarshaler::SetBufferProperty function is called for the first time, the tracker pair is added to the list because the list is empty.

To add the new entry to the tracker list, the size of tracker_list is increased by 1 and the new tracker pair data is written ([3]). Then, it sets a reference from each CInteractionTrackerMarshaler object to the CInteractionTrackerBindingManagerMarshaler ([4]) object using the DirectComposition::CInteractionTrackerMarshaler::SetBindingManagerMarshaler function, which is as follows.

The DirectComposition::CInteractionTrackerMarshaler::SetBindingManagerMarshaler function updates tracker->binding_obj to a new CInteractionTrackerBindingManagerMarshaler object.

After appending the CInteractionTrackerMarshaler object pair to tracker_list, the relationship between the CInteractionTrackerMarshaler object and the CInteractionTrackerBindingManagerMarshaler object is as follows:

Chart1.jpg

Because they are referenced by each other, the references must be cleared when an object is released. Let's see the situation if the CInteractionTrackerMarshaler object is released. To release the resources related with the CInteractionTrackerMarshaler object, the DirectComposition::CInteractionTrackerMarshaler::ReleaseAllReferences function is called.

If the CInteractionTrackerMarshaler object has a binding to a CInteractionTrackerBindingManagerMarshaler object, DirectComposition::CInteractionTrackerBindingManagerMarshaler::RemoveTrackerBindings is called to remove the corresponding tracking entry.

In DirectComposition::CInteractionTrackerBindingManagerMarshaler::RemoveTrackerBindings, if one of the two tracker objects in the entry has a resource id that matches the object being deleted, the entry_id of that entry will be set to zero. Finally, it calls DirectComposition::CInteractionTrackerBindingManagerMarshaler::CleanUpListItemsPendingDeletion to clean those entries that have entry_id equal to zero.

However, what happens if a single CInteractionTrackerMarshaler is added to multiple CInteractionTrackerBindingManagerMarshaler tracker lists? Because there is no check while adding a new entry, the CInteractionTrackerMarshaler object, which is already bound to a CInteractionTrackerBindingManagerMarshaler object, can become bound to a second CInteractionTrackerBindingManagerMarshaler object.

The picture below shows that situation:

Chart2.jpg

In this situation, if Tracker1 is freed, only the entry in TrackerBindingB is removed because Tracker1 is bound to TrackerBindingB. Eventually, the entry of the TrackerBindingA object has the freed object pointer.

Chart3.jpg

This dangling object pointer is later dereferenced in the DirectComposition::CInteractionTrackerBindingManagerMarshaler::EmitBoundTrackerMarshalerUpdateCommands function, which can be triggered via the NtDCompositionCommitChannel system call. This system call references the resource during serialization of the batched commands.

The function shown above calls the EmitUpdateCommands method for objects in the tracker_list. The freed object will get referenced in the process, which leads to a use-after-free vulnerability.

CVE-2021-26900

CVE-2021-26900/ZDI-21-331 will re-trigger the above vulnerability by bypassing the patch of CVE-2020-1381. The patch of CVE-2020-1381 is as follows.

The part marked with [*] was added to check the binding_obj of the CInteractionTrackerMarshaler object. it checks that the CInteractionTrackerMarshaler is not already bound to another CInteractionTrackerBindingManagerMarshaler.

However, this patch can be bypassed by updating the tracker entry. Let's see the code for updating the tracker entry:

First, the above code tries to find the entry that has tracker pair, (tracker1, tracker2) or (tracker2, tracker1). If there is an entry, the entry_id is updated to new_entry_id ([1]).

The most important part related to this vulnerability is [2]. When the new_entry_id is zero, the CInteractionTrackerBindingManagerMarshaler object regards this entry as not necessary. To handle this entry, it calls the DirectComposition::CInteractionTrackerBindingManagerMarshaler::RemoveBindingManagerReferenceFromTrackerIfNecessary function. However, this function will not remove this entry. It only removes the binding.

The above function tries to find an entry whose resource id is tracker1_id or tracker2_id. If there are no other entries whose resource id is tracker1_id or tracker2_id, it means that the two objects don't have to reference each other. Thus, the DirectComposition::CInteractionTrackerMarshaler::SetBindingManagerMarshaler function is called with a NULL binding object to remove the binding of the CInteractionTrackerMarshaler object.

However, the pointer of tracker1 or tracker2 remains in the tracker list although the binding from CInteractionTrackerMarshaler to CInteractionTrackerBindingManagerMarshaler is removed. Updating entry with a zero new_entry_id produces the state shown below:

Chart4.jpg

Now, the binding_obj of the CInteractionTrackerMarshaler object is set to zero, which can bypass the patch of CVE-2020-1381. If we bind tracker1 to another CInteractionTrackerBindingManagerMarshaler object, the state is changed as follows.

Chart5.jpg

Next, updating the entry_id in TrackerBindingA to a non-zero value will produce the same state as in CVE-2020-1381

The Patch

The patch applied to win32kbase.sys to fix the vulnerability, CVE-2021-26900, is as follows:

The patch applies to the code that adds the entry to tracker_list, modifies the entry_id, and releases the resource.

When modifying the entry_id, the binding is not removed although the entry_id is 0.

Next, when adding the entry, the listref field is added to the resource. This field is used to free the object properly when the same objects are inserted to tracker_list.

Finally, when releasing the resource, the binding is actually removed in the DirectComposition::CInteractionTrackerBindingManagerMarshaler::CleanUpListItemsPendingDeletion function.

Proof-of-concept code demonstrating this vulnerability can be found here.


Thanks again to JeongOh Kyea for providing this thorough write-up and PoC. He has contributed several Windows bugs to the ZDI program over the last couple of years, and we certainly hope to see more submissions from him in the future. Until then, follow the team for the latest in exploit techniques and security patches.

CVE-2021-26900: Privilege Escalation Via a Use After Free Vulnerability In win32k

Parallels Desktop RDPMC Hypercall Interface and Vulnerabilities

29 April 2021 at 16:02

Parallels Desktop implements a hypercall interface using an RDPMC instruction (“Read Performance-Monitoring Counter”) for communication between guest and host. More interestingly, this interface is accessible even to an unprivileged guest user. Though the HYPER-CUBE: High-Dimensional Hypervisor Fuzzing [PDF] paper by Ruhr-University Bochum has a brief mention of this interface, we have not seen many details made public. This blog post gives a brief description of the interface and discusses a couple of vulnerabilities (CVE-2021-31424/ZDI-21-434 and CVE-2021-31427/ZDI-21-435) I found in UEFI variable services.

Parallels Desktop has support for two Virtual Machine Monitors (VMM): Apple’s built-in hypervisor and the Parallels proprietary hypervisor. Prior to macOS Big Sur, the Parallels proprietary hypervisor is used by default. With this hypervisor there is a considerable amount of guest-to-host kernel attack surface, making it an interesting target. The details in this blog correspond to Parallels Desktop 15.1.5 running on a macOS Catalina 10.15.7 host.

Dumping the VMM

The proprietary VMM is a Mach-O executable that is compressed and embedded within the user space worker process prl_vm_app. The worker process injects the VMM blob into the kernel using an IOCTL_LOAD_MONITOR request to the prl_hypervisor kernel extension. The address of the zlib-compressed VMM and its sizes are maintained in a global structure, which can be used to dump the blobs for analysis. The VMM Mach-O binary has function names, making it easier to locate the hypercall handler for RDPMC.

Figure 1 - Compressed VMM Mach-O executable

Figure 1 - Compressed VMM Mach-O executable

When the guest executes an RDPMC instruction, the VMM calls Em_RDPMC_func()->HandleOpenToolsGateRequest() to process the request. The arguments to the hypercall are expected through the general-purpose registers RAX, RBX, RCX, RDX, RDI and RSI. The status of the request is returned through register RAX. The VMM also has an alternate code path PortToolsGateOutPortFunc()->HandleOpenToolsGateRequest(), reachable by writing to I/O port 0xE4.

HandleOpenToolsGateRequest() dispatches the request based on the value of register RAX and sub-commands in other registers. The code path of interest for this writeup is Em_RDPMC_func()->HandleOpenToolsGateRequest()->OTGHandleGenericCommand(), which can be reached by setting RAX = 0x7B6AF8E and RBX = 7. OTGHandleGenericCommand() further supports multiple guest operations based on the value set in register RDX. The debug messages quickly reveal that RDX = 9 handles UEFI service requests for reading and writing UEFI variables.

The UEFI runtime variable services in Parallels Desktop include three components: UEFI firmware, a hypercall interface in the VMM, and an API through which the VMM makes requests to the host user space prl_vm_app worker process. The VMM and the worker process communicate using shared memory.

Analyzing the Firmware

The UEFI firmware that ships with Parallels Desktop (efi64d.bin and efi64.bin) is based on EDK2. Just like the VMM Mach-O binary, it is a zlib-compressed binary starting with 12 bytes of magic header. To analyze the firmware, decompress the file skipping the first 12 bytes and load it using the efiXplorer IDA Pro plugin. This may take a while, but it does work well. Once the analysis is over, search the firmware for the hypercall number for invoking OTGHandleGenericCommand (0x7B6AF8E).

Figure 2 - Search for OTGHandleGenericCommand

Figure 2 - Search for OTGHandleGenericCommand

The search returned multiple results, but the most interesting ones for the UEFI runtime variable services hypercall are part of VariableRuntime.Dxe. Note that the firmware relies on I/O port 0xE4 for the hypercall instead of RDPMC, as illustrated below.

Figure 3 - UEFI firmware invoking hypercall

Figure 3 - UEFI firmware invoking hypercall

By cross-referencing the hypercall, the UEFI variable driver entry points can be located in the firmware. Then, by comparing the decompiled code with VariableServiceInitialize() in EDK2, the handlers for UEFI runtime variable services can be easily identified. This can be done using the efiXplorer IDA plugin, which imports all the type information.

Consider the callback for GetVariable(). The firmware sets up a 48 byte request structure with an operation type (0x10) and other required fields. OTG_Hypercall() loads the address of the request structure in register RSI and triggers the hypercall as seen in Figure 3. Similarly, each variable service has an operation type associated with it. By analyzing the callbacks for SetVariable(), GetNextVariableName(), and QueryVariableInfo(), the operation type to service mapping as well as the structure of the VMM service request can be recovered.

Figure 4 - UEFI GetVariable() service

Figure 4 - UEFI GetVariable() service

Figure 5 - VMM request structure

Figure 5 - VMM request structure

Table 1 - Mapping Variable services to VMM operations

Table 1 - Mapping Variable services to VMM operations

Hypercall Vulnerabilities

We will be examining some vulnerabilities in OTGHandleGenericCommand. A simplified view of the decompiled code is shown below. Note that the Parallels VMM uses functions ReadLinear() and WriteLinear() for reading from and writing to guest memory respectively. MonRetToHostSwitch() transfers control from the VMM to the user space worker process (still on the host) to handle a specific API request, and the parameter value of 0xD7 corresponds to API_EFI_VAR_REQUEST.

CVE-2021-31424/ZDI-CAN-12848 – Heap Overflow

The first bug is a heap overflow. The size of the UEFI variable name provided by the guest is not validated. Therefore, the copy operation using ReadLinear() overflows the host kernel heap by a guest provided value * 2 (UTF-16).

CVE-2021-31427/ZDI-CAN-13082 - Time-Of-Check Time-Of-Use Information Disclosure

The second interesting observation I made during my analysis was that the data size in the UEFI service request is written to shared memory before validation. After writing, the VMM validates the data size, but only when handling SetVariable(). For read requests, such as GetVariable(), GetNextVariableName(), or QueryVariableInfo(), the validation is delegated to user mode process using the MonRetToHostSwitch(API_EFI_VAR_REQUEST) call.

After MonRetToHostSwitch(API_EFI_VAR_REQUEST) returns, the VMM checks the status set by the user space. If the status is 0, WriteLinear() fetches data size from the shared memory again for writing back to the guest. This is where things get interesting. There is a race window between the call to user space MonRetToHostSwitch() and WriteLinear() in the VMM. If the data size can be updated to some untrusted value, with status set to 0, it is possible to trigger an out-of-bounds read during WriteLinear(). To trigger the race, it is necessary to understand how the status is updated in the shared memory by the worker process. In prl_vm_app, the handler for API_EFI_VAR_REQUEST is at the address 0x1000DEDF0:

EFIVar.datasize is updated or validated in the user space and status is set to 0 only when a request is successful. Otherwise EFIVar.datasize is set to 0 and status is set to a non-zero error code. The simplest request type turned out to be QueryVariableInfo(), which returns the maximum storage size, remaining storage size, and maximum size of a single UEFI variable. It also sets the status to 0 when the expected data size equals 24. As there are no state changing operations, QueryVariableInfo() is ideal for triggering the bug. Consider the following scenario:

Thread A – Keep sending SetVariable() request with arbitrary data size value > 0x1000 bytes that updates SharedMem->EFIVar.datasize but always returns without entering the worker process due to the validation request.datasize > 0x1000.

Thread B – Keep sending QueryVariableInfo() requests, which sets status to 0. If thread A updates the SharedMem->EFIVar.datasize after the status is set by QueryVariableInfo() in the user space but before the VMM copies data using WriteLinear(), an out-of-bounds read can be triggered. Below is a debug log of the VMM page fault when the OOB read hits an unmapped kernel address.

Conclusion

What made these bugs particularly interesting is that they are reachable through a lesser-known interface. Also, they can be triggered by an unprivileged guest user to execute code in the host kernel. That said, since the introduction of macOS Big Sur, the Parallels proprietary hypervisor is not used by default. Parallels patched both these RDPMC hypercall bugs in the recently released 16.5.0 along with many other issues reported through the ZDI program.

You can find me on Twitter @RenoRobertr, and follow the team for the latest in exploit techniques and security patches.

Parallels Desktop RDPMC Hypercall Interface and Vulnerabilities

CVE-2021-20226: A Reference-Counting Bug in the Linux Kernel io_uring Subsystem

22 April 2021 at 16:27

In June 2020, we received a Linux kernel submission detailing a reference-counting bug in the recently introduced io_uring subsystem. The bug leads to a use-after-free on any file structure, which can be leveraged for privilege escalation in the kernel. This bug was submitted by Ryota Shiga (@Ga_ryo_) of Flatt Security.

We believe that the vulnerability affected the Linux kernel from version 5.6 to 5.7 inclusive. The vulnerability has been assigned identifiers ZDI-21-001 and CVE-2021-20226.

The Vulnerability

Linux kernel 5.1 introduced a new asynchronous I/O feature called io_uring. This subsystem operates by batching I/O operation system calls, so that multiple I/O operations can be performed in one system call.

Linux kernel 5.6 has a flawed implementation of the IORING_OP_CLOSE operation. When a system call passes a files_struct to a kernel thread, io_grab_files() doesn’t increment the reference counter at (1). This can lead to a later access of the freed file structure.

Exploitation

The map_lookup_elem() and map_update_elem() functions are good candidates for use in exploiting this bug.

The fdget() at (2) is an optimized function that doesn't increase the reference count if the current task is single-thread. The returned file structure, f, can be freed by a later IORING_OP_CLOSE. The __bpf_copy_key() syscall at (3) is actually a wrapper for copy_from_user(). This provides an opportunity to produce a race condition by using userfaultfd and triggering the vulnerability. At this point, file structure f and its corresponding map are freed. The memory of the map can be reallocated with fake data at (4) and (5). Finally, we can read arbitrary memory at (6) and disclose to usermode.

Here is an overview for the exploit timeline:

Figure 1 - The Exploit Timeline

Figure 1 - The Exploit Timeline

The recvmsg() function is for timing control. The freed bpf_map can be faked by spraying with setxattr(). The arbitrary write can be achieved by map_update_elem(). This exploit method is restricted to a single-core environment due to the condition of fdget().

Conclusion

New features mean new attack surfaces, and new attack surfaces often lead to new bugs being discovered. It will be interesting to see if any other vulnerabilities are found in this subsystem. Regardless, it was a great find by Ryota, and we appreciate his submission. If that name sounds familiar at all, Ryota also competed in the most recent Pwn2Own and won $30,000 demonstrating a different privilege escalation bug on Ubuntu. We look forward to seeing more from him in the future.

You can find me on Twitter @_wmliang_, and follow the team for the latest in exploit techniques and security patches.

CVE-2021-20226: A Reference-Counting Bug in the Linux Kernel io_uring Subsystem

The April 2021 Security Update Review

13 April 2021 at 17:29

It’s the second Tuesday of the month, which means the latest security updates from Adobe and Microsoft are released. Take a break from your regularly scheduled activities and join us as we review the details for their latest security offerings.

Adobe Patches for April 2021

For April, Adobe released four patches addressing 10 CVEs in Adobe Photoshop, Digital Editions, RoboHelp, and Bridge. The update for Bridge fixes six CVEs, all of which were reported through the ZDI program. Four of these bugs are rated Critical and could allow arbitrary code execution if exploited. The patch for Photoshop fixes two Critical-rated CVEs. Both of these buffer overflows could all arbitrary code execution. The update for Digital Editions fixes a Critical-rated privilege escalation bug that could lead to an arbitrary file system write. Finally, the patch for RoboHelp fixes a single privilege escalation bug. None of the CVEs addressed by Adobe are listed as publicly known or under active attack at the time of release.

Microsoft Patches for April 2021

For April, Microsoft released patches for 114 CVEs in Microsoft Windows, Edge (Chromium-based), Azure and Azure DevOps Server, Microsoft Office, SharePoint Server, Hyper-V, Team Foundation Server, Visual Studio, and Exchange Server. This is the largest number of CVEs addressed in a month by Microsoft this year, and it is slightly higher than April of last year. A total of five of these bugs came through the ZDI program. None of the bugs being addressed this month were disclosed at the recent Pwn2Own contest. Of these 114 bugs, 19 are rated as Critical, 88 are rated Important, and one is rated Moderate in severity. Six additional bugs impact Edge (Chromium-based) and were ingested from a recent Chromium update. According to Microsoft, one bug is currently being exploited while four others are publicly known at the time of release.

Let’s take a closer look at some of the more interesting updates for this month, starting with the bug listed as being under active attack:

-       CVE-2021-28310 - Win32k Elevation of Privilege Vulnerability
This is the only vulnerability listed as being actively exploited being patched in April. The bug allows an attacker to escalate privileges by running a specially crafted program on a target system. This does mean that they will either need to log on to a system or trick a legitimate user into running the code on their behalf. Considering who is listed as discovering this bug, it is probably being used in malware. Bugs of this nature are typically combined with other bugs, such as a browser bug or PDF exploit, to take over a system.

-       CVE-2021-28480/28481 – Microsoft Exchange Server Remote Code Execution Vulnerability
Both of these CVEs are listed at a 9.8 CVSS and have identical write-ups, so they both get listed here. Both code execution bugs are unauthenticated and require no user interaction. Since the attack vector is listed as “Network,” it is likely these bugs are wormable – at least between Exchange servers. The CVSS score for these two bugs is actually higher than the Exchange bugs exploited earlier this year. These bugs were credited to the National Security Agency. Considering the source, and considering these bugs also receive Microsoft’s highest Exploit Index rating, assume they will eventually be exploited. Update your systems as soon as possible.

-       CVE-2021-28329 et al. – Remote Procedure Call Runtime Remote Code Execution Vulnerability
There are 27 bugs in this month’s release with this title, and all have identical descriptions and CVSS scores. However, 12 are rated Critical while 15 are rated Important in severity. In RPC vulnerabilities seen in the past, an attacker would need to send a specially crafted RPC request to an affected system. Successful exploitation results in executing code in the context of another user. Perhaps the users involved in the Important-rated bugs have lower privileges than their Critical-rated counterparts, but that is not clear from the description. Either way, the researcher who reported these bugs certainly found quite the attack surface.

-       CVE-2021-28444 – Windows Hyper-V Security Feature Bypass Vulnerability
This security feature bypass allows an attacker to potentially bypass Router Guard configurations on Hyper-V. Router Guard is designed to prevent guest OSes from offering router services on the network. Many don’t realize Windows can be set up as a router, and on physical or virtual systems, be configured to re-route packets to a rouge location (e.g. Man-in-the-Middle) or simply black hole the traffic. If you’re running Hyper-V, even accidental misconfigurations could cause disruptions, so definitely don’t ignore this patch.

Here’s the full list of CVEs released by Microsoft for April 2021, minus the Edge bugs ingested from Chromium.

CVE Title Severity CVSS Public Exploited Type
CVE-2021-28310 Win32k Elevation of Privilege Vulnerability Important 7.8 No Yes EoP
CVE-2021-28458 Azure ms-rest-nodeauth Library Elevation of Privilege Vulnerability Important 7.8 Yes No EoP
CVE-2021-27091 RPC Endpoint Mapper Service Elevation of Privilege Vulnerability Important 7.8 Yes No EoP
CVE-2021-28437 Windows Installer Information Disclosure Vulnerability Important 5.5 Yes No Info
CVE-2021-28312 Windows NTFS Denial of Service Vulnerability Moderate 3.3 Yes No DoS
CVE-2021-28460 Azure Sphere Unsigned Code Execution Vulnerability Critical 8.1 No No RCE
CVE-2021-28480 Microsoft Exchange Server Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2021-28481 Microsoft Exchange Server Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2021-28482 Microsoft Exchange Server Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2021-28483 Microsoft Exchange Server Remote Code Execution Vulnerability Critical 9 No No RCE
CVE-2021-28329 Remote Procedure Call Runtime Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2021-28330 Remote Procedure Call Runtime Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2021-28331 Remote Procedure Call Runtime Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2021-28332 Remote Procedure Call Runtime Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2021-28333 Remote Procedure Call Runtime Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2021-28334 Remote Procedure Call Runtime Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2021-28335 Remote Procedure Call Runtime Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2021-28336 Remote Procedure Call Runtime Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2021-28337 Remote Procedure Call Runtime Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2021-28338 Remote Procedure Call Runtime Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2021-28339 Remote Procedure Call Runtime Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2021-28343 Remote Procedure Call Runtime Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2021-27095 Windows Media Video Decoder Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2021-28315 Windows Media Video Decoder Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2021-27092 Azure AD Web Sign-in Security Feature Bypass Vulnerability Important 4.3 No No SFB
CVE-2021-27067 Azure DevOps Server and Team Foundation Server Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2021-28459 Azure DevOps Server and Team Foundation Services Spoofing Vulnerability Important 6.1 No No Spoofing
CVE-2021-28313 Diagnostics Hub Standard Collector Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-28321 Diagnostics Hub Standard Collector Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-28322 Diagnostics Hub Standard Collector Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-28456 Microsoft Excel Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-28451 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-28454 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-27089 Microsoft Internet Messaging API Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-28449 Microsoft Office Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-28452 Microsoft Outlook Memory Corruption Vulnerability Important 7.1 No No RCE
CVE-2021-28450 Microsoft SharePoint Denial of Service Update Important 5 No No DoS
CVE-2021-28317 Microsoft Windows Codecs Library Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-28453 Microsoft Word Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-27096 NTFS Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-28466 Raw Image Extension Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-28468 Raw Image Extension Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-28471 Remote Development Extension for Visual Studio Code Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-28327 Remote Procedure Call Runtime Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-28340 Remote Procedure Call Runtime Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-28341 Remote Procedure Call Runtime Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-28342 Remote Procedure Call Runtime Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-28344 Remote Procedure Call Runtime Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-28345 Remote Procedure Call Runtime Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-28346 Remote Procedure Call Runtime Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-28352 Remote Procedure Call Runtime Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-28353 Remote Procedure Call Runtime Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-28354 Remote Procedure Call Runtime Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-28355 Remote Procedure Call Runtime Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-28356 Remote Procedure Call Runtime Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-28357 Remote Procedure Call Runtime Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-28358 Remote Procedure Call Runtime Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-28434 Remote Procedure Call Runtime Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-28470 Visual Studio Code GitHub Pull Requests and Issues Extension Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-28448 Visual Studio Code Kubernetes Tools Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-28472 Visual Studio Code Maven for Java Extension Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-28457 Visual Studio Code Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-28469 Visual Studio Code Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-28473 Visual Studio Code Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-28475 Visual Studio Code Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-28477 Visual Studio Code Remote Code Execution Vulnerability Important 7 No No RCE
CVE-2021-27064 Visual Studio Installer Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-28464 VP9 Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-27072 Win32k Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2021-28311 Windows Application Compatibility Cache Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2021-28326 Windows AppX Deployment Server Denial of Service Vulnerability Important 5.5 No No DoS
CVE-2021-28438 Windows Console Driver Denial of Service Vulnerability Important 5.5 No No DoS
CVE-2021-28443 Windows Console Driver Denial of Service Vulnerability Important 5.5 No No DoS
CVE-2021-28323 Windows DNS Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2021-28328 Windows DNS Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2021-27094 Windows Early Launch Antimalware Driver Security Feature Bypass Vulnerability Important 4.4 No No SFB
CVE-2021-28447 Windows Early Launch Antimalware Driver Security Feature Bypass Vulnerability Important 4.4 No No SFB
CVE-2021-27088 Windows Event Tracing Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-28435 Windows Event Tracing Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-28318 Windows GDI+ Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-28348 Windows GDI+ Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-28349 Windows GDI+ Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-28350 Windows GDI+ Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-26416 Windows Hyper-V Denial of Service Vulnerability Important 7.7 No No DoS
CVE-2021-28314 Windows Hyper-V Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-28441 Windows Hyper-V Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2021-28444 Windows Hyper-V Security Feature Bypass Vulnerability Important 5.7 No No SFB
CVE-2021-26415 Windows Installer Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-28440 Windows Installer Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2021-26413 Windows Installer Spoofing Vulnerability Important 6.2 No No Spoofing
CVE-2021-27093 Windows Kernel Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-28309 Windows Kernel Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-27079 Windows Media Photo Codec Information Disclosure Vulnerability Important 5.7 No No Info
CVE-2021-28445 Windows Network File System Remote Code Execution Vulnerability Important 8.1 No No RCE
CVE-2021-26417 Windows Overlay Filter Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-28446 Windows Portmapping Information Disclosure Vulnerability Important 7.1 No No Info
CVE-2021-28320 Windows Resource Manager PSM Service Extension Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-27090 Windows Secure Kernel Mode Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-27086 Windows Services and Controller App Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-28324 Windows SMB Information Disclosure Vulnerability Important 7.5 No No Info
CVE-2021-28325 Windows SMB Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2021-28347 Windows Speech Runtime Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-28351 Windows Speech Runtime Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-28436 Windows Speech Runtime Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-28319 Windows TCP/IP Driver Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2021-28439 Windows TCP/IP Driver Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2021-28442 Windows TCP/IP Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2021-28316 Windows WLAN AutoConfig Service Security Feature Bypass Vulnerability Important 4.2 No No SFB

Moving on to the remaining Critical-rated patches, there are two additional patches for Exchange that are nearly as severe as those already documented. None of the Exchange bugs this month indicate Office 365 versions are affected. Like those before them, these bugs only impact on-prem installations. Microsoft also provided additional information about the security updates. If you’re running Exchange, this should be considered required reading.

There’s a bug impacting Azure Sphere, but you likely won’t need to take any action to be protected. Devices running Azure Sphere connected to the Internet should receive automatic updates. If your devices are isolated, you will need to ensure these updates are applied. The final two Critical-rated patches correct bugs in the Windows Media Video Decoder component. For these, an attacker would need to convince a user to open specially crafted media on an affected system to gain arbitrary code execution at the logged-on user level.

Looking at other bugs in this release, we see more than half of the patches this month are related to remote code execution vulnerabilities. Beyond those already mentioned, the bugs mostly impact Office and Windows components. In most cases, they represent open-and-own scenarios. Of those that stand out, there’s a bug impacting Outlook that requires user interaction but could lead to code execution. There are several patches for Visual Studio as well. These also will require some form of user interaction. There’s one patch for the Visual Studio Code GitHub Pull Requests and Issues Extension, but it’s unclear how an attacker would leverage this vulnerability. The same goes for the bug in Visual Studio Code Kubernetes Tools. The final RCE bugs to watch out for impact the GDI+ component. These are somewhat cryptic. Even though they are listed as RCE, their attack vector is listed as local and user interaction is none. This would indicate the bugs could be triggered by something other than viewing or opening an image, but without further details, we can only speculate. 

There are 19 bugs labelled as privilege escalations, and this includes two of the publicly known vulnerabilities. The first occurs in the Azure ms-rest-nodeauth library, and the other is in the RPC Endpoint Mapper Service. There’s also a privilege escalation in Hyper-V, but it’s not clear where an attacker would escalate from or to. For the majority of these bugs, an attacker would need to log on to an affected system and run their own code. As mentioned above, these are typically combined with a separate code execution bug to take over a system.

This month’s release also includes patches for nine Denial of Service (DoS) bugs, including the publicly known Moderate-rate DoS in NTFS. The other DoS bug that stands impacts the TCP/IP driver. It appears an attacker could cause a DoS by sending specially crafted packets to an affected system, although it’s not clear if this would result in a blue screen of if the system would just stop responding. Other DoS bugs impact SharePoint, the AppX Deployment server, Hyper-V, and other Windows components.

The final publicly known bug this month in an info disclosure bug in the Windows Installer. If exploited, the bug could allow attackers unauthorized file system access. There are 17 total info disclosure bugs receiving patches this month, and most only lead to leaks consisting of unspecified memory contents. An exception to this is a bug that impacts the Azure DevOps Server. If exploited, this vulnerability could leak pipeline configuration variables and secrets. There’s a patch for an info disclosure bug in Excel as well. A user would need to open a specially crafted file with Excel to be impacted, but it’s not clear what would leak beyond “sensitive information.”

Shifting to the security feature bypasses, there are two patches for the Windows Early Launch Antimalware driver – better known as ELAM. Microsoft does not list what security feature could be bypassed by either vulnerability. Other bypasses impact the Azure AD Web Sign-in and the Windows WLAN AutoConfig Service. These bugs also provide no guidance on what may be bypassed by an attacker.

This month’s release is rounded out by patches to address two spoofing bugs. The first bug impacts Azure DevOps Server and Team Foundation Services, while the other affects the Windows Installer. Neither of these bugs receives much in the way of documentation, but a CVSS score north of 6 means they shouldn’t be ignored.

Finally, the servicing stack advisory (ADV990001) was revised for multiple versions of Windows. No additional advisories were released this month.

Looking Ahead

The next Patch Tuesday falls on May 11, and we’ll return with details and patch analysis then. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

The April 2021 Security Update Review

Pwn2Own 2021 - Schedule and Live Results

6 April 2021 at 13:47

Welcome to Pwn2Own 2021! This year, we’re distributed amongst various locations to run the contest, but we’ll be bringing you all of the results live from Austin with love. This year’s event is shaping up to be one of the largest in Pwn2Own history, with 23 separate entries targeting 10 different products in the categories of Web Browsers, Virtualization, Servers, Local Escalation of Privilege, and - our newest category - Enterprise Communications.

If you’ve ever wanted to watch Pwn2Own but couldn’t get to Vancouver, you’re in luck! We’ll be streaming the entirety of the event on YouTube, Twitch, and the conference site. In between the attempts, we’ll also have interviews with researchers and vendors, highlights from previous events, and other videos highlighting some of the work done by Trend Micro research. On Wednesday, we’ll have a special “Hacker Hall of Fame” video series that is not to be missed. Be sure to stop by often to see the latest.

As always, we started the contest with a random drawing to determine the order of attempts. We have a total of 23 attempts scheduled over the next three very full days. The complete schedule for the contest is below (all times Eastern [UTC -4:00]). We will update this schedule with results as they become available.

Note: All times subject to change

Tuesday, April 6

Miss any of the attempts? You can watch the full replay of Day One here.

1000 - Jack Dates from RET2 Systems targeting Apple Safari in the Web Browser category

SUCCESS - Jack used an integer overflow in Safari and an OOB Write to get kernel-level code execution. In doing so, he wins $100,000 and 10 Master of Pwn points.

1130 - DEVCORE targeting Microsoft Exchange in the Server category

SUCCESS - The DEVCORE team combined an authentication bypass and a local privilege escalation to complete take over the Exchange server. They earn $200,000 and 20 Master of Pwn points.

1300 - The researcher who goes by OV targeting Microsoft Teams in the Enterprise Communications category

SUCCESS - OV combined a pair of bugs to demonstrate code execution on Microsoft Teams. In doing so, we earns himself $200,000 and 20 points towards Master of Pwn

1430 - Team Viettel targeting Windows 10 in the Local Escalation of Privilege category

SUCCESS - The team used an integer overflow in Windows 10 to escalate from a regular user to SYSTEM privileges. This earns them $40,000 and 4 points towards Master of Pwn.

1530 - The STAR Labs team of Billy, Calvin and Ramdhan targeting Parallels Desktop in the Virtualization category

FAILURE - The STAR Labs team could not get their exploit to work within the time allotted.

1630 - Ryota Shiga of Flatt Security Inc targeting Ubuntu Desktop in the Local Escalation of Privilege category

SUCCESS - Ryota used an OOB access bug to go from a standard user to root on Ubuntu Desktop. He earns $30,000 and 3 Master of Pwn points in his Pwn2Own debut.

1730 - The STAR Labs team of Billy, Calvin and Ramdhan Oracle VirtualBox in the Virtualization category

FAILURE - The STAR Labs team could not get their exploit to work within the time allotted.

Wednesday, April 7

Miss any of the attempts? You can watch the full replay of Day Two here.

0900 - Jack Dates from RET2 Systems targeting Parallels Desktop in the Virtualization category

SUCCESS - Jack combined three bugs - an uninitialized memory leak, a stack overflow, and an integer overflow to escape Parallels Desktop and execute code on the underlying OS. He earns $40K and 4 more Master of Pwn points. His two day total is now $140,000 and 14 points.

1000 - Bruno Keith (@bkth_) & Niklas Baumstark (@_niklasb) of Dataflow Security (@dfsec_it) targeting Google Chrome and Microsoft Edge (Chromium) in the Web Browser category

SUCCESS - The team used a Typer Mismatch bug to exploit the Chrome renderer and Microsoft Edge. Same exploit for both browsers. They earn $100,000 total and 10 Master of Pwn points.

1130 - Team Viettel targeting Microsoft Exchange in the Server category

PARTIAL - Team Viettel successfully demonstrated their code execution on the Exchange server, but some of the bugs they used in their exploit chain had been previously reported in the contest. This counts as a partial win but does get them 7.5 Master of Pwn points.

1300 - Daan Keuper and Thijs Alkemade from Computest targeting Zoom Messenger in the Enterprise Communications category

SUCCESS - Daan Keuper and Thijs Alkemade from Computest used a three bug chain to exploit Zoom messenger and get code execution on the target system - all without the target clicking anything. They earn themselves $200,000 and 20 Master of Pwn points.

Zero clicks needed to pop calc

Zero clicks needed to pop calc

1430 - Tao Yan (@Ga1ois) of Palo Alto Networks targeting Windows 10 in the Local Escalation of Privilege category

SUCCESS - Tao Yan used a Race Condition bug to escalate to SYSTEM on the fully patched Windows 10 machine. He earns himself $40,000 and 4 points towards Master of Pwn.

1530 - Sunjoo Park (aka grigoritchy) targeting Parallels Desktop in the Virtualization category

SUCCESS - Sunjoo Park (aka grigoritchy) used a logic bug to execute code on the underlying operating system through Parallels Desktop. He wins $40,000 and 4 points towards Master of Pwn.

1630 - Manfred Paul targeting Ubuntu Desktop in the Local Escalation of Privilege category

SUCCESS - Manfred used an OOB Access bug to escalate to a root user on Ubuntu Desktop. The Pwn2Own veteran earns himself $30,000 and 3 points towards Master of Pwn.

1730 - The researcher known as z3r09 targeting Windows 10 in the Local Escalation of Privilege category

SUCCESS - z3r09 used an integer overflow to escalate his permissions up to NT Authority\SYSTEM. His impressive display nets him $40,000 and 4 points towards Master of Pwn.

Thursday, April 8

0900 - Benjamin McBride from L3Harris Trenchant targeting Parallels Desktop in the Virtualization category

SUCCESS - Ben used a memory corruption bug to successfully execute code on the host OS from within Parallels Desktop. He earns $40,000 and 4 Master of Pwn points.

1000 - Steven Seeley of Source Incite targeting Microsoft Exchange in the Server category

PARTIAL - Although Steven did use two unique bugs in his demonstration, this attempt was a partial win due to the Man-in-the-Middle aspect of the exploit. It's still great research though, and he earns 7.5 Master of Pwn points.

1130 - The STAR Labs team of Billy targeting Ubuntu Desktop in the Local Escalation of Privilege category

PARTIAL - Although Billy was able to successfuolly escalate privileges to root, the bug he used was known to the vendor and will be patched soon. The demonstration does earn him 2 additional Master of Pwn points.

1230 - Fabien Perigaud of Synacktiv targeting Windows 10 in the Local Escalation of Privilege category

PARTIAL - Despite the excellent use of ASCII art during his demonstration, it turns out Microsoft was aware of the bug he used. He still earns 2 Master of Pwn points for the partial win.

1330 - Alisa Esage targeting Parallels Desktop in the Virtualization category

PARTIAL - Despite the great demonstration (replete with ASCII art), the bug used by Alisa had been reported to the ZDI prior to the contest, making this a partial win. It's still great work, and we're thrilled she broke ground as the 1st woman to participate as an independent researcher in Pwn2Own history. Her efforts do result in two points towards Maser of Pwn.

1430 - Vincent Dehors of Synacktiv targeting Ubuntu Desktop in the Local Escalation of Privilege category

SUCCESS - Despite admitting this was the first exploit he had written for Linux, Vincent had no issues escalating to root through a double free bug. He earns himself $30,000 and 3 Master of Pwn points.

1530 - Da Lao targeting Parallels Desktop in the Virtualization category

SUCCESS - The researcher known as Da Lao used an OOB Write to successfully complete his guest-to-host escape in Parallels. He earns $40,000 and 4 points towards Master of Pwn.

1630 - Marcin Wiazowski targeting Windows 10 in the Local Escalation of Privilege category

SUCCESS - Marcin used a Use After Free (UAF) bug to escalate to SYSTEM on Windows 10. He wins himself $40,000 and 4 Master of Pwn points.

Thanks again to our partners Tesla, Zoom, and Adobe as well as our sponsor VMware. Thanks also to the researchers who participate and to the vendors for providing fixes for what’s discovered during the contest. As a reminder, vendors have 90 days to produce a fix for all vulnerabilities reported.

Pwn2Own 2021 - Schedule and Live Results

CVE-2021-25646: Getting Code Execution on Apache Druid

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Pengsu Cheng and Prosenjit Sinha of the Trend Micro Research Team detail a recent code execution vulnerability in the Apache Druid database. The bug was originally discovered and reported by Litch1 from the Security Team of Alibaba Cloud. The following is a portion of their write-up covering CVE-2021-25646, with a few minimal modifications.


Apache Druid is a high-performance, modern, real-time analytic database. Druid is designed for workflows where fast ad-hoc analytics, instant data visibility, or high concurrency are required. Druid streams data from applications like Kafka and Amazon Kinesis, and batch-loads files from data lakes such as HDFS and Amazon S3. Druid supports most popular file formats for structured and semi-structured data. Some common application areas for Druid include clickstream analytics (web and mobile analytics), network telemetry analytics (network performance monitoring), server metrics storage, supply chain analytics, (manufacturing metrics), application performance metrics, digital marketing/advertising analytics, and business intelligence. 

Apache Druid provides a rich set of APIs via HTTP and JDBC for loading, managing and querying data. Users can also interact with Druid via its built-in console interface. The Apache Druid console can be accessed via HTTP. An HTTP request consists of a request line, various headers, an empty line, and an optional message body: 

where CRLF represents the new line sequence Carriage Return (CR) followed by Line Feed (LF) and SP represents a space character. Parameters can be passed from the client to the server as name-value pairs in either the Request-URI or in the message-body, depending on the Method used and the Content-Type header. For example, a simple HTTP request using the GET method and passing a parameter named param with value 1 would look like this:

A corresponding HTTP request using the POST method might look like:

If there is more than one parameter/value pair, they are encoded as &-delimited name=value pairs:

         var1=value1&var2=value2...

The Vulnerability

Druid offers the ability to execute JavaScript at the server without restrictions. Out of concern for security, JavaScript is disabled by default.

Druid uses Jackson to parse the JSON data. When Druid receives JSON data of type “javascript” it uses JavaScriptDimFilter as the corresponding entity class. The constructor of JavaScriptDimFilter is decorated with @JasonCreator:

The @JsonCreator annotation signifies that when the JavaScriptDimFilter class is deserialized, Jackson will call this constructor. The parameters of the constructor dimension, function, extractionFn, and filterTuning all have @JasonProperty annotation modification; as a result, Jackson will be encapsulated a com.fasterxml.jackson.databind.deser.CreatorProperty type when deserializing and parsing to JavaScriptDimFilter. In the case of config parameters that are not marked @JasonProperty, a com.fasterxml.jackson.databind.deser.CreatorProperty named "" will be created.

According to the Druid documentation, JavaScript execution can be enabled via the flag druid.javascript.config in the configuration, and is disabled by default. org.apache.druid.js.JavaScriptConfig contains JavaScript-related configuration. Druid uses the Jersey framework, and all its configuration information, including JavaScriptConfig, is provided by the Guice framework. In order to execute JavaScript on the Druid server, an attacker would need to enable JavaScript in the JavaScriptDimFilter configuration.

Apache Druid has a remote code execution vulnerability while parsing JSON data of type JavaScript. This vulnerability is mainly based on the Jackson parsing feature. When the name property of the JSON data is resolved to "", the value of that empty key is bound to the corresponding parameter (config) of the object (JavaScriptDimFilter, specified when the type is JavaScript). As a result, an attacker can enable the JavaScript execution settings, resulting in the execution of user-supplied JavaScript using the function key.

In the com.fasterxml.jackson.databind.deser.BeanDeserializer#_deserializeUsingPropertyBased method, the “key name” in the parsed JSON string is used to find the corresponding CreatorProperty in the current parsed object. This functionality of looking at the CreatorProperty is implemented in the findCreatorProperty method. The findCreatorProperty method looks for the property in the _propertyLookup HashMap for the corresponding “key name”. In _propertyLookup, the key of JavaScriptConfig is set to "" as it is not decorated with a @JsonProperty annotation. If the attacker supplies a key in the JSON string as "", findCreatorProperty will match that key and it will select the CreatorProperty corresponding to JavaScriptConfig. For example, an attacker can supply the corresponding segment of the JSON to inject configuration settings into JavaScriptConfig:

Jackson is responsible for injecting org.apache.druid.js.JavaScriptConfig into _propertyLookup. The _deserializeUsingPropertyBased method mentioned earlier is called by deserializeFromObjectUsingNonDefault method from the BeanDeserializerBase class, where the _propertyLookup is stored in _propertyBasedCreator HashMap. The BeanDeserializerBase#deserializeFromObjectUsingNonDefault method gets called from BeanDeserializer#deserializeFromObject, where the HashMap is stored in _propertyBasedCreator. Ultimately in the SettableBeanPropery class, the _propertyBasedCreator is assigned to the _valueTypeDeserializer HashMap. According to Jackson documentation, the _valueTypeDeserializer hashmap contains type information and this is the type deserializer used to handle type resolution.

After extracting the corresponding CreatorProperty of the JavascriptConfig, JavaScriptDimFilter checks if the JavaScript execution is enabled. Finally, it executes the JavaScript. The following code shows JavaScriptDimFilter checking if the JavaScript is enabled or not:

         Preconditions.checkState(this.config.isEnabled(), "JavaScript is disabled");

Therefore, an attacker is able to set the JavaScriptConfig to enable JavaScript execution by sending an empty ("") name when the type is set to JavaScript. The value of the empty name is then parsed and applied to the configuration of JavaScriptDimFilter class. The attacker can then send arbitrary JavaScript as the value of the function key.

A remote attacker can exploit this vulnerability by sending an HTTP request containing crafted JSON data in the request body. Successful exploitation can result in the execution of arbitrary code with the privileges of the vulnerable server.

Source Code Walkthrough

The following code snippet was taken from Apache Druid version 0.19.0. Comments added by Trend Micro have been highlighted.

From org.apache.druid.query.filter.JavaScriptDimFilter:

From com.fasterxml.jackson.databind.deser.BeanDeserializer:

From com.fasterxml.jackson.databind.deser.impl.PropertyBasedCreator:

From com.fasterxml.jackson.databind.deser.BeanDeserializerBase:

From com.fasterxml.jackson.databind.jsontype.impl.AsPropertyTypeDeserializer:

Conclusion

The Apache Druid team has addressed this vulnerability and recommends users update to version 0.20.1. They also recommend network access to cluster machines be restricted to trusted hosts only. Publicly available proof-of-concept code has been released for this bug, so administrators should upgrade to a non-affected version of Druid as soon as possible.

Special thanks to Pengsu Cheng and Prosenjit Sinha of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit http://go.trendmicro.com/tis/.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the ZDI team for the latest in exploit techniques and security patches.

CVE-2021-25646: Getting Code Execution on Apache Druid

CVE-2021-27076: A Replay-Style Deserialization Attack Against SharePoint

An attacker is frequently in the position of having to find a technique to evade some data integrity measure implemented by a target. One instructive example of a data integrity measure is a message authentication check. Generally, message authentication is achieved by appending some form of a cryptographic tag to a message. Calculating the correct value for the tag is possible only with knowledge of a secret key held by the legitimate sender. When the target receives a message, the target can check that the tag has been calculated correctly. A correct calculation proves that the message was authorized by the legitimate sender.

An attacker who wishes to concoct some other message and convince the target that it was authorized by the sender faces a challenge. Typically, the attacker cannot calculate the proper tag that must be appended, because the attacker is not in possession of the secret key.

In such a circumstance, what are the attacker’s options? An important realization is this: While the attacker herself does not know the secret key, there is at least one actor in the picture who does, namely, the legitimate sender. Perhaps the attacker can interact with the sender in such a way that the sender will be influenced to authorize the very message that the attacker wishes to send to the target (or one close enough).

Naturally, a system will not be designed in such a way that an attacker can ask directly to have an arbitrary message authorized. That would defeat the entire purpose of including an authorization code in the system’s design. On the contrary, the sender is presumably designed to authorize only those messages that it intends the target to accept as authentic. Nevertheless, there is an insidious and underappreciated danger lurking within this very common security design pattern we have just described.

The essence of the problem is centered on the word “intends” in the previous paragraph. For a secure system, what we really need is for the recipient to be able to prove that the sender has a particular intent. In reality, what we have is a cryptographic scheme that proves that the sender has emitted a message consisting of a particular sequence of bits. Is this good enough? The answer depends upon how precisely the sender’s intent can be inferred from the binary message.

Let us make this clear with a concrete example. Here, “Bob” and “Alice” are two legitimate actors. They could be automated systems, or they could be humans communicating over an electronic medium. Suppose that, in the course of an exchange, Bob asks Alice whether Alice wishes to proceed with a particular transaction. Alice replies “YES” and appends a cryptographic tag, proving that Alice authorizes the message that says “YES”. Bob receives the “YES” message together with the tag, verifies that the tag has been calculated correctly, and concludes that Alice has authorized proceeding with the transaction.

This conclusion is on shaky ground, though. When we look a bit more closely, we can easily see that all that Bob can really conclude is that Alice has said “YES” to someone, sometime, in regard to something. Bob is not really justified in concluding anything about Alice’s intent.

An attacker can exploit this as follows. First, the attacker records Alice’s “YES” response, in some context, perhaps an inconsequential one. Alice’s “YES” is accompanied by a valid message authorization code, calculated by Alice herself (or Alice’s equipment). Later, the attacker replays Alice’s “YES” response, together with the valid code, convincing Bob that Alice has said “YES” in an entirely different context (or perhaps simply at a later date). The essential problem is that Alice’s “YES” response does not contain enough information to uniquely identify her intent.

Interestingly, the FCC has warned that scammers have been executing an attack following this exact pattern, by eliciting a verbal “yes” from human victims over the phone. In this instance, no cryptographic authenticators are in use. Rather, an individual’s unique voice is the basis for authenticating messages.

For an example of an attack of this nature against an automated system using cryptographic message authentication, see Michal Zalewski’s ASP.NET VIEWSTATE bug CVE-2005-1664 (variant 1a).

Attacks of this sort are known as replay attacks since they involve replaying a response generated by a legitimate actor in a context not intended by that actor. The different context might simply be a later time, or it might involve taking the message out of its intended context in some more sophisticated fashion.

Attacking SharePoint Session

The above introduction will help us appreciate the nature of a rather amazing attack against SharePoint, submitted to us by an anonymous researcher and given the identifiers ZDI-21-276 / CVE-2021-27076.

In the implementation of SharePoint’s InfoPath functionality, documents are serialized and stored in session state. From there, they may be retrieved by key (editingSessionId) and deserialized. Relevant code outtakes are as follows:

Data read from session state is ultimately passed to BinaryFormatter.Deserialize. If an attacker can specify arbitrary data here, code execution can result.

The challenge facing the attacker here is somewhat similar to the scenario described above in regard to message authentication. The difference is that, in this case, what stands in the attacker’s way is not a cryptographic authentication code, but rather the fact that the attacker has no access to session state and cannot place arbitrary data there at will.

As above, though, the attacker still has an available option. While the attacker has no direct control over the contents of session state, there is another actor present that does: namely, the SharePoint application itself. Perhaps the SharePoint application can be influenced to place the attacker’s chosen data into session state?

Surely there is no direct way to accomplish this, as it would be folly to design an application in such a way that an untrusted user can make arbitrary modifications to session state. Rather, all edits to session state are moderated through the application itself, so that anything that ends up in session state is, in effect, authorized by the application to reside there.

This is the point where the thorny problem of intent rears its head. Though the SharePoint application would not place into session state arbitrary user-supplied data with the intent of that data being read back by the deserialization mechanism, it remains within the realm of possibility that SharePoint could be influenced to place such data there with some alternative intent. In fact, that turns out to be the case. SharePoint also uses the session state mechanism to store arbitrary user-supplied files during attachment upload operations. This is at the core of the vulnerability, though there is still more for us to explain.

Under normal operating conditions, these two different types of data in session state never mix. Each blob added to session state is stored under a unique key (as in the editingSessionId variable discussed above). During attachment upload operations, data is normally retrieved from session state using the key corresponding to a data item that was placed there with the intent of it being used in attachment upload operations. Similarly, during DocumentSessionState deserialization operations, data is normally retrieved using a key that corresponds to a data item that was placed into session state with the intent of it being used in DocumentSessionState deserialization. Hence nothing untoward happens during typical operations.

The next piece of the vulnerability is that the editingSessionId can be influenced from the client side. By replacing one key value for another on the client side, it becomes possible to influence the server to retrieve data from session state placed there with one intent (attachment upload), and replay it in a different context, so that it enters the DocumentSessionState deserialization code path.

There is one final difficulty for the attacker. When uploading an attachment, the corresponding session state key is not visible from the client side. It is present only on the server side, within the DocumentSessionState object. Our anonymous researcher solved this problem by performing an additional attack in the reverse direction: feeding the document’s state key into the attachment mechanism, so that the server replays a serialized DocumentSessionState as an attachment and returns it to the client. Within the serialized bytes, the state key of the attachment can be found.

The final exploit is highly reliable but has numerous steps. We present a simplified version below:

  1. Create an InfoPath list.
  2. Begin adding a new item to the list.
  3. Attach a file to the item. The file contains a fake InfoPath DocumentSessionState including arbitrary objects to be deserialized. The file’s extension can be set to anything InfoPath allows for extensions, for example, .png. After attaching this file, do not save the form.
  4. Scrape the document’s state key from the page’s HTML.
  5. Feed the document’s state key to the FormServerAttachments.aspx page, maliciously replaying the DocumentSessionState into the attachment mechanism. The entire serialized DocumentSessionState is returned to the client as if it were an attached file.
  6. From within the returned data, extract the state key of the attachment added in step 3.
  7. Feed the attachment’s state key into an undocumented client-side API, maliciously replaying the attachment into the deserialization mechanism. Remote code execution is achieved when the arbitrary objects present in the attachment are deserialized on the server.

Microsoft patched this vulnerability in March as CVE-2021-27076. All supported versions of SharePoint Server, including Microsoft Business Productivity Servers 2010 Service Pack 2, are affected by this vulnerability. We recommend applying the patch to affected systems.

Conclusion

Correct system design hinges upon the proper interchange of messages. It is well understood that cryptographic techniques such as message authentication codes are needed to assure the integrity of data in transit, and that access control is required to assure the integrity of data at rest, which we may think of as messages generated by a system to be consumed later by the same system. When applying these security techniques, however, it is also crucial to keep in mind the semantics of how the data will be consumed. Even where the integrity of binary data itself is assured by the application of appropriate security measures, the security of the system as a whole may nonetheless be compromised if an attacker can alter some context that affects how the data is ultimately interpreted.

You can find me on Twitter at @HexKitchen, and follow the team for the latest in exploit techniques and security patches.

CVE-2021-27076: A Replay-Style Deserialization Attack Against SharePoint

The Battle Between White Box and Black Box Bug Hunting in Wireless Routers

11 March 2021 at 17:25

Last year, we disclosed two authentication bypass vulnerabilities, ZDI-20-1176 (ZDI-CAN-10754) and ZDI-20-1451 (ZDI-CAN-11355), affecting multiple NETGEAR products. Both of the vulnerabilities resided in the mini_httpd webserver. These vulnerabilities were discovered by an anonymous researcher and the researcher known as 1sd3d (Viettel Cyber Security) respectively. Both of the vulnerabilities share a similar root cause and are located very closely to one another. However, the two researchers identified the same vulnerabilities in two different groups of routers, and each researcher exploited the vulnerabilities differently. Because of this, it is interesting to compare and contrast how these researchers approached the same problem and to speculate how they reached the final goal of a viable exploit through different paths.

The Vulnerabilities

Thanks to the requirements of the GNU General Public License (GPL), NETGEAR has published the source code of their firmware. These two vulnerabilities can be understood in the most straightforward fashion by analyzing the GPL release of the firmware provided by NETGEAR. In this blog post, we’ll analyze GPL firmware version 1.0.0.72 of the NETGEAR R6120 router. If you also want to poke around, you can find the firmware from the vendor website.

Based on the firmware source code, we can tell the webserver is based on version 1.24 of the mini_httpd open-source project. The vulnerabilities reside in the code bolted on by NETGEAR and therefore do not affect the upstream open-source web server.

The main() function is located in mini_http.c. This function is responsible for setting up the Berkeley-style sockets, SSL, and the listen-loop. To handle concurrent HTTP requests, the webserver forks itself when a TCP connection is received to handle each connection individually in a sub-process. Here is the edited main() function of mini_http from GPL firmware source code from NETGEAR:

The handle_request() function starting at line 1502 then takes over and handles all HTTP processing after the forking.

The function first initializes some variables and proceeds to read in the request line of an HTTP request from the socket at line 1608 using the helper function get_request_line(). The handle_request() function then proceeds to use strpbrk() to separate the HTTP request method from the request line. The rest of the request line is stored in the variable named path at line 1611 and the function continues to process the request path and the request.

Things become interesting starting from line 2106, where the multi-condition if-statement first checks if the path matches one of the strings in array no_check_passwd_paths. This is defined at line 409 with path_exists() (defined in sc_util.c). The if-statement also checks if the path variable contains the substring “PNPX_GetShareFolderList”. If either of the conditions are met, the need_auth variable is set to 0. The need_auth variable does exactly what it advertises. When set to 0, the authentication will be skipped. The following snippet shows how the no_check_passwd_paths array of strings is defined:

The astute reader should have spotted the vulnerability by now. From main() to handle_request(), the program never handled a case where there are request parameters that are part of the request line. If an attacker sends an HTTP request with a request parameter that contains any of the strings in the no_check_passwd_paths array, the attacker can satisfy the if-condition defined at line 2106 and bypass authentication.

Proof of Concept (PoC) and Exploitation

The anonymous researcher had provided a simple PoC to demonstrate the vulnerability (ZDI-20-1176):

This PoC allows the attacker to view the post-authentication page passwordrecovered.htm without authentication. This PoC can be tested by simply navigating to the above path in a browser.

Finally, the researcher provided an additional PoC that allows the attacker to view the router admin password to gain full control of the device in the report.

For ZDI-20-1451, the researcher (1sd3d) noticed that the program actually had not yet parsed out the HTTP version in the path variable, and the naïve strstr() will match with “PNPX_GetShareFolderList” if they simply append it to the end of the HTTP version in a request and satisfy the if-condition defined at line 2110 to bypass authentication.

1sd3d then chained this vulnerability with a post-authenticated command injection ZDI-20-1423 (ZDI-CAN-11653) to gain full control of the device.

White Box vs Black Box

The anonymous report approached the bug from a white box code-audit side, while 1sd3d’s report approached it from a black box reverse engineering using Ghidra and its decompiler. With this in mind, we can speculate on why they exploited the vulnerabilities differently and found the vulnerabilities in different sets of routers.

The vulnerable code for ZDI-20-1451 is wrapped within an #ifdef PNPX preprocessor directive. When approached from the white box side, it is hard to tell if the PNPX directive was defined at compile time. It is possible that the vulnerable code is not compiled into the final firmware. In fact, this code was indeed not compiled into the firmware for the NETGEAR R6120 wireless router.

Writing a script to look for the vulnerable source code pattern of ZDI-20-1176 is therefore a more reliable way to find exploitable firmware when working with GPL source code. Naturally, the anonymous researcher chose to take advantage of the no_check_passwd_paths array that is not wrapped in any preprocessor directive to proceed with exploitation.

When approached from the black box RE side, what you see is what the CPU sees. However, goto statements, de Morgan’s Law, and lack of variable names can often obscure the logic of vulnerabilities in decompiled code. ZDI-20-1451 was the more apparent of the two vulnerabilities when inspected in the researcher’s decompiled code.

Decompiled code view of the NETGEAR R7450 firmware in Ghidra from submitter’s report.

Decompiled code view of the NETGEAR R7450 firmware in Ghidra from submitter’s report.

The rather unique “PNPX_GetShareFolderList” string makes searching for the same vulnerability across the firmware of different devices easier. Running the binary through strings and searching for the string should give good enough accuracy. Writing a script to search for ZDI-20-1176 in a disassembler will definitely require some scripting wizardry.

Conclusion

Each method has its advantages and blind spots. In this specific case, they both arrived at the same destination but took different approaches when it came to exploitation. This demonstrates how no one method is superior. However, it is possible only one method may take you further in your next bug hunting journey. That said, being proficient in both can only be beneficial in the long term.

In a world of move fast, break things, and deadline driven product development, NETGEAR developers should have done a better job in code review before this flaw was shipped. The declaration of no_need_check_password_page local variable in the latter part of the code in addition to the need_auth variable does not instill confidence in the code. Luckily, it seems that NETGEAR is moving away from this tech debt-laden codebase in newer products and firmware.

Footnote

 It is often possible to deduce research methodology from vulnerability reports. One important caveat is that the researchers may have decided to omit their black box or white box work from their submission for clarity and render the entire comparison in the blog moot. If that were the case, at least you have learned something about two router bugs.

You can find me on Twitter @TrendyTofu, and follow the team for the latest in exploit techniques and security patches.

The Battle Between White Box and Black Box Bug Hunting in Wireless Routers

The March 2021 Security Update Review

9 March 2021 at 18:31

It’s the third second Tuesday of the year, which means we get the latest security updates from Adobe and Microsoft. Take a break from your regularly scheduled activities and join us as we review the details for their latest security offerings.

Adobe Patches for March 2021

For March, Adobe released three patches covering eight CVEs in Adobe Connect, Creative Cloud Desktop, and Framemaker. Two of these CVEs came through the ZDI program. The update for Framemaker fixes a single Out-of-Bounds (OOB) read vulnerability that could lead to remote code execution. The update for Creative Cloud addresses three different Critical-rated CVEs. Two of these bugs could lead to code execution while the third could allow a privilege escalation. The final Adobe patch for March covers one Critical and three Important-rated vulnerabilities in Adobe Connect. The Critical-rated bug could lead to arbitrary code execution while the other bugs addressed are all reflective cross-site scripting (XSS) bugs). None of the issues addressed by Adobe are listed as publicly known or under active attack at the time of release.

Updated March 10:

After the initial release, Adobe also shipped patches for PhotoShop and Animate to address nine additional CVEs. The Animate patch fixes two Critical and five Important-rated bugs. The Critical bugs are buffer overflows that could allow code execution while the Important-rated bugs could allow information disclosure. The patch for PhotoShop addresses two Critical rated bugs that could allow code execution. None of the issues are listed as publicly known or under active attack at the time of release.

Microsoft Patches for March 2021

Microsoft started the March patch cycle early by shipping an emergency patch for Exchange last week covering seven unique CVEs. Four of these bugs are listed as under active attack, which is why the patch was released outside the normal, patch Tuesday cycle. There has already been a mountain of information published about these vulnerabilities, so I won’t cover the bugs in more detail here. However, if you run Exchange on-premise, you need to follow the published guidance and apply the patches as soon as possible. Microsoft has even taken the extraordinary step of creating patches for out-of-support versions of Exchange. Ignore these updates at your own peril.

For all of March, Microsoft released patches for 89 unique CVEs covering Microsoft Windows components, Azure and Azure DevOps, Azure Sphere, Internet Explorer and Edge (EdgeHTML), Exchange Server, Office and Office Services and Web Apps, SharePoint Server, Visual Studio, and Windows Hyper-V. These 89 CVEs include the seven Exchange CVEs released last week. A total of 15 of these bugs came through the ZDI program. Of these 89 bugs, 14 are listed as Critical and 75 are listed as Important in severity. According to Microsoft, two of these bugs are listed as publicly known while five are listed as under active attack at the time of release.

Please note these CVE counts do not include the CVEs patched in the recent update to the Chromium version of the Edge browser. Last week, Version 89 of this browser was released.

 Let’s take a closer look at some of the more interesting updates for this month, starting with the other bug listed as being under active attack:

 -       CVE-2021-26411 – Internet Explorer Memory Corruption Vulnerability
This patch corrects a bug in Internet Explorer (IE) and Edge (EdgeHTML-based) that could allow an attacker to run their code on affected systems if they view a specially crafted HTML file. Microsoft lists this as both publicly known and under active attack at the time of release. While not as impactful as the Exchange bugs, enterprises that rely on Microsoft browsers should definitely roll this out quickly. Successful exploitation would yield code execution at the level of the logged-on user, which is another reminder not to browse web pages using an account with Administrative privileges.

 -        CVE-2021-26897 – Windows DNS Server Remote Code Execution Vulnerability
This is the second straight month with a DNS server RCE vulnerability, and this month’s bug has company. A total of 5 bugs are listed as DNS Server Remote Code Execution Vulnerabilities, but this CVE is the only one listed as Critical. All note that Secure Zone Updates lessen the likelihood of successful exploitation but are not a full mitigation. This implies dynamic updates may be involved in the exploitation of these bugs. All five of these bugs are listed as a CVSS 9.8, and there is the outside chance this could be wormable between DNS servers. Definitely prioritize the testing and deployment of these updates.

 -       CVE-2021-26867 – Windows Hyper-V Remote Code Execution Vulnerability
This bug could allow an authenticated attacker to execute code on the underlying Hyper-V server. While listed as a CVSS of 9.9, the vulnerability is really only relevant to those using the Plan-9 file system. Microsoft does not list other Hyper-V clients as impacted by this bug, but if you are using Plan-9, definitely roll this patch out as soon as possible.

 -       CVE-2021-27076 – Microsoft SharePoint Server Remote Code Execution Vulnerability
This patch fixes a code execution bug originally submitted through the ZDI program. For an attack to succeed, the attacker must be able to create or modify Sites with the SharePoint server. However, the default configuration of SharePoint allows authenticated users to create sites. When they do, the user will be the owner of this site and will have all the necessary permissions. This is similar to some other SharePoint bugs we have blogged about in the past, and we’ll have additional details about this vulnerability on our blog in the near future.

Here’s the full list of CVEs released by Microsoft for March 2021.

CVE Title Severity CVSS Public Exploited DOS
CVE-2021-26411 Internet Explorer Memory Corruption Vulnerability Critical 8.8 Yes Yes RCE
CVE-2021-26855 Microsoft Exchange Server Remote Code Execution Vulnerability Critical 9.1 No Yes RCE
CVE-2021-26857 Microsoft Exchange Server Remote Code Execution Vulnerability Critical 7.8 No Yes RCE
CVE-2021-27065 Microsoft Exchange Server Remote Code Execution Vulnerability Critical 7.8 No Yes RCE
CVE-2021-26858 Microsoft Exchange Server Remote Code Execution Vulnerability Important 7.8 No Yes RCE
CVE-2021-27077 Windows Win32k Elevation of Privilege Vulnerability Important 7.8 Yes No EoP
CVE-2021-27074 Azure Sphere Unsigned Code Execution Vulnerability Critical 6.2 No No RCE
CVE-2021-27080 Azure Sphere Unsigned Code Execution Vulnerability Critical 9.3 No No RCE
CVE-2021-21300 Git for Visual Studio Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2021-24089 HEVC Video Extensions Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2021-26902 HEVC Video Extensions Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2021-27061 HEVC Video Extensions Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2021-26412 Microsoft Exchange Server Remote Code Execution Vulnerability Critical 9.1 No No RCE
CVE-2021-26876 OpenType Font Parsing Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2021-26897 Windows DNS Server Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2021-26867 Windows Hyper-V Remote Code Execution Vulnerability Critical 9.9 No No RCE
CVE-2021-26890 Application Virtualization Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-27075 Azure Virtual Machine Information Disclosure Vulnerability Important 6.8 No No Info
CVE-2021-24095 DirectX Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2021-24110 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-27047 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-27048 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-27049 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-27050 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-27051 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-27062 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-27085 Internet Explorer Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-27053 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-27054 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-26854 Microsoft Exchange Server Remote Code Execution Vulnerability Important 6.6 No No RCE
CVE-2021-27078 Microsoft Exchange Server Remote Code Execution Vulnerability Important 9.1 No No RCE
CVE-2021-27058 Microsoft Office ClickToRun Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-24108 Microsoft Office Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-27057 Microsoft Office Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-27059 Microsoft Office Remote Code Execution Vulnerability Important 7.6 No No RCE
CVE-2021-26859 Microsoft Power BI Information Disclosure Vulnerability Important 7.7 No No Info
CVE-2021-27056 Microsoft PowerPoint Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-27052 Microsoft SharePoint Server Information Disclosure Vulnerability Important 5.3 No No Info
CVE-2021-27076 Microsoft SharePoint Server Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-24104 Microsoft SharePoint Spoofing Vulnerability Important 4.6 No No Spoof
CVE-2021-27055 Microsoft Visio Security Feature Bypass Vulnerability Important 7 No No SFB
CVE-2021-26887 Microsoft Windows Folder Redirection Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-26881 Microsoft Windows Media Foundation Remote Code Execution Vulnerability Important 7.5 No No RCE
CVE-2021-27082 Quantum Development Kit for Visual Studio Code Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-26882 Remote Access API Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-27083 Remote Development Extension for Visual Studio Code Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-26880 Storage Spaces Controller Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-26886 User Profile Service Denial of Service Vulnerability Important 5.5 No No DoS
CVE-2021-27081 Visual Studio Code ESLint Extension Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-27084 Visual Studio Code Java Extension Pack Remote Code Execution Vulnerability Important Unlisted No No RCE
CVE-2021-27060 Visual Studio Code Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-27070 Windows 10 Update Assistant Elevation of Privilege Vulnerability Important 7.3 No No EoP
CVE-2021-26869 Windows ActiveX Installer Service Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-27066 Windows Admin Center Security Feature Bypass Vulnerability Important 4.3 No No SFB
CVE-2021-26860 Windows App-V Overlay Filter Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-26865 Windows Container Execution Agent Elevation of Privilege Vulnerability Important 8.8 No No EoP
CVE-2021-26891 Windows Container Execution Agent Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-26896 Windows DNS Server Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2021-27063 Windows DNS Server Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2021-26877 Windows DNS Server Remote Code Execution Vulnerability Important 9.8 No No RCE
CVE-2021-26893 Windows DNS Server Remote Code Execution Vulnerability Important 9.8 No No RCE
CVE-2021-26894 Windows DNS Server Remote Code Execution Vulnerability Important 9.8 No No RCE
CVE-2021-26895 Windows DNS Server Remote Code Execution Vulnerability Important 9.8 No No RCE
CVE-2021-24090 Windows Error Reporting Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-26872 Windows Event Tracing Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-26898 Windows Event Tracing Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-26901 Windows Event Tracing Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-24107 Windows Event Tracing Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-26892 Windows Extensible Firmware Interface Security Feature Bypass Vulnerability Important 6.2 No No SFB
CVE-2021-26868 Windows Graphics Component Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-26861 Windows Graphics Component Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-26862 Windows Installer Elevation of Privilege Vulnerability Important 6.3 No No EoP
CVE-2021-26884 Windows Media Photo Codec Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-26879 Windows NAT Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2021-26874 Windows Overlay Filter Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-1640 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-26878 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-26870 Windows Projected File System Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-26866 Windows Update Service Elevation of Privilege Vulnerability Important 7.1 No No EoP
CVE-2021-26889 Windows Update Stack Elevation of Privilege Vulnerability Important 7.1 No No EoP
CVE-2021-1729 Windows Update Stack Setup Elevation of Privilege Vulnerability Important 7.1 No No EoP
CVE-2021-26899 Windows UPnP Device Host Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-26873 Windows User Profile Service Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2021-26864 Windows Virtual Registry Provider Elevation of Privilege Vulnerability Important 8.4 No No EoP
CVE-2021-26871 Windows WalletService Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-26885 Windows WalletService Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-26863 Windows Win32k Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2021-26875 Windows Win32k Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-26900 Windows Win32k Elevation of Privilege Vulnerability Important 7.8 No No EoP

Moving on to the remaining Critical-rated patches, two affect Azure Sphere, but you likely won’t need to take any action. Devices running Azure Sphere are connected to the Internet receive automatic updates. If your devices are isolated, you should make sure these updates are applied. There are four patches to correct bugs in the HEVC Video Extensions, and these updates are available from the Windows Store. There’s a patch for a bug in OpenType Fonts that could be exploited by viewing a specially crafted font. Finally, there’s an intriguing update for Git for Visual Studio that fixes a bug that requires no privileges but some level of user interaction. The attack complexity is also listed as low, so we may hear more about this vulnerability in the future.

Shifting to the Important-rated patches, there are still a bunch of code execution bugs to look at. In fact, 45 of the 90 bugs patched this month are listed as some form of remote code execution. Many of the affected components have matching Important updates to go with their Critical counterparts. These include Exchange, DNS Server, HVEC Video Extensions, and IE. This month’s release included five RCE bugs impacting Visual Studio. Most are straightforward, however, the update for the Quantum Development Kit for Visual Studio must be manually downloaded. This can be done through the extensions page within Visual Studio. There are also the expected updates for Office and Office components. Similar to last month, users of Microsoft Office 2019 for Mac will need to wait for their update to be made available.

Looking at the 30 Elevation of Privilege (EoP) bugs addressed in this month’s release, most require an attacker to log on to an affected system and run specially crafted code to escalate privileges. Almost all of these patches impact the Windows kernel and various Windows components. One bug to note had previously been disclosed by ZDI as Microsoft stated it did not meet their bar for servicing. At some point after we published our advisory, Microsoft changed course and produced a patch to address this issue. We’re glad they changed their mind.

This month’s release includes patches for six information disclosure bugs. Usually, these types of cases only lead to leaks consisting of unspecified memory contents. That’s true for three of these bugs, but the others leak some significant info. The vulnerability in Azure Virtual Machine could allow a low-privileged user to gain virtual machine credentials as well as credentials to extensions associated with the virtual machine. Speaking of credentials, the bug in Microsoft Power BI could expose NTLM hashes, which could then be brute-forced to reveal plaintext passwords. Finally, according to the Microsoft write-up, the info leak in SharePoint Server could allow an attacker access to an “organizational's email, sites, filename, url of file...” There’s nothing more than this generic description listed, but assume valuable information could be exposed by an attacker.

Three components receive patches to fix security feature bypasses (SFB) this month. The bypasses for Windows Extensible Firmware Interface and the Windows Admin Center receive patches but no documentation. The SFB for Visio does get some additional information, but the attack scenario seems far from common. Systems would be affected only with a specific Group Policy Object. An attacker would still need to modify a macro-enabled template that ships with Excel. If those two conditions occur and the user runs a malicious file on a system affected by that Group Policy, some form of bypass can occur. Based on the write-up, it doesn’t read like imminent danger, but still probably best to roll out the patch.

This month’s release is rounded out by four denial-of-service (DoS) bugs and a spoofing vulnerability. The spoofing bug occurs in the SharePoint server, but no further information is provided. Two of the DoS bugs impact the DNS Server service, and they have the same caveats as the previously mentioned code execution bugs. There’s also a DoS in the NAT Server service. For these bugs, it’s not clear if the service can just be restarted or if a full system reboot is required. The final DoS was reported through the ZDI program, but it doesn’t impact a service. Instead, it notes a bug in the User Profile Service. By creating a junction, an attacker can abuse the service to overwrite the contents of a chosen file, thus creating a DoS condition.

Finally, the servicing stack advisory (ADV990001) was revised for multiple versions of Windows. No additional advisories were released this month.

Looking Ahead

The next Patch Tuesday falls on April 13, and we’ll return with details and patch analysis then. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

The March 2021 Security Update Review

CVE-2020-3992 & CVE-2021-21974: Pre-Auth Remote Code Execution in VMware ESXi

2 March 2021 at 16:00

Last fall, I reported two critical-rated, pre-authentication remote code execution vulnerabilities in the VMware ESXi platform. Both of them reside within the same component, the Service Location Protocol (SLP) service. In October, VMware released a patch to address one of the vulnerabilities, but it was incomplete and could be bypassed. VMware released a second patch in November completely addressing the use-after-free (UAF) portion of these bugs. The UAF vulnerability was assigned CVE-2020-3992. After that, VMware released a third patch in February completely addressing the heap overflow portion of these bugs. The heap overflow was assigned CVE-2021-21974.

This blog takes a look at both bugs and how the heap overflow could be used for code execution. Here is a quick video demonstrating the exploit in action:

Service Location Protocol (SLP) is a network service that listens on TCP and UDP port 427 on default installations of VMware ESXi. The implementation VMware uses is based on OpenSLP 1.0.1. VMware maintains its own version and has added some hardening to it.

The service parses network input without authentication and runs as root, so a vulnerability in the ESXi SLP service may lead to pre-auth remote code execution as root. This vector could also be used as a virtual machine escape, since by default a guest can access the SLP service on the host.

The Use-After-Free Bug (CVE-2020-3992)

This bug exists only in VMware’s implementation of SLP. Here is the simplified pseudocode:

At (3), if a SLP_FUNCT_DAADVERT or SLP_FUNCT_SRVREG request is handled correctly, it will save the allocated SLPMessage into the database. However, at (4), the SLPMessage is freed even though the handled request returns without error. It leaves a dangling pointer in the database. It is possible the free at (4) was added in the course of fixing some older bugs.

Bypassing the First Patch for CVE-2020-3992

The first patch (build-16850804) by VMware was interesting. VMware didn’t make any changes to the vulnerable code shown above. Instead, they added logic to check the source IP address before handling the request. The logic, which is in IsAddrLocal(), allows requests from a source IP address of localhost only.

After a few seconds, you might notice that it can still be accessed from an IPv6 link-local address via the LAN.

The Second Patch for CVE-2020-3992

Just over two weeks later, the second patch (build-17119627) was released. This time, they improved the IP source address check logic.

This change does eliminate the IPv6 vector. Additionally, they patched the root cause of the UAF bug by clearing the pointer to the SLPMessage after adding it to the database.

The Heap Overflow Bug (CVE-2021-21974)

Like the previous bug, this bug exists only in VMware’s implementation of SLP. Here is the simplified pseudocode:

At (5), srvurl comes from network input, but the function does not terminate srvurl with a NULL byte before using strstr(). The out-of-bounds string search leads to a heap overflow at (6). This happened because VMware did not merge an update from the original OpenSLP project.

The Patch for CVE-2021-21974

Six weeks later, the third patch (build- 17325551) was released. It addressed the root cause of the heap overflow bug by checking the length before the memcpy at (6).

Exploitation

All Linux exploit mitigations are enabled for /bin/slpd, and most notably, Position Independent Executables (PIE). This makes it difficult to achieve code execution without first disclosing some addresses from memory. At first, I considered using the UAF, but I could not figure out an effective method to get a memory disclosure. Therefore, I moved my focus to the heap overflow bug instead.

Upgrading the Overflow

SLP uses struct SLPBuffer to handle events that it sends and receives. One SLPBuffer* sendbuf and one SLPBuffer* recvbuf are allocated for each SLPDSocket* connection.

The plan is to partially overwrite the start or curpos pointer in SLPBuffer and leak some memory on the next message reply. However, the sendbuf is emptied and updated before each reply. Fortunately, there is a timeslot during which sendbuf can survive due to the select-based socket model:

  1. Fill a socket send buffer without receiving until the send buffer is full.
  2. Partially overwrite sendbuf->curpos for that socket.
  3. Start to receive from the socket. The leaked memory will be appended at the end.

There are some additional challenges, though:

       -- Due to the use of strstr(), you cannot overflow with a NULL byte.
       -- The overflowed buffer (obuf) will be automatically freed very soon after the return of SLPParseSrvUrl().

Together, this means that the overwrite can only extend partway through the next chunk header. Otherwise, the size of the next free chunk will be set to a very large value (four non-NULL bytes), and shortly after obuf is freed, the process will abort.

The following layout overcomes these challenges:

layout3.PNG

Assume that the target is sendbuf. In (F1), each chunk marked “IN USE” can be either a SLPBuffer or a SLPDSocket. A hole is prepared for obuf in (F2). After triggering the overflow in (F4), the next freed chunk is enlarged and overlapped onto the target. Next, obuf is then freed in (F5). Now, you can allocate a new recvbuf from a new connection to overwrite the target in (F6). This time the overwrite can include NULL bytes.

There is an additional problem:

       -- Many malloc() functions from OpenSLP are replaced with calloc() by VMware.

The recvbuf in (F6) is also allocated from calloc(), which zero-initializes memory. This means that partial pointer overwrites are not possible when recvbuf overlaps the target. There is a trick to get around that, though: You can first overwrite the IS_MAPPED flag on the freed chunk in (F4). This causes calloc() to skip the zero initialization on the next allocation. This is a general method that is useful in many situations where you want to perform an overwrite on target.

Putting It All Together

  1. Overwrite a connection state (connection->state) as STREAM_WRITE_FIRST. This is necessary so that sendbuf->curpos will get reset to sendbuf->start in preparation for the memory disclosure.
  2. Partially overwrite sendbuf->start with 2 NULL bytes, where sendbuf belongs to the connection mentioned in step 1. Start receiving from the connection. You can then get memory disclosure, including the address of sendbuf.
  3. Overwrite sendbuf->curpos from a new connection to leak the address of a recvbuf, which is allocated from mmap(). Once you have an mmapped address, it becomes possible to infer the libc base address.
  4. Overwrite recvbuf->curpos from a new connection, setting it to the address of free_hook. Start sending on the connection. You can then overwrite free_hook.
  5. Close a connection, invoking free_hook to start the ROP chain.

These steps may not be the optimized form.

Privilege Level Obtained

If everything goes fine, you can execute arbitrary code with root permission on the target ESXi system. In ESXi 7, a new feature called DaemonSandboxing was prepared for SLP. It uses an AppArmor-like sandbox to isolate the SLP daemon. However, I find that this is disabled by default in my environment.

This suggests that a sandbox escape stage will be required in the future.

Conclusion

VMware ESXi is a popular infrastructure for cloud service providers and many others. Because of its popularity, these bugs may be exploited in the wild at some point. To defend against this vulnerability, you can either apply the relevant patches or implement the workaround. You should consider applying both to ensure your systems are adequately protected. Additionally, VMware now recommends disabling the OpenSLP service in ESXi if it is not used.

We look forward to seeing other methods to exploit these bugs as well as other ESXi vulnerabilities in general. Until then, you can find me on Twitter @_wmliang_, and follow the team for the latest in exploit techniques and security patches.

CVE-2020-3992 & CVE-2021-21974: Pre-Auth Remote Code Execution in VMware ESXi

CVE-2020-8625: A Fifteen-Year-Old RCE Bug Returns in ISC BIND Server

25 February 2021 at 17:30

In October 2020, we received a submission from an anonymous researcher targeting the ISC BIND server. The discovery was based upon an earlier vulnerability, CVE-2006-5989, which affected the Apache module mod_auth_kerb and was initially found by an anonymous researcher. The ISC BIND server shared the vulnerable code within the Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO) component, but ISC did not merge the patch at that time. After 15 years, ISC patched the bug in BIND and assigned it CVE-2020-8625.

This vulnerability affects BIND versions from 9.11 to 9.16. It can be triggered remotely and without authentication. It leads to a 4-byte heap overflow. This submission was close to earning a larger payout through our Targeting Incentive Program, but lacked the full exploit needed to qualify for the full award. Still, it’s a great submission, and the bug is worth looking in greater detail.

The Vulnerability

The heap overflow bug exists in function der_get_oid(), which is in lib/dns/spnego.c.

This function allocates an array buffer at (1). The variable len is used to keep track of the number of available elements remaining in the buffer. The code fills the first 2 elements at (2), but it only decreases len by 1 at (3). As a result, the loop (4) can overflow the buffer by 1 element. The type of data->components is int, so we have a 4-byte heap overflow.

The Trigger

Since the vulnerability exists within the SPNEGO component, TKEY-GSSAPI configuration is necessary in BIND.

The dns.keytab file can be found in bin/tests/system/tsiggss/ns1/, and the example.nil.db file is generated by the script bin/tests/system/tsiggss/setup.sh.

Now the environment is ready. Upon receiving a crafted request, the vulnerability is triggered, producing the following call stack:

Exploitation

The exploitability for this bug is highly dependent on the glibc version. The following explanation is based on Ubuntu 18.04 with glibc 2.27, which enables tcache support.

First, we have to determine what is under control from this overflow bug.

       -- The size and content of the vulnerable buffer, which is allocated in der_get_oid(), is controllable. By the way, the buffer will be freed when the current request is done.
       -- There is a while loop in decode_MechTypeList() to execute der_get_oid() repeatedly. The loop count is controllable.

With these two points in mind, we can manipulate the heap fairly easily. To prepare the heap, we can exhaust tcache bins of any size and refill them after the request is done. Also, the refilled chunks can be contiguous in memory. This makes the memory layout quite conducive to exploitation via a buffer overflow.

Arbitrary write

At this stage, achieving an arbitrary write is straightforward by abusing the tcache freelist.

  1. Trigger a 4-byte overflow to enlarge the next free chunk size.
  2. Allocate the corrupted chunk on the next request. It will be moved to the new tcache bin when the request is ended.
  3. Allocate the corrupted chunk again with the new size. The corrupted chunk overlaps the next free chunk and overwrites its freelist with an arbitrary value.
  4. Allocate from the poisoned tcache freelist. It will return an arbitrary address.

Attempting to leak an address

All Linux mitigations are enabled by default for BIND. We have to struggle with ASLR first, which means we will need to find a way to leak an address from memory. A possible chance for obtaining a leak is in code_NegTokenArg() function. It is used for encoding response messages into a buffer, which will be sent to the client.

buf at (5) is a temporary buffer. Its initial size is 1024 bytes, which is within the range of sizes handled by tcache. outbuf at (6) is the buffer that will be sent to the client. Its size is within range for tcache also. If it is possible to apply a tcache dup attack on these two buffer sizes, the two malloc() calls at (5) and (6) will return the same address. After the free() at (7), a tcache->next pointer will be updated into buf, which is already overlapped with outbuf. This means a heap pointer will leak to the client.

Ideally, buf_len at (6) should be chosen to be large enough to avoid interfering with small tcache bins. Unfortunately, it seems the maximum value is only about 96 bytes. Due to this problem, the process does not survive and crashes very soon after the client gets the leaked heap pointer. More research is needed to find a way to continue the path to a full exploit.

The Patch

The patched versions are BIND 9.16.12 and BIND 9.11.28. To fix BIND 9.16, ISC fixed the buffer allocation size at (1). In BIND 9.11, they applied the patch as well.

Conclusion

This bug shows how vulnerabilities can reside undetected for years, even when the software is open source and in wide use. Software maintainers need to closely monitor all of the external modules they consume to ensure they stay up to date with the latest patches. It also shows how complex this challenge can be. ISC BIND is the most popular DNS server on the internet. The scope of impact is quite large, especially since the vulnerability can be triggered remotely and without authentication. All are advised to update their DNS servers as soon as possible.

For more information about our Targeted Incentive Program, check out this blog. We hope to see more submissions for this program in the future. Until then, you can find me on Twitter @_wmliang_, and follow the team for the latest in exploit techniques and security patches.

CVE-2020-8625: A Fifteen-Year-Old RCE Bug Returns in ISC BIND Server

ZDI-21-171: Getting Information Disclosure in Adobe Reader Through the ID Tag

18 February 2021 at 17:25

Sometimes the only thing between you and a successful exploit is an information leak. While I see my fair share of information disclosure bugs on the job, it’s not every day that I see one that is so clean and elegant. Then again, it’s not every day I get the privilege of looking at some of  Mark Yason's stellar research. This blog covers one such information leak Mark submitted to the program and recently patched by Adobe.

Let’s talk about  ZDI-21-171, but first, here’s a quick video showing the bug in action.

The Vulnerability

The issue exists due to the way Adobe Reader handles the ID tag within the PDF trailer. The problem is that when processing the array values for the ID tag, the application does not anticipate anything over 0x100 bytes.  With this knowledge and some JavaScript in hand, an attacker can leverage this to disclose the base address of Annots.api.

What exactly are we talking about?

If you pop open a PDF document in an editor, chances are that at the bottom, you’ll see a File Trailer that looks something like this:

Figure 1 - Example PDF Trailer

Figure 1 - Example PDF Trailer

According to Adobe’s documentation, the trailer consists of one or more key-value pairs.

Figure 2 - Adobe’s File Trailer documentation

Figure 2 - Adobe’s File Trailer documentation

The key-value pair of interest is ID, which is “an array of two strings constituting a file identifier for the file.” (See section 9.3, “File Identifiers” in the document referenced above.) Our proof of concept is shown below and contains overly long array values:

Figure 3 - Proof of Concept PDF Trailer

Figure 3 - Proof of Concept PDF Trailer

What happens when the application encounters an ID key in a file trailer? During the parsing of the ID key, Reader will call a function that will return the size of the ID array values and uses that value to populate the following structure:

Figure 4 - Trailer ID Structure

Figure 4 - Trailer ID Structure

This is best illustrated by the following pseudocode:

Figure 5 - Pseudocode to retrieve File ID

Figure 5 - Pseudocode to retrieve File ID

The f_AcroDocGetFileID method returns the actual size of the file ID in the PDF even if the passed buffer argument is NULL and the buffer size argument is smaller than the actual size of the file ID. This value is then used to set the originalIDLen and modifiedIDLen properties without any check if the value is greater than 0x100 bytes.

Following this in the debugger, we can see that the parameters on the stack align with what we’re seeing in the debugger.

Figure 6 - A look at the stack and the returned value

Figure 6 - A look at the stack and the returned value

When the function returns, the structure looks like this:

Figure 7 - Returned stack structure

Figure 7 - Returned stack structure

Note the returned size in @eax. The issue here is that the return value was not checked to determine if it is greater than 0x100 before storing the value in this->originalIDLen and this->modifiedIDLen.

At this point, the structure is setup with invalid length values. This comes into play later with a call to Collab.documentToStream(), which invokes a memcpy call. This is shown below:

Figure 8 - This memcpy leads to an out-of-bounds read

Figure 8 - This memcpy leads to an out-of-bounds read

When the application tries to copy the originalID into a heap-based buffer, it uses the new 0x400 bytes size instead of the expected 0x100 bytes and allows a user to leak data from the stack. The result is a stack-based buffer out-of-bounds read can be leveraged to disclose the base address of Annots.api through the Collab.documentToStream() API call.

Figure 9 - Annots.api base address successfully leaked

Figure 9 - Annots.api base address successfully leaked

Wrapping up

Adobe Reader is a common target for attackers since the PDF format is so ubiquitous. While this blog covers an info disclosure bug, Adobe recently patched this along with other vulnerabilities that could allow remote code execution, including one bug that was being actively exploited. Getting code execution on modern applications typically requires multiple steps, and leaking memory addresses is often the first step towards a full exploit chain. Combine this bug with something that allows code execution and a sandbox escape, and you could have a full compromise. You should definitely apply the security patch to all affected systems as soon as possible.

You can find me on Twitter at @mrpowell and be sure to follow the team for the latest in exploit techniques and security patches.

ZDI-21-171: Getting Information Disclosure in Adobe Reader Through the ID Tag

❌