RSS Security

🔒
❌ About FreshRSS
There are new articles available, click to refresh the page.
☑ ☆ ✇ Zero Day Initiative - Blog

CVE-2021-27077: Selecting Bitmaps into Mismatched Device Contexts

By: Guest Blogger

In March 2021, Microsoft released a patch to correct a vulnerability in the Windows GDI subsystem. The bug could allow an attacker to execute code with escalated privileges. This vulnerability was reported to the ZDI program by security researcher Marcin Wiązowski. The patch for CVE-2021-27077 addresses several of his bug submissions. He has graciously provided this detailed write-up of the vulnerabilities and an analysis of the patch from Microsoft.


To handle devices on which drawing can be performed (pixel-based devices), Windows provides so-called device contexts (DCs). A device context object encapsulates a device object where a device object represents either a screen or a printer. Device contexts are an abstraction layer between user-mode code and low-level device drivers. They also act as containers, referencing various graphic objects used during drawing operations, such as pens, brushes, bitmaps, palettes, regions, and paths. To establish a connection between a device context and some other graphic object, the user-mode code calls SelectObject. For example:

In this example, we create a screen-related device context and three other GDI objects: a region, a font, and a bitmap. By selecting them into the device context, we cause them to be used during the ExtTextOut call below. This call will draw text on our TestBitmap by using our TestFont, and the drawing area will be clipped by our TestRegion.

For us, the important facts about device contexts are:

1 - They can be either screen-related or printer-related.
2 - To reference the screen or printer, each device context internally keeps a handle, referred to as hdev. Internally, a device context object resides in kernel memory, and its hdev field is a pointer to another object residing in kernel memory, this one being a device object.

Bitmaps selected into device contexts

Bitmaps are represented in kernel memory as surface objects. The partial structure definition shown here includes some fields documented by Microsoft, as well as some undocumented fields that have been reconstructed:

As we can see, bitmaps can contain a hdev value. This value is initially set to NULL, but selecting the bitmap into a device context copies the hdev value from the device context to the bitmap’s hdev field.

Now let’s do an experiment:

In this example:

1) We create one printer-related device context (DCPrn) and one screen-related device context (DCScr). For the printer DC, we used the printer named “Microsoft XPS Document Writer” which is available by default, but any installed printer could be used instead. If necessary, the EnumPrinters API could be used to get the names of all installed printers.
2) We create a bitmap (Bitmap). Note that it’s a monochrome (1 bit deep) bitmap, so it’s compatible with any device context. This includes 1-bit or 8-bit printer-related DCs and 32-bit screen-related DCs.
3) We select the bitmap into the printer-related DC. This sets the bitmap’s hdev field so that it points to the printer device object in kernel memory. The variable PrevBitmap is set to the default bitmap that was created together with the printer DC.
4) We deselect our bitmap (by selecting PrevBitmap instead), so we’ll be able to select Bitmap into some other device context again. Bitmaps are specific in that sense. They can be selected into only one device context at a time, so deselecting is required.
5) Finally, we select Bitmap into a screen-related DC. This updates bitmap’s hdev field so that it no longer points to the printer device object, but rather to the screen device object.

This code isn’t malicious, but we’ll make it malicious in the next step. But first, let’s look at some changes that were introduced in Windows 2000.

User-Mode Printer Drivers (UMPD)

Historically, both screens and printers used to be handled by kernel-mode drivers. While there are only a small number of vendors that manufacture graphic cards and write corresponding driver code, the world of printers is quite a different story. Undoubtedly there were plenty of printer manufacturers who introduced numerous security risks and instabilities in their drivers. To make things safer and more stable, Windows 2000 introduced an architecture that allowed printer drivers to work in user mode instead. Both kernel-mode and user-mode printer drivers coexisted until Windows Vista. Since then, Windows has supported only user-mode drivers for printing.

Consequently, only some stubs remained in kernel code for printer handling. These stubs mainly just make callbacks to user mode. In user mode, these calls are first passed to some internal code in user32.dll, then to some more code in gdi32.dll, then to yet more internal code in gdi32full.dll, which finally passes them to user-mode printer drivers for handling:

To provide user-mode drivers with the needed functionalities, some kernel-mode APIs now also have their user-mode API counterparts. One such API is EngAssociateSurface. Display drivers use calls to the kernel-mode function win32kbase.sys!EngAssociateSurface, whereas printer drivers use the user-mode function gdi32.dll!EngAssociateSurface:

For our purposes, we can consider the user-mode EngAssociateSurface function to be an extended version of the SelectObject API. When passing a bitmap as the first parameter, we can set not only the bitmap’s hdev field but also its dhpdev and flags fields. Here are a few things to consider:

1) The hdev parameter will be a valid value obtained from an existing printer-related device context. User-mode code can obtain this value since it’s forwarded by the kernel to the user-mode printer driver. This will be explained below in greater detail. After validation, the passed hdev parameter will be copied to the bitmap’s hdev field.
2) The flHooks parameter may contain any combination of HOOK_XXX flags, documented here. These flags will be set in the bitmap’s flags field.
3) The dhpdev value is not passed as a parameter. However, the kernel maintains its internal list of hdev-dhpdev pairs, so setting the bitmap’s hdev field will also set its dhpdev field.

During device initialization, the device driver can pass a dhpdev value of the driver’s choice to the operating system, thus creating a hdev-dhpdev pair. In practice, the dhpdev value points to a block of driver-allocated memory, which will be either kernel-mode memory for display drivers or user-mode memory for printer drivers. This observation is very important for us.

Whenever executing a GDI graphics primitive (for example, ExtTextOut, which renders text to a DC), there are two code paths that could be chosen. One code path implements the primitive via a call to a corresponding driver function (supposing one exists) that knows how to perform that graphics primitive natively. The other code path uses a generic implementation of the primitive as supplied by win32k. The bitmap’s flags field, containing a combination of values from the HOOK_XXX enumeration, tells the operating system which GDI operations should be handled by the win32k subsystem and which should be directed to a corresponding device driver function. When so requested, the driver is identified by the device context’s hdev field.

Since we used ExtTextOut in our example above, let’s consider the HOOK_TEXTOUT flag. The ExtTextOut GDI function takes a device context as a parameter and passes it to the kernel-mode implementation of GDI. The kernel obtains the bitmap that is selected into this device context and checks if the bitmap’s flags field has the HOOK_TEXTOUT bit set. If this bit is not set, the kernel will pass our request to the generic win32kfull.sys!EngTextOut function to render the text. If HOOK_TEXTOUT is set, though, the kernel will forward our request to the device driver as specified by the bitmap’s hdev field. In this case, execution will be passed in kernel mode to one of three possible places (a few more are used in some specific cases, but they are not interesting for us):

Cdd.dll!DrvTextOut, which is a part of a top-level display driver, used for screen devices when only one monitor is active.
win32kfull.sys!MulTextOut, which is a part of a top-level display driver, used for multi-monitor configurations. This driver is embedded directly in the win32k subsystem.
win32kfull.sys!UMPDDrvTextOut, which is one of the printer stubs in the kernel. It uses a callback to pass the request through to user mode. This allows the request to be handled by the appropriate user-mode printer driver.

