[Qemu-devel] German BSI analysed security of KVM / QEMU

[Qemu-devel] German BSI analysed security of KVM / QEMU

[Stefan Weil]

Hi,

the German Bundesamt für Sicherheit in der Informationstechnik
(Federal Office for Information Security) published a study on
the security of KVM and QEMU:

https://www.bsi.bund.de/DE/Publikationen/Studien/Sicherheitsanalyse_KVM/sicherheitsanalyse_kvm.html

(article only available in German)

Summary (Google translated to English):

"In summary, it can be said that the investigated components - above all
KVM, QEMU and libvirt - are suitable for realizing a technically mature
and secure virtualization environment."

Regards
Stefan Weil

Re: [Qemu-devel] German BSI analysed security of KVM / QEMU

[Cornelia Huck]

On Fri, 13 Oct 2017 11:10:05 +0200
Stefan Weil <sw@weilnetz.de> wrote:

> Hi,
> 
> the German Bundesamt für Sicherheit in der Informationstechnik
> (Federal Office for Information Security) published a study on
> the security of KVM and QEMU:
> 
> https://www.bsi.bund.de/DE/Publikationen/Studien/Sicherheitsanalyse_KVM/sicherheitsanalyse_kvm.html
> 
> (article only available in German)

Thanks for posting this!

I only looked at the conclusion for now. Some interesting points:

- They state that QEMU's source code is well structured, readable and
  maintainable. I wonder what kind of source code they usually deal
  with ;)
- Most problems noted seemed to be related to signed<->unsigned
  conversions, but none were found to be exploitable.
- They liked hardening via stack protection, NX, and ASLR, as well as
  the mechanisms used by libvirt.
- They generally seemed to be happy with QEMU being deployed via
  libvirt.
- Restrictions imposed via KVM (guest access to some CPU registers)
  scored positive points. They did not like that Hyper-V and PMU were
  not deconfigurable.
- Lack of support for encryption/signing of network-based images was
  criticized. They ended up using Ceph and GlusterFS, which they were
  reasonably happy with.

That's just from a quick browse.

Re: [Qemu-devel] German BSI analysed security of KVM / QEMU

[Daniel P. Berrange]

On Fri, Oct 13, 2017 at 11:37:08AM +0200, Cornelia Huck wrote:
> On Fri, 13 Oct 2017 11:10:05 +0200
> Stefan Weil <sw@weilnetz.de> wrote:
> 
> > Hi,
> > 
> > the German Bundesamt für Sicherheit in der Informationstechnik
> > (Federal Office for Information Security) published a study on
> > the security of KVM and QEMU:
> > 
> > https://www.bsi.bund.de/DE/Publikationen/Studien/Sicherheitsanalyse_KVM/sicherheitsanalyse_kvm.html
> > 
> > (article only available in German)
> 
> Thanks for posting this!
> 
> I only looked at the conclusion for now. Some interesting points:
> 
> - They state that QEMU's source code is well structured, readable and
>   maintainable. I wonder what kind of source code they usually deal
>   with ;)

Most closed source apps are worse than even badly structured open
source code IME ;-)

> - Most problems noted seemed to be related to signed<->unsigned
>   conversions, but none were found to be exploitable.
> - They liked hardening via stack protection, NX, and ASLR, as well as
>   the mechanisms used by libvirt.
> - They generally seemed to be happy with QEMU being deployed via
>   libvirt.
> - Restrictions imposed via KVM (guest access to some CPU registers)
>   scored positive points. They did not like that Hyper-V and PMU were
>   not deconfigurable.
> - Lack of support for encryption/signing of network-based images was
>   criticized. They ended up using Ceph and GlusterFS, which they were
>   reasonably happy with.

Hopefully the 'luks' driver (which can be layered over any block backend
including network ones), and the TLS support for NBD would be considered
to address this last point to some degree. At least from the encryption
side.

