[libvirt-users] Virtio-net drivers immune to Nethammer?

[procmem]

Hi I'm a privacy distro maintainer investigating the implications of the
newly published nethammer attack [0] on KVM guests particularly the
virtio-net drivers. The summary of the paper is that rowhammer can be
remotely triggered by feeding susceptible* network driver crafted
traffic. This attack can do all kinds of nasty things such as modifying
SSL certs on the victim system.

* Susceptible drivers are those relying on Intel CAT, uncached memory or
the clflush instruction.

My question is, do virtio-net drivers do any of these things?

***

[0] https://arxiv.org/abs/1805.04956

[Daniel P. Berrangé]

Post by procmem
Hi I'm a privacy distro maintainer investigating the implications of the
newly published nethammer attack [0] on KVM guests particularly the
virtio-net drivers. The summary of the paper is that rowhammer can be
remotely triggered by feeding susceptible* network driver crafted
traffic. This attack can do all kinds of nasty things such as modifying
SSL certs on the victim system.
* Susceptible drivers are those relying on Intel CAT, uncached memory or
the clflush instruction.
My question is, do virtio-net drivers do any of these things?

This question is probably better directed at either linux net maintainers
list, or the qemu developers list, since that's where the virtio-net
experts will be.

Regards,
Daniel

[procmem]

Post by Daniel P. Berrangé

Post by procmem
Hi I'm a privacy distro maintainer investigating the implications of the
newly published nethammer attack [0] on KVM guests particularly the
virtio-net drivers. The summary of the paper is that rowhammer can be
remotely triggered by feeding susceptible* network driver crafted
traffic. This attack can do all kinds of nasty things such as modifying
SSL certs on the victim system.
* Susceptible drivers are those relying on Intel CAT, uncached memory or
the clflush instruction.
My question is, do virtio-net drivers do any of these things?

This question is probably better directed at either linux net maintainers
list, or the qemu developers list, since that's where the virtio-net
experts will be.
Regards,
Daniel

OK I will thanks.

[procmem]

Hi. What are the security implications for the host when using direct
kernel boot for guests that are potentially malicious? Is guest
filesystem data saved to an emulated drive or directly on the host? [0]
Direct boot seems like an otherwise more efficient way to do things.

[0] It was discovered that tenants using cloud infrastructure that used
LVM were able to recover deleted sensitive data from others however
emulated drives control the data available to the guest at a very low
level and consequently don't suffer from this huge disadvantage.

[procmem]

Hello. I'm interested in running guests as read-only to turn them into a
sort of virtualized "live=cd". The goal is to leave no forensic evidence
on the host disk or virtual one which would lead to traces on the host
still- similar to how TAILS works but with the added convenince and
flexibility of running in a VM. If I set the qcow image to read-only as
per the manual, will any changes made during a session be written to
disk (or a transient file on disk)?

[Peter Krempa]

Post by procmem
Hello. I'm interested in running guests as read-only to turn them into a
sort of virtualized "live=cd". The goal is to leave no forensic evidence
on the host disk or virtual one which would lead to traces on the host
still- similar to how TAILS works but with the added convenince and
flexibility of running in a VM. If I set the qcow image to read-only as
per the manual, will any changes made during a session be written to
disk (or a transient file on disk)?

Filesystems such as ext4 require write access to the device so they can
play back the journal when mounting. This means that you have to allow
writes.

If you want to be sure that the writes don't touch any image, you need
to create a overlay qcow2 image which will catch the writes and dispose
it after the VM is turned off.

[Francesc Guasch]

Post by Peter Krempa

Post by procmem
Hello. I'm interested in running guests as read-only to turn them into a
sort of virtualized "live=cd". The goal is to leave no forensic evidence

If you want to be sure that the writes don't touch any image, you need
to create a overlay qcow2 image which will catch the writes and dispose
it after the VM is turned off.

Shameless plug here, our tool, built on top of libvirt, has been
used for this very same purpose. You can create a base, then clone
it easily ,do your things, then erase it. You can even create volatile
clones, that get removed automatically on shutdown.

It does it internally with qcow overlays as Peter advises there.

Anyway the underlying disk drive may contain traces of the deleted
filesystems. If you want to get rid of those too, you should wipe them
somehow.

We advertise it as VDI tool but nothing stops you from using it
with any kind of OS. https://ravada.upc.edu/

[Peter Krempa]

Post by procmem
Hi. What are the security implications for the host when using direct
kernel boot for guests that are potentially malicious? Is guest

The same as for any VM. The only factor may be how the kernel for the
guest is obtained. If the kernel and initrd are present on the host it's
as every other VM.

Obviously if you try to get the kernel/initrd from the guest/VM image
there are security implications e.g. by mounting the image on the host.

Post by procmem
filesystem data saved to an emulated drive or directly on the host? [0]

This depends solely on the configuration of the <disk> so anything
related to that applies.

Post by procmem
Direct boot seems like an otherwise more efficient way to do things.
[0] It was discovered that tenants using cloud infrastructure that used
LVM were able to recover deleted sensitive data from others however
emulated drives control the data available to the guest at a very low
level and consequently don't suffer from this huge disadvantage.

Using a qcow2 image as a file can avoid this. Just set your disks
correctly.

Post by procmem
_______________________________________________
libvirt-users mailing list
https://www.redhat.com/mailman/listinfo/libvirt-users