We are now ready to make our piece of code malicious. To achieve this, we’ll replace one of the SelectObject calls with a call to EngAssociateSurface call, passing HOOK_TEXTOUT as the flags parameter:

Other modifications are as follows:

1) We no longer need to call CreateCompatibleDC when creating DCPrn. This is because we no longer call SelectObject on DCPrn but rather EngAssociateSurface on DCPrn’s hdev value.
2) Because of internal EngAssociateSurface requirements, we can’t use the CreateBitmap call anymore. We must instead call CreateCompatibleBitmap on DCPrn.
3) We no longer need to deselect our bitmap from DCPrn. This is because there is no SelectObject call on DCPrn but rather EngAssociateSurface on DCPrn’s hdev value.
4) Note that we explicitly call a Unicode (wide) version of the ExtTextOut API. We also provide an ETO_IGNORELANGUAGE flag to this call, along with a very long string. This way, our ExtTextOut request will be passed directly to the kernel mode without any further user-mode handling.

Let’s look at the comments in the code snippet above. The EngAssociateSurface call sets the bitmap’s hdev field so it points to a printer device in kernel mode. As explained above, this will also affect the bitmap’s dhpdev field. As we remember, this value, in practice, points to a block of driver-allocated memory. Since printer drivers are handled in user mode, this will be some block of user-mode memory. Finally, the HOOK_TEXTOUT bit is set in the bitmap’s flags field.

The SelectObject call is then made, which ties the bitmap to DCScr and modifies the bitmap’s hdev field so it no longer points to the printer device but rather to a screen device. Other bitmap fields are not modified. In particular, SelectObject will not alter the dhpdev field.

Finally, we have the ExtTextOutW call on the screen-related DCScr. When handling this call, the kernel will see the HOOK_TEXTOUT flag set in the bitmap’s flags field, so drawing will not be handled by the win32k subsystem. Instead, our request will be passed to the device driver specified by the DCScr’s hdev value, which in our case is the display driver. This way, thanks to our manipulations, the display driver will get the bitmap containing a pointer to some user-mode memory in the bitmap’s dhpdev field while it expects to see a pointer to its own, kernel-mode memory there. We definitely found a security problem.

By preparing a block of user-mode memory appropriately, we can trick the display driver into overwriting kernel memory of our choice. This means privilege escalation is possible. But first, we must perform some interactions with a user-mode printer driver to help us fulfull the following four requirements:

Requirement 1: We must obtain the printer’s hdev value so we will be able to make the EngAssociateSurface call. This is a kernel-mode pointer.
Requirement 2: We must obtain the printer’s dhpdev pointer (note that this is a user-mode pointer), so we can prepare the memory that the display driver will access there. Even better, we can also modify this pointer at will, as explained below.
Requirement 3: Calling CreateCompatibleBitmap on DCPrn must return a bitmap that can be then selected into DCScr, so it must be either a 1-bit or a 32-bit bitmap. For this reason, we must force the user-mode printer driver to create either a 1-bit or a 32-bit device context, which will become our DCPrn.
Requirement 4: We must force the user-mode printer driver to report that it has a native text rendering function. Otherwise, calling EngAssociateSurface with HOOK_TEXTOUT will fail.

Hooking the UMPD implementation

Printer drivers are user-mode DLLs registered in the Registry. Printer drivers may implement functions that are defined in the winddi.h header file and are identified by integer constants:

To implement INDEX_DrvEnablePDEV functionality, device drivers provide a function with the following definition:

As we can see, this function gets the hdev value as a parameter and returns the dhpdev value. This means that we need to install some wrapper around this function in the printer driver to be able to obtain and modify these values.

To reach our goal, we could hook the user-mode printer driver itself, as described in detail here. However, this is quite a complex approach. Instead, we’ll try another solution that is both simpler and more universal. Instead of placing hooks in the driver itself, we will hook the user-mode code that is executed above the driver:

By injecting our own layer between user32.dll!ClientPrinterThunk and gdi32.dll!GdiPrinterThunk, we can obtain a central point at which all data passed to or returned from printer drivers can be read and modified. This can be achieved easily, since gdi32.dll!GdiPrinterThunk is a public export from the gdi32.dll module. Because user32.dll is a PE image mapped into memory, it’s enough to enumerate its import table and replace all pointers to gdi32.dll!GdiPrinterThunk with pointers to our own code. This gives us the ability to modify the incoming data, call the original gdi32.dll!GdiPrinterThunk function, and modify the returned data as needed.

The gdi32.dll!GdiPrinterThunk function, although exported by gdi32.dll, is not publicly defined. As of today, it has four parameters and can be reconstructed as:

In this call, the input buffer contains the identifier of the driver function to be called (i.e., one of the INDEX_XXX values) along with data needed for the call. The output buffer receives the results returned by the printer driver. The needed parts of the input and output buffer can be reconstructed as:

For our exploit, we need custom handling of the following INDEX_XXX requests in our GdiPrinterThunk wrapper:

1) INDEX_DrvEnablePDEV
2) INDEX_UMPDDrvDriverFn (undocumented, called from win32kfull.sys!UMPDDrvDriverFn)
3) INDEX_DrvDisablePDEV

Aside from the INDEX_XXX values defined in winddi.h, GdiPrinterThunk also receives a few undocumented commands. These have INDEX_XXX values greater than the highest documented value. Undocumented commands are never forwarded down to the lowest level (the user-mode printer driver DLL). They are designed for internal gdi32full.dll use only. The first command passed to the GdiPrinterThunk call is always a particular undocumented command, which, after increasing by 3, gives us the needed INDEX_UMPDDrvDriverFn value.

After using CreateDC to create a printer-related device context, we’ll catch many requests in our installed GdiPrinterThunk wrapper. Most of them should be just passed directly to the original gdi32.dll!GdiPrinterThunk implementation, with the three exceptions as mentioned above:

• When handling INDEX_DrvEnablePDEV, we can find the hdev value needed for the EngAssociateSurface call in the input buffer, which satisfies Requirement #1. Then, after calling the original gdi32.dll!GdiPrinterThunk function, we can find the dhpdev value in the output buffer, which points to some block of user-mode memory. Disassembling gdi32full.dll shows that this block of memory contains only two handles/pointers. At this moment, we can allocate some large (64 kB) block of user-mode memory, copy these two handles/pointers to our block, and overwrite the original dhpdev value with a pointer to our own block. By disclosing dhpdev as well as overwriting it with a new value to our liking, we have satisfied Requirement #2. Additionally, the output buffer contains a pointer to a pdi record. We should set pdi->iDitherFormat to BMF_1BPP and also ensure that pdi->flGraphicsCaps has the GCAPS_PALMANAGED flag cleared. This way, Requirement #3 will be met as well.

