[pve-devel] New non-thin LVM volume can contain old data
Herman van Rink
helmo at initfour.nl
Tue Jan 22 09:55:03 CET 2019
Hi,
The sparse issue raised by Stoiko Ivanovin (bug 2050) made me realize
that this could have wider security implications.
When you create a new LVM volume(not thin) you just get a range of disk
blocks ... these are not zeroed. So the new user of a VM gets access to
this old 'random' data.
Steps to reproduce:
- When a disk is really empty you could first create a dummy volume and
fill that with `yes foobar | dd of=/dev/mapper/dummylv bs=1M`, then
lvremove it again. (The yes utility just keeps repeating the 'foobar'
pattern.)
- Add a new disk volume to an existing vm, on a non-thin LVM storage
- inside the vm run: `cat /dev/<new device name> | strings` # The
strings utility skips all non-printable characters
Or to reproduce outside of Proxmox:
```
lvcreate --name testempty --size 1GB <vgname>
cat /dev/<vgname>/testempty | strings
```
In my case I got parts of my own old data. But if I we're to add a
volume to a server where a client has access, they could get old data
from another client.
You could argue that this is an issue in LVM, but it becomes a problem
in a multi user system like Proxmox. Even though this may be 'by design'
in LVM, Proxmox could help prevent users falling into this trap.
lvcreate has a --zero option, but that only clears the first 4KiB.
Another possibly related bug is 1032
Solution:
Depending on the type of storage a new volume should be filled with
zero's before being used.
There could be a (default on) checkbox on the 'Add: Hard Disk' form to
skip this, but can you trust all users?
The scenario I can think of where one might want to disable this
checkbox is when your going to overwrite the whole volume anyway, and
want to avoid the delay.
--
Met vriendelijke groet / Regards,
Herman van Rink
Initfour websolutions
More information about the pve-devel
mailing list