Signing of disk images is impractical as it would imply having to download
the entire image contents to validate signature, rather defeating the point
of having a network based image. But perhaps this is lost in translation
and they mean something else by "signing of images" ?

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [Qemu-devel] German BSI analysed security of KVM / QEMU

[Cornelia Huck]

On Fri, 13 Oct 2017 10:44:00 +0100
"Daniel P. Berrange" <berrange@redhat.com> wrote:

> On Fri, Oct 13, 2017 at 11:37:08AM +0200, Cornelia Huck wrote:
> > On Fri, 13 Oct 2017 11:10:05 +0200
> > Stefan Weil <sw@weilnetz.de> wrote:
> >   
> > > Hi,
> > > 
> > > the German Bundesamt für Sicherheit in der Informationstechnik
> > > (Federal Office for Information Security) published a study on
> > > the security of KVM and QEMU:
> > > 
> > > https://www.bsi.bund.de/DE/Publikationen/Studien/Sicherheitsanalyse_KVM/sicherheitsanalyse_kvm.html
> > > 
> > > (article only available in German)  
> > 
> > Thanks for posting this!
> > 
> > I only looked at the conclusion for now. Some interesting points:
> > 
> > - They state that QEMU's source code is well structured, readable and
> >   maintainable. I wonder what kind of source code they usually deal
> >   with ;)  
> 
> Most closed source apps are worse than even badly structured open
> source code IME ;-)

Ha, that's true from my experience as well ;)

> 
> > - Most problems noted seemed to be related to signed<->unsigned
> >   conversions, but none were found to be exploitable.
> > - They liked hardening via stack protection, NX, and ASLR, as well as
> >   the mechanisms used by libvirt.
> > - They generally seemed to be happy with QEMU being deployed via
> >   libvirt.
> > - Restrictions imposed via KVM (guest access to some CPU registers)
> >   scored positive points. They did not like that Hyper-V and PMU were
> >   not deconfigurable.
> > - Lack of support for encryption/signing of network-based images was
> >   criticized. They ended up using Ceph and GlusterFS, which they were
> >   reasonably happy with.  
> 
> Hopefully the 'luks' driver (which can be layered over any block backend
> including network ones), and the TLS support for NBD would be considered
> to address this last point to some degree. At least from the encryption
> side.
> 
> Signing of disk images is impractical as it would imply having to download
> the entire image contents to validate signature, rather defeating the point
> of having a network based image. But perhaps this is lost in translation
> and they mean something else by "signing of images" ?