• When handling INDEX_UMPDDrvDriverFn, we get the DriverFn array in the output buffer. After calling the original gdi32.dll!GdiPrinterThunk function, we should set DriverFn[INDEX_DrvTextOut] to TRUE so the kernel will think that text drawing functionality is handled natively by the printer driver. Thanks to this, passing HOOK_TEXTOUT flag to our EngAssociateSurface call will succeed. This will satisfy Requirement #4.

• When handling INDEX_DrvDisablePDEV, we’ll find our own dhpdev value in the input buffer. It’s good to replace it with the original value before calling the original gdi32.dll!GdiPrinterThunk function to avoid problems with heap memory. gdi32full.dll treats this value as a pointer to its own block of heap memory and tries to release it.

Kernel Exploitation with a Fake dhpdev Block

We are now ready to pass our block of user-mode memory to the display driver. Our choice will be the multi-monitor display driver. More precisely, we will target its win32kfull.sys!MulTextOut function. This will limit our exploitation to multi-monitor machines only, but exploitation will be a bit tricky. The multi-monitor driver expects to see its own data structures in the dhpdev block, so we must craft this block of memory properly to obtain a controllable memory write. A detailed description of the needed memory contents would be quite boring and not really cutting-edge, so let’s immediately focus on the tricky part. There are some flags stored in the dhpdev block where we can set the RC_PALETTE bit. This informs the multi-monitor driver that our displays need a palette for drawing. A palette is used for dealing with 8-bit color modes. Enabling such modes for displays has not been possible since Windows 8. However, the code for handling them is still present. This allows us to use the RC_PALETTE flag and thus force the driver to create a palette object while, by preparing contents of the fake dhpdev block carefully, we can control the memory address where the palette object will be stored. In other words, we can overwrite kernel memory of our choice with a palette handle value.

Our target for overwriting will be our process token’s privileges – see here for details on how to obtain the address of our privileges in kernel memory. In short, we can treat privileges as two 64-bit bitfields located in kernel memory. One of these bitfields tells which privileges are present and another one tells which are enabled. For our purposes, it’s enough to gain the following four privileges:

1) SeCreateTokenPrivilege
2) SeSecurityPrivilege
3) SeAssignPrimaryTokenPrivilege
4) SeTcbPrivilege

To obtain these privileges, we need to set their corresponding bits in the present bitfield. Generally speaking, once a privilege is present in the token, it can be enabled by calling the AdjustTokenPrivileges API. However, not all privileges can be enabled so easily. Each process token contains not only its privileges but also a so-called integrity level. Normal processes don’t have an integrity level high enough to enable the most critical privileges just by making an API call. For this reason, we must perform our exploitation twice: once to overwrite the bitfield indicating which privileges are present and a second time to overwrite the bitfield indicating which privileges are enabled. This means we must:

1) Prepare our fake dhpdev block in such a way that the handle to the palette object will be stored in the present bitfield.
2) Call ExtTextOutW.
3) Prepare our fake dhpdev block once again so the handle to the palette object will be stored in the enabled bitfield.
4) Call ExtTextOutW again.

For successful exploitation, we need to hold only the four privileges listed above. All other privileges may be either set or cleared. Having these four privileges is enough to make a successful call to an undocumented NtCreateToken native API. This allows us to create a token with all privileges present and enabled and with the highest possible integrity level. Passing such a token to a CreateProcessAsUser call allows us to create a maximally powerful user-mode process.

Our last task is to force the kernel to create palettes with the proper handle values so that writing so those values to the privileges bitfields will set the required bits.

Controlling GDI handle values

The lowest 16 bits of each GDI handle act as an index to a so-called global GDI table. For example, a handle value may be:

0x6c0859b2

where:
1) 0x59b2 is an index to a slot in the global GDI table.
2) 0x08 is an object type. 0x08 stands for a palette object.
3) 0x6c is a counter that is incremented each time a slot is assigned for a new object.

Slots in the global GDI table are used in a LIFO (Last In, First Out) manner. We can experiment and create 3 GDI objects: Object1, Object2, and Object3. Obtained handle values may be, for example:

0x74xx25c8
0x21xx1287
0x15xx4f34

Now we can delete these objects in reverse order (Object3, Object2, and Object1) and recreate them in the original order again. The handle values will most probably still reference the same slots, and their values will now be:

0x75xx25c8
0x22xx1287
0x16xx4f34

To achieve our goal, we should:
1) Create many GDI objects of any type. Since there is a per-process limit of 10,000 GDI handles, we can create 9,500 objects. Assuming a linear distribution, 1/16 of the obtained handle values (nearly 600 of them) will have the needed bit combination.
2) Delete the objects that don’t have the needed bit combination in their lowest 16 bits.
3) Delete the objects that do have the needed bit combination in their lowest 16 bits.

The slots of the most recently deleted objects will be first to be reused again when the multi-monitor driver allocates its palette objects during exploitation. Since the most recently deleted objects have the required bit combination in their handle values, the kernel-generated palette objects will also have this same bit combination.

Due to multitasking, other processes may interfere with our manipulations and release additional slots or reuse our just-released slots before they are used by the multi-monitor driver when creating its internal palette objects. This is not a big problem. We can call PrivilegeCheck to see if our process token’s privileges have been overwritten as expected. In case of failure, we can just attempt our exploitation once again.

As a result of our exploitation:
1) The needed privileges in our process token will always be set.
2) There are some other privileges that will always be in a predictable state (set or cleared) due to their being overwritten by the 0x08 part of the handle value.
3) The remaining privileges will be overwritten randomly.

The Patch

When the vulnerability was found, it was first thought that the problem was that the multi-monitor driver doesn’t validate that the dhpdev pointer in the received bitmaps falls within the kernel-mode memory range. We should note that some other HOOK_XXX flags could also be used for exploitation, for example, HOOK_LINETO along with a LineTo call. Therefore, the validation would need to be implemented in multiple places in the multi-monitor driver.

However, under the hood, things are probably more complicated than they appear, so another solution has been implemented. Now, when a bitmap’s dhpdev field is non-NULL (which would be a consequence of making an EngAssociateSurface call), and the bitmap is also printer-compatible (one of the bitmap’s undocumented flags indicates this), selecting the bitmap into a screen-related device context is no longer possible. A newly-added win32kbase.sys!bIsSurfaceAllowedInDC function checks these conditions and causes the SelectObject call to fail. The introduced change shouldn’t cause any problems in real-life scenarios, since the algorithm used for the exploitation is highly artificial. However, this change still breaks compatibility to some extent. For this reason, the patch can be disabled by adding an undocumented registry key from an elevated command prompt and rebooting:

reg.exe add HKEY_LOCAL_MACHINE\System\CurrentControlSet\Policies /v {b7ca08da-d52e-4acb-9866-7dad281e4489} /t REG_DWORD /d 1

Another newly-added function named win32kbase.sys!UMPDAllowPrinterSurfaceInDisplayDC is now called during system initialization. It reads the registry key (if it exists) and stores the result in a global variable called win32kbase.sys!gAllowPrinterSurfaceInDisplayDC. This variable is then read by the aforementioned win32kbase.sys!bIsSurfaceAllowedInDC function, which is internally called during each SelectObject call.


