7:42 p.m.
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
7:33 a.m.
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 :|
6:22 p.m.
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.
4:19 p.m.
New subject: [libvirt-users] Direct Kernel Boot and Security
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.
6:29 p.m.
New subject: [libvirt-users] Read-only Guests for Anti-Forensics
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)?
1:22 a.m.
New subject: [libvirt-users] Read-only Guests for Anti-Forensics
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.
9:13 a.m.
New subject: [libvirt-users] Read-only Guests for Anti-Forensics
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/
1:20 a.m.
New subject: [libvirt-users] Direct Kernel Boot and Security
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users
2371
days inactive
2409
days old
7 comments
4 participants
participants (4)
-
Daniel P. Berrangé -
Francesc Guasch -
Peter Krempa -
procmem