As part of my research on the security of paravirtualized devices, I reported a number of vulnerabilities to the Xen security team, which were patched today. All of them are double fetch vulnerabilities affecting the different backend components used for paravirtualized devices. While the severity and impact of these bugs varies heavily and is dependent on a lot of external factors, I would recommend patching them as soon as possible. In the rest of this blog post I’ll give a short teaser about my research with full details coming out in the first quarter of 2016 .
Yesterday 7Elements released the description of a Remote Code Execution vulnerability in VMware vCenter. The information came in at a good point as I’m at the moment drafting a follow-up blogpost for this one which will summarize some of our approaches to virtualization security. The vCenter vulnerability is both quite critical and particularly interesting in several ways:
This post is a short wrap-up of our Troopers talk about the research we did on IBM’s General Parallel File System. If you are interested in all the technical details take a look at our slides or the video recording. We will also give an updated version of this talk at the PHDays conference in Moscow next month.
The IBM General Parallel File System is a distributed file system used in large scale enterprise environments, high performance clusters as well as some of the worlds largest super computers. It is considered by many in the industry to be the most feature rich and production hardened distributed file system currently available. GPFS has a long and really interesting history, going back to the Tiger Shark file system created by IBM 1993.
Of course, this makes it an interesting target for security research. When looking at GPFS from an implementation point of view, the Linux version is made up of three different components: User space utilities and helper scripts, the mmfsd network daemon and multiple Linux kernel modules. We (Florian Grunow and me) spent some time analyzing the internals of these components and discovered critical vulnerabilities in all of them.
In my last blog post, I gave an overview about recent vulnerabilities discovered in the x86 emulation layer of Xen. While both of the discussed vulnerabilities only allow for guest privilege escalation, the complexity of the involved code seemed to indicate that even more interesting bugs could be discovered. So I spent some time searching for memory corruption issues and discovered a very interesting bug that resulted in XSA 123 . This post gives an overview about the root cause of the bug and a short description of exploitation challenges. A follow-up post will describe possible exploitation strategies in more detail.
Developing a secure and feature rich hypervisor is no easy task. Recently, the open source Xen hypervisor was affected by two interesting vulnerabilities involving its x86 emulation code: XSA 110 and XSA 105. Both bugs show that the attack surface of hypervisors is often larger than expected. XSA 105 was originally reported by Andrei Lutas from BitDefender. The patch adds missing privilege checks to the emulation routines of several critical system instructions including LGDT and LIDT. The vulnerable code can be reached from unprivileged user code running inside hardware virtual machine (HVM) guests and can be used to escalate guest privileges. XSA 110 was reported by Jan Beulich from SUSE and concerns insufficient checks when emulating long jumps, calls or returns.
Recently we had the pleasure to take a look at GitHub’s Enterprise appliance. The appliance allows one to deploy the excellent GitHub web interface locally to host code on-site. Besides the well known interface, which is similar to the one hosted at github.com, the appliance ships with a separate interface called the management console, which is used for administrative tasks like the configuration of the appliance itself. This management interface is completely decoupled from the user interface.
During our assessment we focused on the management console where we found several vulnerabilities (others may have found them, too). On November 11, 2014 GitHub released a security advisory which included the most critical findings that have been fixed in GitHub Enterprise 2.0.0. Because the advisory doesn’t include any detailed information, we will discuss some of those vulnerabilities in detail.
The below post was originally written on February 9th as a little educational exercise & follow-up to my BinDiff post. (This research was actually triggered by a relative asking about that strange Fritz!Box vulnerability he heard about on the radio). Once we realized the full potential of the bug we decided against publishing the post and contacted several parties instead. Amongst others this contributed to the German BSI press release. Given the cat is out of the bag now anyway, we see no reason to hold it back. We will further take this as an opportunity to lay out our basic vulnerability disclosure principles in a future post. This topic will also be discussed in the panel “Ethics of Security Work & Research” at Troopers
Fritz!Box is series of DSL and WLAN routers produced by AVM. They are extremely popular in Germany and are the uncontested market leader for private DSL customers. Recently, a significant number of Fritz!Box owners became victim of an attack that resulted in calls to expensive international numbers. The newspaper “Der Westen” reported about a case where phone calls valued over 4200€ were initiated from a compromised Fritz!Box. Few days later AVM published a security update for a large number of Fritz!Box models and urged customers to apply the patch as soon as possible.
However, no further details about the vulnerability were published. This blog post describes our analysis of the vulnerability that we performed directly after the first updates were released.