Thanks again to Marcin for providing this thorough write-up. He has contributed many 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-27077: Selecting Bitmaps into Mismatched Device Contexts

☑ ☆ ✇ Zero Day Initiative - Blog

CVE-2021-31969: Underflowing in the Clouds

By: Hossein Lotfi

With the popularity of cloud storage, various operating systems have added services and functionalities to support such storage. You can now have your storage in the cloud while exploring it locally on your system. On Windows, this is done via the Cloud Sync Engine. This component exposes a native API known as the Cloud Filter API. The implementation is found in the Cloud Files Mini Filter Driver, or cldflt.sys. The purpose of this blog is to provide some details about an integer underflow vulnerability within this driver tracked as CVE-2021-31969/ZDI-21-797, which was originally reported to the ZDI by an anonymous researcher. It can be exploited to overflow a kernel buffer and gain code execution with escalated privileges.

A quick look at Cloud Sync Engines

The Cloud Files API in Windows has been available since Windows 10 version 1709. It offers support for cloud sync engines and handles tasks such as creating and managing placeholder files and directories. A sync engine is a service that syncs files between a remote host and a local client in a way that allows cloud-hosted files and directories to be available to local users through the Windows file system and File Explorer. In this scenario, the file itself resides in the cloud, while on your local filesystem, there is a representation of that file known as a “placeholder.” Your file in the cloud might be huge, but a placeholder file might consume only the few bytes needed to store headers. When you access a placeholder file, Windows makes the associated cloud file available via syncing. The vulnerability can be triggered during the processing of placeholder files.

Method of triggering the vulnerability

Here is a description of the key steps in the proof of concept:

1: It starts by performing a sync root registration. It then initiates the communication between a sync provider and the sync filter API:

2: It gets a handle to the target directory and retrieves the reparse point data via an FSCTL_GET_REPARSE_POINT control code:

3: It modifies the retrieved reparse point data, setting the length to zero. It then sets it back via an FSCTL_SET_REPARSE_POINT_EX control code (with the tag set to 0x9000301A which is IO_REPARSE_TAG_CLOUD_3). Finally, it sets parameters to ask for a placeholder update (code= 0xC0000003) via the cloud filter FSCTL (0x903BC):

The Kernel Bug

As we mentioned, a kernel driver called cldflt.sys is responsible for processing cloud filter FSCTLs. As usual, this is accomplished using a function with a large switch statement. This function is named HsmFltProcessHSMControl:

Figure 1 - The HsmFltProcessHSMControl Function

Figure 1 - The HsmFltProcessHSMControl Function

For an operation with code 0xC0000003, it will eventually call HsmFltProcessUpdatePlaceholder:

Figure 2 - Call to HsmFltProcessUpdatePlaceholder

Figure 2 - Call to HsmFltProcessUpdatePlaceholder

After some processing, the execution flow will reach HsmpRpReadBuffer. It first allocates a buffer then retrieves reparse point data by issuing an FSCTL_GET_REPARSE_POINT control code. Note that the retrieved data may have been modified by the attacker. Afterward, it calls HsmpRpiDecompressBuffer:

Figure 3 - Calling HsmpRpiDecompressBuffer

Figure 3 - Calling HsmpRpiDecompressBuffer

Inside HsmpRpiDecompressBuffer, the provided length (which the attacker has set to zero) is retrieved and increased by 8. It is saved in a local variable (length) and then is used to allocate a kernel buffer. Shortly afterward, the code proceeds to decompress data via a call to RtlDecompressBuffer using the allocated buffer as the destination buffer for the uncompressed data. However, the pointer it passes to RtlDecompressBuffer is not the start of the allocated buffer. Instead, it is advanced by 12 bytes to make room for some metadata. Correspondingly, the buffer size it passes to RtlDecompressBuffer is length minus 12. In the disassembly shown below, the subtraction is seen optimized as an ADD. In our case, this subtraction produces an integer underflow, so that a huge buffer length value of 0xFFFFFFF4 is passed to RtlDecompressBuffer. This enables a kernel buffer overflow.

Figure 4 - Showing the integer underflow

Figure 4 - Showing the integer underflow

The Patch

Microsoft fixed this vulnerability by adding a check to make sure the retrieved length is not less than 4. This makes it impossible to trigger an integer underflow.

Figure 5 - Patch from Microsoft

Figure 5 - Patch from Microsoft

Final notes

New technologies are always on the way and operating systems must add new features to support such technologies and bring them to the end users. Researchers can always expect vulnerabilities in such a fresh piece of code no matter how good programmers are or how thorough a vendor checks and performs fuzzing to catch errors and vulnerabilities.

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

CVE-2021-31969: Underflowing in the Clouds

☑ ☆ ✇ Zero Day Initiative - Blog

The July 2021 Security Update Review

By: Dustin Childs

The second Tuesday of the month is here, and it brings with it the latest security patches 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 July 2021

For July, Adobe released five patches addressing 29 CVEs in Adobe Dimension, Illustrator, Framemaker, Acrobat and Reader, and Adobe Bridge. A total of 15 of these bugs were reported through the ZDI program with several being discovered by ZDI researchers Mat Powell and Joshua Smith. The update for update Acrobat and Reader fixes 19 different bugs – several of which could lead to code execution if an attacker can convince a user to open a malicious PDF with an affected version. The update for Dimension also could allow code execution. For Illustrator, three bugs are being fixed. The two that allow for code execution occur in during the processing of PDF and JPEG2000 files. These issues result from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated buffer. Similar Out-Of-Bounds (OOB) Write bugs exist in the five fixes for Bridge. Again, code execution would occur at the level of the logged-on user. The single CVE fixed by the Framemaker patch corrects an OOB Write that exists within the parsing of TrueType fonts embedded in PDF files.

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 July 2021

For July, Microsoft released patches for 117 CVEs in Microsoft Windows, Dynamics, Exchange Server, Microsoft Office, Windows Storage Spaces Controller, Bing, SharePoint Server, Internet Explorer (IE), Visual Studio, and OpenEnclave. A total of 17 of these bugs were reported through the ZDI program. Of these 117 bugs, 13 are rated Critical, 103 are rated Important, and one is rated as Moderate in severity. This volume of fixes is more than the last two months combined and on par with the monthly totals from 2020. Perhaps the lowered rate seen in the prior months was an aberration. According to Microsoft, six of these bugs are publicly known and four are listed as under active attack 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 that’s already received a lot of (warranted) attention:

-       CVE-2021-34527 - Windows Print Spooler Remote Code Execution Vulnerability
Much has already been written about this currently exploited bug also known as PrintNightmare. Microsoft released an Out-of-Band (OOB) patch for this bug on July 1, and they have updated it multiple times since then. There have been reports the patch is ineffective, but Microsoft insists it works – provided certain registry keys have the correct values. Enterprises should verify these registry keys are configured as intended and get this patch rolled out. It’s also a fine time to disable the Print Spooler service wherever it isn’t needed and restrict the installation of printer drivers to just administrators.