Could be my bad translation (they talk about "Verschlüsselung und
Signierung"), but I haven't looked what they actually tried to
accomplish.

Re: [Qemu-devel] German BSI analysed security of KVM / QEMU

[Kevin Wolf]

Am 13.10.2017 um 11:44 hat Daniel P. Berrange geschrieben:
> On Fri, Oct 13, 2017 at 11:37:08AM +0200, Cornelia Huck wrote:
> > - Lack of support for encryption/signing of network-based images was
> >   criticized. They ended up using Ceph and GlusterFS, which they were
> >   reasonably happy with.
> 
> Hopefully the 'luks' driver (which can be layered over any block backend
> including network ones), and the TLS support for NBD would be considered
> to address this last point to some degree. At least from the encryption
> side.

They refer to a blog post of yours about the weakness of the AES
encryption in qcow2, but it seems they didn't see that luks exists as a
replacement. While the qcow2 integration of luks is new in 2.10, we've
had the separate 'luks' driver for a while. Do we need to inform our
users better about it?

The option of using LUKS on the host is mentioned, but also that libvirt
doesn't support this, so it comes with manual work.


They saw the TLS support in NBD, but had the impression it's not mature:

    nbd sieht zwar einen Schutz durch TLS vor, dieser wird jedoch als
    experimentell bezeichnet und nicht für den produktiven Betrieb
    empfohlen.

("nbd provides protection by TLS; however, this is described as
experimental and not recommended for production")

> Signing of disk images is impractical as it would imply having to download
> the entire image contents to validate signature, rather defeating the point
> of having a network based image. But perhaps this is lost in translation
> and they mean something else by "signing of images" ?

I suppose they mean something on a per-block basis, like a checksum or
hash that is included in the encryption and can be used to verify that
nobody changed the encrypted data from outside.

    Darüber hinaus besitzt qcow2 keinerlei Integritätsschutz. Selbst wenn
    die Verschlüsselung als ausreichend sicher angesehen werden würde, so
    ist es dem Angreifer prinzipiell weiterhin möglich, den Inhalt des
    Blockgeräts zu modifizieren

("In addition, qcow2 has no integrity protection. Even if the
encryption were considered sufficiently secure, in priciple the attacker
could still modify the content of the block device.")

They mention dm-integrity as an option to implement this on the host
kernel level.


Another thing that made me a bit sad is that they mention qed as a
better performing alternative for qcow2. Even in 2017, people keep
spreading this nonsense. :-(

Kevin

Re: [Qemu-devel] German BSI analysed security of KVM / QEMU

[Daniel P. Berrange]

On Mon, Oct 16, 2017 at 03:22:46PM +0200, Kevin Wolf wrote:
> Am 13.10.2017 um 11:44 hat Daniel P. Berrange geschrieben:
> > On Fri, Oct 13, 2017 at 11:37:08AM +0200, Cornelia Huck wrote:
> > > - Lack of support for encryption/signing of network-based images was
> > >   criticized. They ended up using Ceph and GlusterFS, which they were
> > >   reasonably happy with.
> > 
> > Hopefully the 'luks' driver (which can be layered over any block backend
> > including network ones), and the TLS support for NBD would be considered
> > to address this last point to some degree. At least from the encryption
> > side.
> 
> They refer to a blog post of yours about the weakness of the AES
> encryption in qcow2, but it seems they didn't see that luks exists as a
> replacement. While the qcow2 integration of luks is new in 2.10, we've
> had the separate 'luks' driver for a while. Do we need to inform our
> users better about it?

There is definitely room to improve our docs and general presentation
of QEMU security features.

> The option of using LUKS on the host is mentioned, but also that libvirt
> doesn't support this, so it comes with manual work.

Yep

> They saw the TLS support in NBD, but had the impression it's not mature:
> 
>     nbd sieht zwar einen Schutz durch TLS vor, dieser wird jedoch als
>     experimentell bezeichnet und nicht für den produktiven Betrieb
>     empfohlen.
> 
> ("nbd provides protection by TLS; however, this is described as
> experimental and not recommended for production")

They probably read the old version of the NBD protocol specification
from early 2016 where TLS was still listed as "Experimental", due to
not having any implementation of the TLS spec. This "Experimental"
tag was removed after we released TLS in QEMU


> > Signing of disk images is impractical as it would imply having to download
> > the entire image contents to validate signature, rather defeating the point
> > of having a network based image. But perhaps this is lost in translation
> > and they mean something else by "signing of images" ?
> 
> I suppose they mean something on a per-block basis, like a checksum or
> hash that is included in the encryption and can be used to verify that
> nobody changed the encrypted data from outside.
> 
>     Darüber hinaus besitzt qcow2 keinerlei Integritätsschutz. Selbst wenn
>     die Verschlüsselung als ausreichend sicher angesehen werden würde, so
>     ist es dem Angreifer prinzipiell weiterhin möglich, den Inhalt des
>     Blockgeräts zu modifizieren
> 
> ("In addition, qcow2 has no integrity protection. Even if the
> encryption were considered sufficiently secure, in priciple the attacker
> could still modify the content of the block device.")
> 
> They mention dm-integrity as an option to implement this on the host
> kernel level.

Ah ok. I would think the user could  still run dm-integrity inside their
guest if they wanted to detect tampering explicitly instead of getting
back garbage decrypted data.

> Another thing that made me a bit sad is that they mention qed as a
> better performing alternative for qcow2. Even in 2017, people keep
> spreading this nonsense. :-(

Probably because when you google for QED you inevitably hit this article
near the top:

  https://www.phoronix.com/scan.php?page=news_item&px=OTY0MQ

And there's little clear information on QEMU website to show that QED
is essentially an obsolete experiment.

Perhaps some clear update to this page would help, and also in the
qemu docs

  https://wiki.qemu.org/Features/QED


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [Qemu-block] German BSI analysed security of KVM / QEMU

[Alberto Garcia]

On Mon 16 Oct 2017 03:38:12 PM CEST, Daniel P. Berrange wrote:
>> Another thing that made me a bit sad is that they mention qed as a
>> better performing alternative for qcow2. Even in 2017, people keep
>> spreading this nonsense. :-(
>
> Probably because when you google for QED you inevitably hit this article
> near the top:
>
>   https://www.phoronix.com/scan.php?page=news_item&px=OTY0MQ
>
> And there's little clear information on QEMU website to show that QED
> is essentially an obsolete experiment.

I remember having to ask on IRC in order to learn what the status of QED
was, I couldn't figure it out just by reading the documentation or even
the mailing list archives.

Berto

Re: [Qemu-devel] German BSI analysed security of KVM / QEMU

[Kevin Wolf]

Am 16.10.2017 um 15:38 hat Daniel P. Berrange geschrieben:
> > Another thing that made me a bit sad is that they mention qed as a
> > better performing alternative for qcow2. Even in 2017, people keep
> > spreading this nonsense. :-(
> 
> Probably because when you google for QED you inevitably hit this article
> near the top:
> 
>   https://www.phoronix.com/scan.php?page=news_item&px=OTY0MQ
> 
> And there's little clear information on QEMU website to show that QED
> is essentially an obsolete experiment.
> 
> Perhaps some clear update to this page would help, and also in the
> qemu docs
> 
>   https://wiki.qemu.org/Features/QED

I updated the wiki page, maybe this will help a bit.

We could also consider printing a warning when you create a new image in
an obsolete native qemu format (i.e. qcow1 and qed).

Kevin

Re: [Qemu-devel] German BSI analysed security of KVM / QEMU

[Stefan Weil]

Am 13.10.2017 um 11:37 schrieb Cornelia Huck:
> On Fri, 13 Oct 2017 11:10:05 +0200
> Stefan Weil <sw@weilnetz.de> wrote:
>
>> Hi,
>>
>> the German Bundesamt für Sicherheit in der Informationstechnik
>> (Federal Office for Information Security) published a study on
>> the security of KVM and QEMU:
>>
>> https://www.bsi.bund.de/DE/Publikationen/Studien/Sicherheitsanalyse_KVM/sicherheitsanalyse_kvm.html
>>
>> (article only available in German)
> Thanks for posting this!
>
> I only looked at the conclusion for now. Some interesting points:
>
> - They state that QEMU's source code is well structured, readable and
>   maintainable. I wonder what kind of source code they usually deal
>   with ;)
> - Most problems noted seemed to be related to signed<->unsigned
>   conversions, but none were found to be exploitable.
> - They liked hardening via stack protection, NX, and ASLR, as well as
>   the mechanisms used by libvirt.
> - They generally seemed to be happy with QEMU being deployed via
>   libvirt.
> - Restrictions imposed via KVM (guest access to some CPU registers)
>   scored positive points. They did not like that Hyper-V and PMU were
>   not deconfigurable.
> - Lack of support for encryption/signing of network-based images was
>   criticized. They ended up using Ceph and GlusterFS, which they were
>   reasonably happy with.
>
> That's just from a quick browse.


I already found some weaknesses in the study:

* It makes the wrong assumption that all maintainers have write access
to the git repository. (chapter 5.3)
* It does not mention important quality measures like Coverity Scan,
Continuous Integration and automated tests.

So QEMU is even better than the BSI thinks. :-)

Stefan