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