-       CVE-2021-34448 - Scripting Engine Memory Corruption Vulnerability
This bug is also listed as under active exploit, but there’s no indication of how widespread the attack is. The vulnerability allows an attacker to execute their code on an affected system if a user browses to a specially crafted website. The code execution would occur at the logged-on user level. This is also a case where CVSS doesn’t quite offer a true glimpse of the threat. Microsoft lists the attack complexity as high, which knocks this from a high severity (>8) to a medium severity (6.8). However, if there are already active attacks, does complexity matter? Regardless, treat this as critical since it could allow code execution on every supported version of Windows.

-       CVE-2021-34494 - Windows DNS Server Remote Code Execution Vulnerability
This bug is currently not under active attack, but considering the severity, there are those who will work to change that status. This bug could allow remote code execution at a privileged service level on a listening network port without user interaction. Microsoft does mention low privileges are needed, but depending on the server configuration, these could be easily gained. This bug is restricted to DNS Servers only, but if there’s one system you don’t want wormed, it’s probably your DNS server. Definitely test and deploy this one quickly.

-       CVE-2021-34458 - Windows Kernel Remote Code Execution Vulnerability
It’s rare to see remote code execution in a kernel bug, but this is that rare exception. This bug impacts systems hosting virtual machines with single root input/output virtualization (SR-IOV) devices. It’s not clear how widespread this configuration is, but considering this bug rates as a CVSS 9.9, it’s not one to ignore. If you have virtual machines in your environment, test and patch quickly.

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

CVE Title Severity CVSS Public Exploited Type
CVE-2021-34527 Windows Print Spooler Remote Code Execution Vulnerability Critical 8.8 Yes Yes RCE
CVE-2021-34448 Scripting Engine Memory Corruption Vulnerability Critical 6.8 No Yes RCE
CVE-2021-31979 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No Yes EoP
CVE-2021-33771 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No Yes EoP
CVE-2021-34473 Microsoft Exchange Server Remote Code Execution Vulnerability Critical 9.1 Yes No RCE
CVE-2021-33781 Active Directory Security Feature Bypass Vulnerability Important 8.1 Yes No SFB
CVE-2021-34523 Microsoft Exchange Server Elevation of Privilege Vulnerability Important 9 Yes No EoP
CVE-2021-33779 Windows ADFS Security Feature Bypass Vulnerability Important 8.1 Yes No SFB
CVE-2021-34492 Windows Certificate Spoofing Vulnerability Important 8.1 Yes No Spoofing
CVE-2021-34474 Dynamics Business Central Remote Code Execution Vulnerability Critical 8 No No RCE
CVE-2021-34464 Microsoft Defender Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2021-34522 Microsoft Defender Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2021-34439 Microsoft Windows Media Foundation Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2021-34503 Microsoft Windows Media Foundation Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2021-34494 Windows DNS Server Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2021-34450 Windows Hyper-V Remote Code Execution Vulnerability Critical 8.5 No No RCE
CVE-2021-34458 Windows Kernel Remote Code Execution Vulnerability Critical 9.9 No No RCE
CVE-2021-33740 Windows Media Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2021-34497 Windows MSHTML Platform Remote Code Execution Vulnerability Critical 6.8 No No RCE
CVE-2021-34476 Bowser.sys Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2021-34489 DirectWrite Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-34440 GDI+ Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-31947 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-33775 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-33776 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-33777 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-33778 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-33760 Media Foundation Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-33753 Microsoft Bing Search Spoofing Vulnerability Important 4.7 No No Spoofing
CVE-2021-34501 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-34518 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-33766 Microsoft Exchange Information Disclosure Vulnerability Important 7.3 No No Info
CVE-2021-33768 Microsoft Exchange Server Elevation of Privilege Vulnerability Important 8 No No EoP
CVE-2021-34470 Microsoft Exchange Server Elevation of Privilege Vulnerability Important 8 No No EoP
CVE-2021-31196 Microsoft Exchange Server Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2021-31206 Microsoft Exchange Server Remote Code Execution Vulnerability Important 7.6 No No RCE
CVE-2021-34451 Microsoft Office Online Server Spoofing Vulnerability Important 5.3 No No Spoofing
CVE-2021-34469 Microsoft Office Security Feature Bypass Vulnerability Important 8.2 No No SFB
CVE-2021-34467 Microsoft SharePoint Server Remote Code Execution Vulnerability Important 7.1 No No RCE
CVE-2021-34468 Microsoft SharePoint Server Remote Code Execution Vulnerability Important 7.1 No No RCE
CVE-2021-34520 Microsoft SharePoint Server Remote Code Execution Vulnerability Important 8.1 No No RCE
CVE-2021-34517 Microsoft SharePoint Server Spoofing Vulnerability Important 5.3 No No Spoofing
CVE-2021-34479 Microsoft Visual Studio Spoofing Vulnerability Important 7.8 No No Spoofing
CVE-2021-34441 Microsoft Windows Media Foundation Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-34452 Microsoft Word Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-33767 Open Enclave SDK Elevation of Privilege Vulnerability Important 8.2 No No EoP
CVE-2021-31984 Power BI Remote Code Execution Vulnerability Important 7.6 No No RCE
CVE-2021-34521 Raw Image Extension Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-33751 Storage Spaces Controller Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2021-34460 Storage Spaces Controller Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34510 Storage Spaces Controller Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34512 Storage Spaces Controller Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34513 Storage Spaces Controller Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34509 Storage Spaces Controller Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-34477 Visual Studio Code .NET Runtime Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34528 Visual Studio Code Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-34529 Visual Studio Code Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-34449 Win32k Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2021-34516 Win32k Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34491 Win32k Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-34504 Windows Address Book Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-33785 Windows AF_UNIX Socket Provider Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2021-34459 Windows AppContainer Elevation Of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34462 Windows AppX Deployment Extensions Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2021-33782 Windows Authenticode Spoofing Vulnerability Important 5.5 No No Spoofing
CVE-2021-33784 Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34488 Windows Console Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34461 Windows Container Isolation FS Filter Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-33759 Windows Desktop Bridge Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-33745 Windows DNS Server Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2021-34442 Windows DNS Server Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2021-34444 Windows DNS Server Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2021-34499 Windows DNS Server Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2021-33746 Windows DNS Server Remote Code Execution Vulnerability Important 8 No No RCE
CVE-2021-33754 Windows DNS Server Remote Code Execution Vulnerability Important 8 No No RCE
CVE-2021-33780 Windows DNS Server Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-34525 Windows DNS Server Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-33749 Windows DNS Snap-in Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-33750 Windows DNS Snap-in Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-33752 Windows DNS Snap-in Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-33756 Windows DNS Snap-in Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-33774 Windows Event Tracing Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2021-34455 Windows File History Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34438 Windows Font Driver Host Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-34498 Windows GDI Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34496 Windows GDI Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-34466 Windows Hello Security Feature Bypass Vulnerability Important 5.7 No No SFB
CVE-2021-34446 Windows HTML Platform Security Feature Bypass Vulnerability Important 8 No No SFB
CVE-2021-33755 Windows Hyper-V Denial of Service Vulnerability Important 6.3 No No DoS
CVE-2021-33758 Windows Hyper-V Denial of Service Vulnerability Important 7.7 No No DoS
CVE-2021-34511 Windows Installer Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-33765 Windows Installer Spoofing Vulnerability Important 6.2 No No Spoofing
CVE-2021-31961 Windows InstallService Elevation of Privilege Vulnerability Important 6.1 No No EoP
CVE-2021-34514 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34500 Windows Kernel Memory Information Disclosure Vulnerability Important 6.3 No No Info
CVE-2021-34508 Windows Kernel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-33764 Windows Key Distribution Center Information Disclosure Vulnerability Important 5.9 No No Info
CVE-2021-33788 Windows LSA Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2021-33786 Windows LSA Security Feature Bypass Vulnerability Important 8.1 No No SFB
CVE-2021-34447 Windows MSHTML Platform Remote Code Execution Vulnerability Important 6.8 No No RCE
CVE-2021-34493 Windows Partition Management Driver Elevation of Privilege Vulnerability Important 6.7 No No EoP
CVE-2021-33743 Windows Projected File System Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-33761 Windows Remote Access Connection Manager Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-33773 Windows Remote Access Connection Manager Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34445 Windows Remote Access Connection Manager Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34456 Windows Remote Access Connection Manager Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-33763 Windows Remote Access Connection Manager Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-34454 Windows Remote Access Connection Manager Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-34457 Windows Remote Access Connection Manager Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-34507 Windows Remote Assistance Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2021-33744 Windows Secure Kernel Mode Security Feature Bypass Vulnerability Important 5.3 No No SFB
CVE-2021-33757 Windows Security Account Manager Remote Protocol Security Feature Bypass Vulnerability Important 5.3 No No SFB
CVE-2021-33783 Windows SMB Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-31183 Windows TCP/IP Driver Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2021-33772 Windows TCP/IP Driver Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2021-34490 Windows TCP/IP Driver Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2021-34519 Microsoft SharePoint Server Information Disclosure Vulnerability Moderate 5.3 No No Info

