Sometimes you discover a vulnerability when you aren’t looking for one, and sometimes, as in this case, it turns out to be a false alarm. More than 70 percent of the vulnerabilities I’ve found in my life had nothing to do with security research. I simply came across them by chance, while doing administration work, for example.
That day, for a customer whose website was getting millions of hits because of a holiday game, I decided to put the website’s content directly into memory to stop having IOPS problems. To do this, I simply used a ramdisk and synchronized the files from disk (where the code was stored) to the ramdisk every minute using rsync.
This customer was on an LXC container with 8 GB of RAM, connected to a separate MySQL server over a private network. The web server used less than 1 GB of RAM, and the applications took up less than 500 MB of disk space.
So I just created a ramdisk like this:
mkdir /home/ramdisk
echo "shm /home/ramdisk tmpfs nodev,nosuid,noexec 0 0" >> /etc/fstab
mount /home/ramdisk
rsync -avz --stats --delete /home/xxxx /home/ramdisk/
After this, I checked with a simple df -h and got a big surprise:
~# df -h
Filesystem Size Used Avail Use% Mounted on
zfstore/zfs-containers/subvol-9202234-disk-1 32G 1.4G 31G 5% /
none 492K 0 492K 0% /dev
tmpfs 26G 68K 26G 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 1.7G 0 1.7G 0% /run/shm
shm 126G 410M 126G 1% /home/ramdisk
My /home/ramdisk had a size of 126 G. I then checked, with and without it, whether it seemed to be using RAM, but memory usage was exactly the same. Very excited at the prospect of having found a new vulnerability, I checked on a new container on another cluster and successfully reproduced the problem. At the same time, I sent an email to someone I know who works on an implementation of this product. In the end, it was just a display problem: privileged containers only fail to *show* the used memory (it’s an accounting issue), but after hitting the specified limits you’ll be writing to swap space instead, and ultimately the kernel’s OOM killer will kill the container before it starts using more RAM than assigned (note that both RAM and swap limits have to be hit). End of the story :)
--
Christophe Casalegno
https://all.bo
Leave a comment
Add a comment