Microsoft Patched the Issue With Windows Containers That Enabled Siloscape

4 min read

Executive Summary

Microsoft recently added additional security checks that address the Windows container escape that we discovered last year. This is the same escape that enabled Siloscape, the first known vulnerability targeting Windows containers, which we discovered earlier this year.

Several findings regarding Windows containers led up to our report on Siloscape. We started with an overview of the architecture, followed by an article on how to use some of those findings to break out of the container.

To address the issue, Microsoft focused on the key function that enabled the container escape, which prevents exploitation. Now, there will also be a check for whether the function is being called from inside a container. If so, it will be blocked. These new changes Microsoft introduced directly prevent Siloscape’s attack technique.

However, these security checks do not completely get rid of the risk of running Windows Server containers for certain purposes. As discussed in a previous blog, we do not recommend using Windows containers as a security feature, which is consistent with guidance from Microsoft.

Palo Alto Networks Prisma Cloud protects customers from Siloscape attacks. In addition, Prisma Cloud Compute will alert customers who have old versions of their hosts that are vulnerable to known CVEs.

Technical Overview of the Issue and the Patch

Recap of Windows Container Escape Technique

As covered in detail in previous posts, an attacker who wants to abuse this issue to create a symbolic link to the host’s drive, and escape the container, needs to call the undocumented function NtSetInformationSymbolicLink with the correct parameters. Such a call will make the attacker’s chosen symbolic link global, thus pointing to the host’s objects instead of the container’s objects. A global symbolic link from inside the container can point to the host's filesystem, registry or basically any named object under the Root Directory Object.

Execution flow of the Windows container escape patched by Microsoft is shown here. It relies on using NtSetInformationSymbolicLink, as shown. — Figure 1. Execution flow of the container escape.

To successfully use NtSetInformationSymbolicLink the caller has to have SeTcbPrivilege privileges. The regular container’s user is indeed Administrator but doesn’t have the necessary privileges.

In order to obtain SeTcbPrivilege privileges an attacker can use the main container’s process, CExecSvc.exe, which has the relevant privileges. An attacker can use CExecSvc.exe’s context to gain its privileges in numerous ways, such as Thread Impersonation or good old DLL injection.

The Fix

The left image shows how NtSetInformationSymbolicLink functioned before the path. The right image shows the adjustment that protects it - the PsIsCurrentThreadInServerSilo function, which checks whether the current thread is associated with a process inside a server silo. — Figure 2. NtSetInformationSymbolicLink before (left) and after (right) the patch.

The patch is easy to understand and straightforward. Any call to NtSetInformationSymbolicLink from a thread inside a container (server silo) will be blocked with the STATUS_PRIVILEGE_NOT_HELD error code. This is done using the PsIsCurrentThreadInServerSilo function, which, as its name suggests, checks whether the current thread is associated with a process inside a server silo.

Is My Kubernetes Cluster Protected?

Windows Server 2019 is the only Windows operating system supported by Kubernetes and was also included in the patch. All versions of Windows Server 2019, including the very first one, 1809, received the fix and are protected from this issue.

If you are using a cloud provider to host your Kubernetes cluster, make sure there are no pending updates for your nodes. On the other hand, if you are hosting your cluster on your own, make sure your nodes have the latest updates installed.

Conclusion

Although this fix provides great relief since it closes the known exploits in the wild, it does not completely get rid of the risk of running Windows Server containers for certain purposes. As discussed in my previous blog, users should follow Microsoft’s guidance recommending not to use Windows containers as a security feature. Microsoft recommends using strictly Hyper-V containers for anything that relies on containerization as a security boundary. Any process running in Windows Server containers should be assumed to have the same privileges as admin on the host, which in this case is the Kubernetes node. If you are running applications in Windows Server containers that need to be secured, we recommend moving these applications to Hyper-V containers.

Nevertheless, and even though containers will always be less secure than a real Virtual Machine with a separate kernel, this fix is a move in the right direction, helping to make Windows containers as secure as their Linux counterparts.

Prisma Cloud's Runtime Protection feature learns the machine's behavior and creates a set of rules for processes. This protection against unexpected process attempting to execute can prevent a Windows container escape, in addition to the patch recently introduced by Microsoft. — Figure 4. Choosing action for unexpected processes on Prisma Cloud.

Prisma Cloud’s Runtime Protection feature learns the machine’s behavior and creates a set of rules for processes. Once the learning is complete, the user can choose the action for new, unexpected processes attempting to execute. The user can choose to alert, prevent or completely block the execution.