Looking at the remaining patches, you’ll note seven patches for Exchange Server, but only some of these are actually new. One of the new ones is CVE-2021-31206, which was disclosed during the last Pwn2Own contest. There are also new patches for elevation of privilege bugs that could be exploited in a man-in-the-middle attack or be network adjacent. The real surprise in this month’s Exchange patches are the three bugs patched in April but not documented until today. Silent patches have caused many problems in the past and represent significant risks to enterprises. While the goal should be for administrators to install every patch, this is simply not feasible for most networks. Network defenders need as much information as possible to prioritize their resources. If they are not provided guidance on installing the patch, or information from the vendor on the severity of the patch, their uninformed decision could have negative consequences.

Taking a look at the remaining Critical-rated bugs, there are two updates for Defender code execution bugs, although 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. There are also RCE bugs in Dynamics 365 Business Central, Windows Media Foundation, MSHTML, and Hyper-V.

Moving to the Important-rated RCE bugs, there are quite a few impacting the Windows DNS Server. Most of these would require an administrator to view a malicious record in the DNS Snap-in to be exploited. There are also a few that have no user interaction and require only low-level privileges. Two of the patches fix denial-of-service (DoS) bugs in the server. Shutting DNS down is nearly as severe as taking it over. In all cases, the DNS Server must be enabled for a system to be impacted by these bugs. The Important RCEs category is rounded out by fixes for Office components, SharePoint Server, and HEVC Video Extensions.

There are a total of 32 Elevation of Privilege (EoP) patches in this month’s release. In addition to the ones previously mentioned, six of these fix EoP bugs in the Windows Storage Spaces Controller. There are also fixes for EoP vulnerabilities in the kernel, Remote Access Connection Manager, Installer service, partition management, and projected file system.

We’ve already mentioned quite a few DoS bugs in this release, and there are a few more to look out for. The first is a bug in the Local Security Authority (LSA). Microsoft doesn’t detail the impact of the bug, but a DoS on LSA implies users can’t authenticate. There are three DoS vulnerabilities in the TCP/IP stack. Again, no details from Microsoft, but it appears an attacker could shut down all networking on a device. Finally, there are fixes for DoS bugs in bowser.sys and the Windows AF_UNIX Socket Provider.

There are 14 patches fixing information disclosure bugs this month, including the single Moderate-rated fix for a bug in SharePoint Server. This bug could disclose PII and, in some cases, requires multiple packages to be completely addressed. Most of the other bugs only lead to leaks consisting of unspecified memory contents. Two notable exceptions impact KDC and SMB. The KDC has a weak encryption algorithm that could be used to decrypted and expose information related to a user or service's active session. The SMB bug could allow an attacker unauthorized file system access, meaning they could read files on the affected system.

Eight security feature bypasses are fixed in this month’s release. The patch for ADFS fixes a bug in the Primary Refresh Tokens, which are normally stored in the TPM. The tokens aren’t encrypted properly. Attackers could extract and potentially decrypt the token for reuse until the token expires or is renewed. There’s a bug in LSA that could allow a read-only domain controller (RODC) to delegate rights by granting itself a ticket. This ticket isn’t validated by a domain controller, which could lead to a read-only DC getting Read/Write privileges. A patch for the Security Account Manager adds Advanced Encryption Standard (AES) encryption as the preferred method when using the MS-SAMR protocol. Microsoft will be releasing KB5004605 with additional configuration details in the future. At the time of release, it’s mentioned, but not live yet. Frustratingly, no details are available about the other bypasses, which includes the patches for two publicly known bugs and Windows Hello.

This month’s release is rounded out by seven patches to address spoofing bugs in SharePoint Server, Bing Search, Visual Studio, Office, Authenticode, Installer, and bug that could allow certificate spoofing. In late June, Microsoft reported they were investigating reports regarding a malicious actor trying to leverage the Windows Hardware Compatibility Program (WHCP) process. While they indicated there was no evidence of certificate exposure, it’s possible this patch resulted from that investigation. They do mark the bug as publicly known, but there’s no documentation confirming the link. No details are available about any of the other spoofing patches.

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

Looking Ahead

The next Patch Tuesday falls on August 10, 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 July 2021 Security Update Review

☑ ☆ ✇ Zero Day Initiative - Blog

CVE-2021-28474: SharePoint Remote Code Execution via Server-Side Control Interpretation Conflict

By: The ZDI Research Team

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

The vulnerability allows authenticated users to execute arbitrary .NET code on the server in the context of the service account of the SharePoint web application. For a successful attack, the attacker needs SPBasePermissions.ManageLists permissions for a SharePoint site. By default, authenticated SharePoint users can create sites/subsites and will have all necessary permissions.   

The Vulnerability

This problem exists due to an inconsistency between code that is used for security verification and code that is used for the actual processing of user input.

