[libvirt-users] Virtio-net drivers immune to Nethammer?
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
On Sat, May 19, 2018 at 12:42:14AM +0000, procmem wrote:
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 -- |: 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 :|
Daniel P. Berrangé:
On Sat, May 19, 2018 at 12:42:14AM +0000, procmem wrote:
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.
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.
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)?
On Sun, Jun 24, 2018 at 23:29:13 +0000, procmem wrote:
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.
On 26/6/18 08:22, Peter Krempa wrote:
On Sun, Jun 24, 2018 at 23:29:13 +0000, procmem wrote:
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/
On Sun, Jun 24, 2018 at 21:19:06 +0000, procmem wrote:
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.
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.
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.
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
participants (4)
-
Daniel P. Berrangé -
Francesc Guasch -
Peter Krempa -
procmem