In this post I want to add (yet) another perspective, motivated by a disclosure
procedure which just happened recently.
todb’s article,
R7-2015-23: Comcast XFINITY Home Security System Insecure Fail Open
is a well planned public forum vulnerability disclosure. The article itself is
very well done: It gives credit to the researcher who discovered the
vulnerability and it shows a vulnerability disclosure timeline where Rapid7
reached out to Comcast (the vendor). They even go a step further and publish the
link showing the process for discovered vulnerabilities in a Rapid7 product as
well as how Rapid7 handles disclosing those vulnerabilities they find in
external products. For their internal disclosure process, they make sure to
release a patch before “publicly announcing the vulnerability in the release
notes of the update”(rapid7 disclosure).
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 .
Given there’s quite some speculation and, as we think, misinformation going
around we think it’s helpful to add/clarify the following information:
we fully comply with the injunction and we have no intentions to violate it.
we do not plan to publish any technical information besides the report (agreed
upon with FireEye themselves) and the slides (based on the former) anyway. No
3rd parties except for the ones involved (FireEye, lawyers) have received any
additional technical information from our side, let alone an earlier version
of the report.
the injunction covers accompanying details mostly within the architecture
space, but not the core vulnerabilities themselves. Those are not part of the
injunction.
we stand by the timeline as provided below. In particular, the following two
points:
– FireEye received a draft version of the report which had the objectionable
material (as identified by the cease and desist letter) fully removed on
August 11th.
– according to the cease and desist letter FireEye’s lawyer sent us, they were
informed – from our side – about the planned talk at 44CON on Jul 23rd.
there’s an injunction, but not a lawsuit. I used the term “sue” after
consulting Merriam-Webster
which states: “sue: to seek justice or right from (a person) by legal
process”, but this might have been misinterpreted by some readers. As stated,
there’s a pending injunction, but not a lawsuit.
Please note that we won’t share legal documents with 3rd parties or publish them
as we consider this inappropriate.
Please note further that, during the whole process, our goal was to perform a
responsible disclosure procedure with its inherent objectives (namely
vulnerability remediation by vendor and education of various stakeholders
involved, see also
here
or
here).
We consider this disclosure process as concluded. We don’t see a need to add
technical details from our side as we feel that the objectives of responsible
disclosure are met (not least as patches are released since quite some time
and both
vendor & finder
have released reports).
In this post I’ll discuss some aspects of vulnerability disclosure. I don’t want
to delve into an abstract & general discussion of vulnerability disclosure (for
those
interested here’s some discussion in
the context of Google’s Project Zero,
this is the well-known CERT/CC approach,
this a paper from WEIS 2006
laying out some variants, and
finally some statement by Bruce Schneier back in 2007). Instead
I will lay out which approach we followed in the past (and why we did so) and
which developments make us consider it necessary to re-think our way of
handling. The post is not meant to provide definitive answers; it was also
written not least to provide clarity for ourselves (“write down a problem in
order to better penetrate it”) and, maybe, to serve as a starting point for a
discussion which will help the community (and us) to find a position on some of
the inherent challenges.
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
Reading
this article from
the Guardian, on this guy apparently being
banned from fully discussing research results in
his talk
at upcoming
USENIX Security, leaves me
scratching my head once more. Things might (as so often) be more complex than
they seem, but this looks like yet-another misconception as for the contribution
of security research (and its public discussion) to the greater good of us all.
Which is unfortunate for the speakers (I’ve been in a similar situation once,
receiving a threatening legal letter from a very large organization one day
before one of our Black Hat presentations and can tell you that stuff like that
doesn’t add to one’s anticipation of the talk or the event…), for the audience
(including some ERNW guys who will be a USENIX-SEC, so, btw, expect a summary
post here) and for the whole community of security researchers.
just a short, somewhat non-technical, post today: I really like
this response Ross Anderson
gave to the “UK Cards Association” asking Cambridge University for taking
offline a thesis of one of their students. It (the letter) pretty much
summarizes how security research should be treated and backed by those
interested in a more secure world we live in.
On a personal note I’d like to add that Ross’ main volume “Security Engineering:
A Guide to Building Dependable Distributed Systems”, initially published in 2001
and updated in the interim with a second edition in 2008, has been the most
influential security book for me on my long way in the infosec space (which
started back in 1997, with some workshops on firewalls I gave for IT auditors).
If I could take only one infosec book to a lonely island, it would be this one.