Security verification is performed by EditingPageParser.VerifyControlOnSafeList(). This function verifies that the provided input does not contain unsafe controls, meaning any control that is not marked as safe by SafeControl elements in web.config file.

The EditingPageParser.ParseStringInternal() function parses user input from dscXml and populates hashtable with information from the Register directives and hashtable2 with values from the tags of server controls. In the next step, it tries to verify each element of hashtable2 against the SafeControl elements from the web.config file. If a control is not marked there as safe, it throws an exception.

Let’s take a closer look at how values in hashtable2 are populated:

As we can see, the SharePoint server verifies only server-side controls (tags with the runat="server" attribute). This is reasonable since client-side elements do not require verification.

 If verification passes, SharePoint will process the provided markup. Let’s review the code that performs the processing:

As you can see, the steps for parsing content at processing time are very similar to the parsing steps at verification time. However, there is a critical one-line difference:

      text4 = HttpUtility.HtmlDecode(text4);

At processing time, attribute values are HTML-decoded by the parser, but there is no corresponding line at verification time. This means that if we have an ASPX tag with an attribute such as runat="server", the EditingPageParser.VerifyControlOnSafeList() function will not consider it a server-side control and will not check it for safety. At processing time, however, it will be recognized and executed as a server-side control.

Exploitation

For our attack, we will use the System.Web.UI.WebControls.Xml control. It allows us to retrieve information from an arbitrary XML file. We can use this to exfiltrate the machineKey section from web.config, which we allow us to forge an arbitrary ViewState and achieve remote code execution via ViewState deserialization.

We can see that System.Web.UI.WebControls.Xml is marked as unsafe via a SafeControl element in web.config:

To deliver our payload to the server, we will use the WebPartPagesWebService.ExecuteProxyUpdates web API method that is accessible via the /_vti_bin/WebPartPages.asmx endpoint. It allows us to render ASPX markup from the OuterHtml attribute in Design mode. User input will be verified by the VerifyControlOnSafeList method.

For a successful attack, we need to provide a relative path to any existing site page:

We can use information from the machinekey section from web.config to create a valid ViewState that will be deserialized by SharePoint. This allows us to run an arbitrary OS command via deserialization of untrusted data.

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 the 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 we will be the owner and have all permissions.

Click on “SharePoint” on the top panel:

Picture2.png

Now click “+ Create site” link:

Picture3.png

Choose Team Site.

Now we need to pick a name for the new site. In this case, we use ts01.

Picture4.png

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

Picture5.png

Now we need a relative path to any site page in this site. We can see list of pages by going to /SitePages/Forms/ByAuthor.aspx:

Picture6.png

We can click on the desired page and take the relative path from the address bar (note that we omit the leading site name and “/” ) :

Picture7.png

In our case, it is SitePages/Home.aspx.

Now we use our custom executable to send a request to the server that triggers the vulnerability. We need to provide the URL to our site, credentials, and the relative path determined above. In this case:

      >SP_soap_RCE_PoC.exe http://sp2019/sites/ts01/ user2 [email protected] contoso "SitePages/Home.aspx"

Picture8.png

If our attack is successful, we receive the content of web.config:

Picture9.png

Within the file, we search for the machineKey element:

Picture10.png

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

      validationKey=”FAB45BC67E06323C48951DA2AEAF077D8786291E2748330F03B6601F09523B79”

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

Using this information, we can perform our remote code execution attack. Before the final step, let’s go to the target SharePoint server and open C:\windows\temp folder:

Picture11.png

We verify there is no SP_RCE_01.txt file yet.

Now let’s go back to the “attacker” machine, and open the Success.aspx page on our site:

In this case, the URL is http://sp2019/sites/ts01/_layouts/15/success.aspx:

Picture12.png

Now we need to open the source code view for this page and find the value of __VIEWSTATEGENERATOR:

Picture13.png

In this example, it is AF878507.

We now have all the data needed to forge an arbitrary ViewState:

 __VIEWSTATEGENERATOR=AF878507

validationKey=FAB45BC67E06323C48951DA2AEAF077D8786291E2748330F03B6601F09523B79

validationAlg=HMACSHA256

We generate the ViewState using ysoserial, as follows:

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

Picture14.png

Here is the resulting payload:

We need to URL-encode it and send it as the __VIEWSTATE parameter in the query string in a request to our server:

We paste this URL into the browser. The response appears as an error:

Picture15.png

Nevertheless, when we check the C:\windows\temp folder on our target server again:

Picture16.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-28474, 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-28474: SharePoint Remote Code Execution via Server-Side Control Interpretation Conflict

☑ ☆ ✇ Zero Day Initiative - Blog

CVE-2021-26892: An Authorization Bypass on the Microsoft Windows EFI System Partition

By: Simon Zuckerbraun

In October 2020, researcher Abdelhamid Naceri, also known as halov, submitted a unique vulnerability to the ZDI. This vulnerability in Windows 10 allows a low-privileged user to wipe out arbitrary files needed for UEFI boot. The attack can even be conducted from a low integrity level.

There is a great deal of mystery surrounding this case and I will explain the parts that I am able to.

The vulnerability is identified as ZDI-21-330/CVE-2021-26892 and was patched by Microsoft in March 2021.

Background

When any computer system starts up from a cold state, the very first instructions that the processor executes come from firmware. Although we would like to quickly transition to executing instructions that are stored on disk (e.g., the operating system), those instruction bytes are not yet available in memory upon a cold start. Hence the processor must start by executing firmware instructions. The firmware provides the needed instructions for retrieving OS boot instructions from disk, and eventually jumping into the OS.

UEFI is a type of firmware. An in-depth treatment of UEFI is beyond the scope of this article, but for our purposes, we need to know that UEFI firmware will look for a boot device (for example, the primary fixed drive) that contains a special partition known as the EFI System Partition or ESP. This partition is formatted with one of the variants of the FAT file system that the firmware can parse. Within this file system, the firmware expects to find a file with extension .EFI, known as a boot loader, from which it can read the further steps needed in order to continue starting the OS. There are often multiple .EFI files present corresponding to different architectures. A UEFI firmware is also capable of handling the case of multiple available boot devices.

The EFI System Partition and Security

As is known, FAT file systems do not record ACLs or any other security information for files. If a FAT file system is mounted on Windows, every file has, in effect, an empty security descriptor, making the file both world-readable and world-writable. Clearly this is unacceptable for the EFI System Partition. If the files on the ESP were world-writable, it would be trivial for any user to damage the system by deleting critical files needed for boot. An unprivileged user could even install a bootkit by replacing the .EFI file with one containing malicious instructions.

Accordingly, Windows does some behind-the-scenes work to impose special restrictions on access to the ESP. To begin with, the EFI partition is not mounted to any drive letter by default. If a non-administrative user attempts to mount it to a drive letter, access is denied. Even if an administrator mounts it to a driver letter (and there is, in fact, a special command-line syntax for mounting the EFI partition: mountvol F: /S), a non-administrative user will still not have any access to the mounted drive.

Bypassing the ESP Authorization Restrictions

