Hope those of you who attended Troopers16 enjoyed it as much as we did! In this post I want to summarize my Troopers16 talk and provide you with some details about freshly assigned CVE-2016-1542 and CVE-2016-1543 related to BMC BladeLogic software.
To start with, BMC Software Inc. is an American company specializing in business service management software; they develop software used for multiple functions, including IT service management, data center automation, performance management, virtualization lifecycle management and cloud computing management. Among other products they have developed a BladeLogic suite that includes Database Automation, Middleware Automation, Server Automation, and Network Automation tools. The one under our focus was BladeLogic Server Automation (BSA).
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:
Once there is proper network isolation & restriction, the vulnerability should not be exploitable from the overall corporate network (or maybe even the Internet — a quick inaccurate shodan search for “vcenter” returned about 1800 results and at random checks actually revealed vCenter systems). It should also not be exploitable from ESXi hosts managed through the vCenter: ESXi hosts need to be able to connect to the vCenter for heartbeat messages, however “only” on ports 443 and 902 — the vulnerability exploits a service running on TCP ports 9875 – 9877.
It is questionable whether the exploited Java RMI functionality is really required for the operation of VMware infrastructures. This blogpost provides further detail on the known type of vulnerability in Java applications. VMware had a similar issue back in 2010, where their workaround to fix a vulnerability was to just disable the affected component, resulting in the impression that it wasn’t even required in the first place. Let’s see whether the future will bring up more vulnerabilities which could have been prevented by implementing more thorough hardening of all components (e.g. following the minimal machine principle). Furthermore in 2011 there was a similar 3^(rd) party component vulnerability in vCenter which we covered in this blogpost. The totality of our posts on VMware security can be found here.
For high-security environments we have been recommending for some time to use a dedicated vCenter per hypervisor cluster (i.e. if you have two hypervisor clusters, one for internal and one for DMZ systems, you should use two separate vCenter systems). Vulnerabilities like these illustrate the need for that, given that the ESXi hosts need to be able to access the vCenter on the network level.
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.
During one of our latest web application code review projects I came across a vulnerability for which I think it is worth to speak about. It is an injection based attack against XML parsers which uses a rarely required feature called external entity expansion. The XML specification allows XML documents to define entities which reference resources external to the document and parsers typically support this feature by default. If an application parses XML input from untrusted sources and the parsing routine is not properly configured this can be exploited by an attacker with a so called XML external entity (XXE) injection. A successful XXE injection attack could allow an attacker to access the file system, cause a DoS attack or inject script code (e.g. Javascript to perform an XSS attack).
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.
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
