Re: [Xen-users] Amazon PVMs magically weren't affected by XSA 182 vuln

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 30/09/16 23:25, Chris Laprise wrote:
> On 09/27/2016 06:20 AM, George Dunlap wrote:
>> On Fri, Sep 23, 2016 at 3:34 PM, Chris
>> Laprise<tasket@xxxxxxxxxxxxxxx>  wrote:
>>> On 09/23/2016 09:42 AM, Ian Murray wrote:
>>>>> ________________________________
>>>>> From: Chris Laprise<tasket@xxxxxxxxxxxxxxx>
>>>>> To:xen-users@xxxxxxxxxxxxx
>>>>> Cc: Joanna Rutkowska<joanna@xxxxxxxxxxxxxxxxxxxxxx>
>>>>> Sent: Friday, 23 September 2016, 14:09
>>>>> Subject: [Xen-users] Amazon PVMs magically weren't affected by XSA 182
>>>>> vuln
>>>>>
>>>>>
>>>>> Hello list...
>>>>>
>>>>> Has anyone seen a good explanation as to why Amazon services were not
>>>>> vulnerable to XSA182 / CVE-2016-6258 ? I understand they offer PV
>>>>> guests
>>>>> on x86.
>>>> Perhaps because they get to patch before most people, as they are in
>>>> the
>>>> pre-disclosure list?
>>>>
>>>>
>>>> https://www.xenproject.org/security-policy.html
>>> And yet, an XSA can trigger updates at AWS that require explanation
>>> of the
>>> disruption...
>>>
>>> https://aws.amazon.com/blogs/aws/ec2-maintenance-update-2/
>>>
>>> So I wondered if in some cases Amazon's in-house versions may not
>>> have been
>>> vulnerable in the first place.
>> It's worth pointing out that everything said here is conjecture, as
>> nobody from Amazon has said anything authoritative.
>>
>> That said, there's some interesting tidbits here:
>>
>> http://www.networkworld.com/article/2892313/cloud-computing/what-happens-inside-amazon-when-there-s-a-xen-vulnerability.html
>>
>>
>> Key quotes:
>>
>> "Most of the Xen vulnerabilities do not apply to AWS because the
>> company has developed its own custom version of Xen. AWS has stripped
>> out all the features of Xen that it doesn’t need, both in order to
>> customize the performance of the open source code to the company’s
>> unique use case, and to limit its exposure to vulnerabilities. "
>>
>> "Schmidt said AWS is always looking to improve its services: both
>> technically to ensure it doesn’t have to reboot VMs, and it is working
>> to keep customers better informed. Part of that process includes
>> sponsoring academic research, including some leading studies into how
>> Xen servers can be hot-patched without requiring a reboot. "
>>
>> So two potential explanations for why they were not vulnerable:
>>
>> 1. They may have disabled the feature, so that they were never vulnerable
>>
>> 2. They may have used an internal hot-patching mechanism to apply the
>> patch without rebooting, so that the statement "we are not vulnerable"
>> was accurate at the time the vulnerability was publicly announced. :-)
>>
>>   -George
> 
> First, being able to hot-patch doesn't mean they weren't vulnerable
> before the patch. "Not affected" will be read by most as "was not
> vulnerable".

I agree with you, that "we have never been vulnerable" is a more natural
interpretation of Amazon's public statements than "we are not vulnerable
at this moment".  But this is PR we're talking about here -- and that is
exactly the kind of ambiguity which PR people like to take advantage of.

In any case, as I've said, you won't get anything from this mailing list
except people's guesses.  If you want answers, you'll have to ask Amazon.

> And Qubes OS, with its minimal-attack surface philosophy, has also
> disabled a lot of Xen features. Yet it is still affected by (i.e.
> vulnerable to) occasional  Xen vulnerabilities that AWS is not. I'm sure
> the Qubes community (and possibly Citrix) would like to know details as
> to why.
> 
> The Network World article doesn't inspire any confidence that
> information will come from Amazon, however. Through it, Amazon declares
> they have special-sauce Xen implementations that have been more secure.
> And that is as far as it goes in addressing Amazon's role as a Xen
> developer, which is the most important aspect of this issue.
> 
> The relationship between Amazon and Xen appears to be an unhealthy one
> that is ripe for abuse:
> 
> https://news.ycombinator.com/item?id=9358843
> 
> So we have a number of Xen devs saying they accept /unattributed/
> patches from Amazon, on top of their security through obscurity. That
> just seems untenable to me, like a zero-day magnet.

I'm not sure what this is supposed to mean.  Nothing can be checked into
the Xen source trees without the DCO [1] to track the copyright
ownership of the file.  The XenProject Security Policy explicitly favors
responsible disclosure, with a goal of no more than 3 weeks between an
initial vulnerability report and public disclosure [2].

Amazon are members of the XenProject (and thus contribute financially)
[3], and they are involved behind-the-scenes in other ways.  But Amazon
has never been a major code contributor to Xen; Xen's development has
never relied on Amazon's contributions, or indeed of *any* public cloud
provider.

Xen is primarily developed by the software companies who sell products
containing Xen and hardware companies that want to hardware to people
who run Xen.  This is primarily SuSE, Oracle, Citrix, and Intel, along
with a long tail of other software and hardware companies.  (FWIW KVM is
also primarily developed by companies that sell software and hardware,
and not by cloud providers.)

What Amazon does or doesn't contribute to the XenProject may reflect on
Amazon as a company, but it doesn't reflect anything about the health of
the XenProject.

 -George

[1] http://developercertificate.org/
[2] https://www.xenproject.org/security-policy.html
[3] https://www.xenproject.org/project-members.html

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
https://lists.xen.org/xen-users