Despite these restrictions, the researcher found that a low-privileged user, even running at low integrity, can still gain some access to the files on the EFI System Partition.

To avoid the need to assign a drive letter, an attacker can call the CreateFile API with a full volume name and path to a specific known file, for example:

      \\?\Volume{641e9a14-b3d6-425c-af6e-7d585169951e}\EFI\Microsoft\Boot\bootmgfw.efi

The volume GUID can be obtained via enumeration of volumes, using the FindFirstVolume and FindNextVolume APIs. In this way, an attacker can obtain a handle to an arbitrary file within the EFI partition, as long as the path is predictable, which is common. I did an experiment and called GetSecurityInfo on the resulting handle, and as would be expected, I received an empty security descriptor, indicating that the file is world-readable and writable: O:WDG:WDD:NO_ACCESS_CONTROL. Even so, Windows does not behave in the way that this security descriptor would imply. Attempts to open the file for reading or writing (GENERIC_READ or GENERIC_WRITE) are denied.

Despite this – and here is the researcher's key finding – there is still a way for an attacker to gain a limited amount of write access. The trick is to call CreateFile without requesting any access at all (neither GENERIC_READ nor GENERIC_WRITE) but specifying a disposition of CREATE_ALWAYS. This flag requests that if the destination file exists, it should be immediately truncated to zero length. Somehow, this combination slips past the authorization logic that Windows implements for the ESP. Although the access mask on the resulting handle does not permit the attacker to write any bytes to the file, Windows nevertheless truncates the file during the CreateFile call as requested. By wiping out the contents of critical .EFI files, the attacker can render the system unable to boot.

Difficulties in Reproduction of the Vulnerability

While analyzing this case, I was mystified to find that it cannot be reproduced on certain hypervisor platforms. I found it could be reproduced on bare metal as well as on HyperV. On ESXi, however, even though the security descriptor comes up as the world-writable O:WDG:WDD:NO_ACCESS_CONTROL, an attempt to truncate the .EFI files fails with ERROR_ACCESS_DENIED. I have no explanation for the difference in behavior between bare metal and ESXi.

Conclusion

When experimenting with this vulnerability it is a good idea to make backups of the .EFI files that will be deleted, particularly when running on bare metal. A successful reproduction results in a complete inability to boot the machine.

The researcher who submitted this bug (halov) is a frequent contributor to the ZDI program, and we hope to continue to see his always interesting research in the future.

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

CVE-2021-26892: An Authorization Bypass on the Microsoft Windows EFI System Partition

☑ ☆ ✇ Zero Day Initiative - Blog

CVE-2021-1497: Cisco HyperFlex HX Auth Handling Remote Command Execution

By: Trend Micro Research Team

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 Cisco HyperFlex HX Data Platform. The bug was originally discovered by Nikita Abramov and Mikhail Klyuchnikov of Positive Technologies. The following is a portion of their write-up covering CVE-2021-1497, with a few minimal modifications.


Cisco HyperFlex HX Data Platform is a high-performance, extensible distributed file system that supports multiple hypervisors with a wide range of enterprise-grade data management and optimization services. A remote code execution vulnerability has been reported in the product due to improper input sanitization.

A remote, unauthenticated attacker can exploit this vulnerability by sending a crafted request to the web-based management interface of the target server. Successful exploitation could lead to the execution of arbitrary code in the context of the root user. Cisco patched this vulnerability in May 2021.

The Vulnerability

Cisco HyperFlex HX Data Platform Installer uses an HTTP-based web console. It is accessible through the following address:

         https://<server_name>

Where <server_name> is the name of the machine on which Cisco HyperFlex HX is installed. 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 line terminator sequence consisting of a Carriage Return (CR) character followed by a Line Feed (LF) character, 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 GET method might look like this:

A similar request 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:

        var1=value1&var2=value2&var3=value3...

Remote users can submit a request to the /auth/ endpoint of the Cisco HyperFlex HX server to authenticate themselves before installation operations. Below is an example of a request submitted to /auth/ to perform a system restore-and-reboot operation:

The frontend NGINX server will forward the HTTP request to the backend HTTP server listening on TCP/8082:

The HTTP server is implemented in an ELF executable file /opt/springpath/auth/auth. When it receives an HTTP request sent to the /auth/ endpoint, it will call the function main_loginHandler() to handle the request. The function will first extract the salt value from the line of /etc/shadow file using the provided username value from the HTTP request. Then it will call the function main_validatePassword() to validate the user-supplied password. This function finally calls main_checkHash() function. To calculate the hash value of the supplied password, this function uses generated Python code as follows:

        python -c 'import crypt; print crypt.crypt("<somePass>", "<salt>")'

Here <somePass> is the password supplied in the HTTP request and <salt> is the value extracted from the /etc/shadow file.

A Python code injection vulnerability exists here. The code fails to correctly validate the value of password before using it to generate the Python code string. An attacker can include Python command injection characters in the value of the password parameter to inject arbitrary Python code. For example, a value like the following:

implies the generated Python code will be like:

Therefore, the OS command COMMAND will be executed when the generated Python code is called.

A remote, unauthenticated attacker can exploit this vulnerability by sending a crafted request to the target server. Successful exploitation can result in the execution of arbitrary commands in the security context of the root user.

Conclusion

Cisco patched this vulnerability in May 2021. In their advisory, they mention there are no workarounds. Affected customers should apply the vendor patch to ensure they are protected from this vulnerability.

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-1497: Cisco HyperFlex HX Auth Handling Remote Command Execution

☑ ☆ ✇ Zero Day Initiative - Blog

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

By: Lucas Leong

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

☑ ☆ ✇ Zero Day Initiative - Blog

The June 2021 Security Update Review

By: Dustin Childs

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

☑ ☆ ✇ Zero Day Initiative - Blog

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

By: The ZDI Research Team

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

☑ ☆ ✇ Zero Day Initiative - Blog

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

By: Lucas Leong

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

☑ ☆ ✇ Zero Day Initiative - Blog

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

By: Vincent Lee

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

☑ ☆ ✇ Zero Day Initiative - Blog

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

By: Trend Micro Research Team

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

☑ ☆ ✇ Zero Day Initiative - Blog

The May 2021 Security Update Review

By: Dustin Childs

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

☑ ☆ ✇ Zero Day Initiative - Blog

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

By: Guest Blogger

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

☑ ☆ ✇ Zero Day Initiative - Blog

Parallels Desktop RDPMC Hypercall Interface and Vulnerabilities

By: Reno Robert

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

☑ ☆ ✇ Zero Day Initiative - Blog

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

By: Lucas Leong

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

☑ ☆ ✇ Zero Day Initiative - Blog

The April 2021 Security Update Review

By: Dustin Childs

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

☑ ☆ ✇ Zero Day Initiative - Blog

Pwn2Own 2021 - Schedule and Live Results

By: Dustin Childs

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

☑ ☆ ✇ Zero Day Initiative - Blog

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

By: Trend Micro Research Team

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

❌