Xen project Mailing List

On Thu, May 14, 2015 at 1:40 PM, Lars Kurth <lars.kurth.xen@xxxxxxxxx> wrote:

Hi folks,

although a lot of interesting suggestions were raised, I think it is more helpful to propose concrete text changes or additions, rather than suggestions which require that the author does additional research.

That would be indeed helpful ;)

> Also, is it worth mentioning why the qemu stub domain isn't the default?Â Is it all compiled and installed in most of the hypervisor distributions on Ubuntu/CentOS/etc?Â I don't think even XenServer uses qemu stub domains, although that might have changed in the recent release.

Is there a conclusion or a concrete paragraph on this one that you can suggest? I did check Ubuntu and a few other distros and they all have stub domains. XenServer may not have. But the domain may of course not be built, even though the
I suppose any outcome/mention should deb in the "One would think this is a complex...."

I'll add a discussion on why stubdoms might not be provided by default - tradeoff between memory usage vs security and the fact that everyone should use it on a given host to gain the extra protection.

@Tamas:

I would propose to position this as a guest blog post: we normally do this for someones 1st blog post on xenproject.org. Normally what we do in such cases is to add a pre-amble. An example is: "This is a guest blog post by Georg DÃrn, a long-time system administrator and open source enthusiast. Georg founded his company its-doern in 2008, to develop solutions for customers entirely from open source software."

If you could add a brief description that would be great.

Sure.

> The recent disclosure of the VENOM bug affecting major open-source hypervisors, such as KVM and Xen, has been circulating in the tech news lately, causing
how about replacing lately with a date
> many to reevaluate their security posture when using cloud infrastructures. That is a very good thing indeed. Virtualization and the cloud has been for too long
I am not sure what you mean by security posture: maybe a more common phrase would be better or an example.

Ack, I'll just say "reevaluate their risks".

I also think that some of the more recent Venom articles are partly also calling out the Venom coverage a clever marketing campaign by CrowdStrike to raise their profile and it is also now clear that far fewer vendors than originally anticipated are affected by Venom
* http://www.csoonline.com/article/2922066/vulnerabilities/venom-hype-and-pre-planned-marketing-campaign-panned-by-experts.html
* http://gizmodo.com/please-stop-comparing-every-security-flaw-to-heartbleed-1704259495
* http://www.forbes.com/sites/thomasbrewster/2015/05/13/venom-vulnerability-could-hit-amazon-oracle-rackspace-citrix/
* http://www.theregister.co.uk/2015/05/13/heartbleed_eat_your_heart_out_venom_vuln_poisons_countless_vms/
* http://www.zdnet.com/article/venom-the-anti-toxin-is-here/

I know, that's why I felt it would be good to address this. For those paying attention this is not really news. Yes, it needs to be fixed but it's not like it wasn't anticipated in general..

> erroneously considered to be a silver bullet against intrusions, malware and APTs.
What is an APT?

Marketing buzz word for targeted attacks. I'll cut it ;)

> The cloud is anything but a safe place.
I am not sure we want to single out the cloud. Maybe, expand the list a bit, e.g. the "internet and cloud". After all we are no worse than other software stacks. Maybe we have a better track record than most.

I completely agree but I still want to highlight that the cloud is not bullet proof. Many people just stare at you blankly when it comes to discussing cloud security and why it's needed (in my experience). It raises the bar. It doesn't solve all your problems and can even introduce new ones.

> VENOM in that sense is just another one in the long list of vulnerabilities that seem to be plaguing hypervisors.
Again, maybe not single out hypervisors

As I said, I kind of want to make people aware that hypervisors have problems too. Maybe "plaguing" is a harsh description though ;)

> However, there are differences between vulnerabilities. While VENOM is indeed a serious bug and can result in a VM escape, which can compromise all VMs on
> the host, it doesnât have to be. In fact, VENOM-style attacks have been known for a long time. And there are easy-to-deploy co
> unter-measures to mitigate the risk of such exploits, natively available in Xen and KVM.
Are there ways to mitigate this for KVM? When I read this I was expecting to read about KVM also. So maybe drop KVM here, as it feels like a loose ends.
Actually re-reading this again, you do mention KVM sVirt SELinux policies: it's easy to miss because that paragraph is embedded into a longer section about stub domains. Maybe add something immediately afterwards along the lines of "Xen provides subdomains to sandbox VENOM style exploits in a de-priviledged domaon and KVM allows for similar jailing of the QEMU process via the native SELinux sVirt policies."

Yea, that makes sense. Red Hat already posted a blog entry saying sVirt protects against this.

> While modern systems come ...
> Devices such as your network card, graphics card and your hard drive. While Linux comes with paravirtual (virtualization-aware) drivers to create such devices, > > emulation is often the only solution to run operating systems that do not have such kernel drivers. This has been traditionally the case with Windows. This
> emulation layer has been implemented in QEMU, which has caused VENOM and a handful of other VM-escape bugs in recent years
Maybe list some examples re QEMU related VM-escaped bugs

Sure.

I think it is worth pointing pout that people use PVHVM (HVM) for performance reasons also. One gets the impression from this paragraph that the only reason

Ack.

> Back in 2011, the Blackhat talk on Virtunoid demonstrated such a VM escape attack against KVM, through QEMU.
Link?

I have a set of footnotes with links that didn't copy in the original email. I'll copy those too in the next revision.

> As a sidenote, KVM allows for similar jailing of the QEMU process via the native SELinux sVirt policies.
See above

> One would think it is a complex process to take advantage of this protection,
Maybe link to http://wiki.xenproject.org/wiki/Device_Model_Stub_Domains

Yeap, had the link in a footnote.

> Unfortunately, your cloud provider may not allow you to enable this option.
You should probably also call out distros

Regards
Lars

Thanks,

Tamas

> On 14 May 2015, at 11:59, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>

> On Thu, 14 May 2015, George Dunlap wrote:
>> On 05/14/2015 11:39 AM, Anil Madhavapeddy wrote:
>>> Yeah... it's worth noting that unikernels like MirageOS or HaLVM never use the x86 device emulation and so require a far easier to audit hypervisor TCB that doesn't involve qemu.
>>>
>>> Also, is it worth mentioning why the qemu stub domain isn't the default?Â Is it all compiled and installed in most of the hypervisor distributions on Ubuntu/CentOS/etc?Â I don't think even XenServer uses qemu stub domains, although that might have changed in the recent release.
>>
>> Well the main reason is that qemu-upstream doesn't work with stub
>> domains yet.Â Anthony worked on it for what, a year?Â He got pretty far
>> but there are just a lot of thorny issues to deal with.
>
> To be fair, there are also other reasons: memory overhead, number of
> domains doubling, and the additional complexity of having 2 QEMUs for
> each domain (there is still one QEMU in Dom0 running for each guest,
> although it just provides the PV backends).
>

> _______________________________________________
> Publicity mailing list
> Publicity@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity

www.novetta.com

Tamas K Lengyel

Senior Security Researcher

7921 Jones Branch Drive

McLean VA 22102

Email Âtlengyel@novetta.com

Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks