I recently played with the “sdk” for my nokia n900. The “sdk” is a cross compilation platform built on scratchbox. The n900 runs maemo, a debian based linux for the arm architecture. I wanted to compile netcat for the phone until i found this, which perfectly runs on the phone. Then i decided to compile hping2 - and you can download my package and install it on your n900. I’ll upload it to the maemo garage, too.
I discovered a thrashing behaviour of the Kernel based virtual machine (KVM) during my research for my thesis on security within virtual os environments. This is how it worked. With the Kernel based virtual machine it is possible to overcommit memory between multiple virtual machines. Memory overcommitment is the fact that you assign more virtual memory than physically available.
Some background knowledge first. KVM is a kernel module. It is included within the vanilla linux kernel since version 2.6.20 (Status). KVM uses Qemu for hardware emulation. Qumranet, the leading company behind KVM has been bought by Red Hat Linux. Red Hat is planning to use KVM as a base technology for virtualization purposes, desktop-virtualization as well as for server-virtualization (RedHat). KVM establishes a full virtualization through Intels Vanderpool or AMDs Pacifica Technology. KVM uses Shadow-Page-Tables to virtualize memory, so KVM can swap pages to disk if the virtual amount of memory does not fit into the physical memory.
Following scenario.
1 GB more than physically available has been commited to guests to force KVM to swap memory to disk when Evil is using all memory commited to Evil. I expected the performance of Good to be affacted in a high degree within this scenario. To measure the performance penalty I used the httperf benchmark utilty, version: httperf-0.9.0 compiled Jun 23 2008. The benchmark tried to query a static HTML page of 3704 bytes located on the apache webserver running on Good. I then forced Evil to use all its memory and KVM to swap pages to disk through a simple c-program.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define MEMORY_MB 1950
#define MEMORY_MAX (MEMORY_MB ∗ 1048576)
main ( ) {
char ∗ ch = (char∗) malloc(MEMORY_MAX);
memset(ch, 0, MEMORY_MAX);
printf("%s\n", "Memory allocated");
while(1) {
memset(ch, 1, MEMORY_MAX);
}
}
I executed the thrashing and benchmark utility from an other host located within the same subnet.
httperf --server good.local --uri /test.html --num-conn 3000 --num-call 10 --rate 100 --timeout 5
This is a very simple benchmark under normal circumstances, but within this scenario I got 3000 errors of 3000 tries through timeouts on my first attempt. The second time 2269 errors and 2295 errors on my third attempt. So I softened the benchmark even more.
httperf --server good.local --uri /test.html --num-conn 500 --num-call 10 --rate 10 --timeout 5
But again, 97, 184 and 153 errors of 500 connection attempts. To be sure that this is due to memory overcommitment, swapping and thrashing I then quit the thrashing utility - no errors occured, so the webserver was not able to perform due to thrashing behaviour of the VMM and the attack is a DoS.
Why does it happen?
Memory is overcommitted. KVM has to swap, but KVM can’t have as much information about the pages it want to swap as an usual OS. So swapping can result in thrashing behaviour when KVM is choosing pages of highly used workloads.
Well, how risky is this kind of vulnerability?
An attacker first has to get access to a VM, but this access does not have to be highly privileged - so you have to consider it as a local DoS vulnerability. Memory has to be overcommited. The KVM version used here is not the newest one available, but it is the default one available with debian’s default distribution. I will check out newer versions soon. KVM is not the most used VMM for server virtualization, but Red Hat’s attempts to use it as a base for server virtualization show that its use potentially will grow.
To backup xen domu’s while running, you can use the following shell script. You have to use lvm on your server (to create live-snapshots) and you have to use key authentification for ssh (to avoid password authentication). What is special about this script is, that it runs on a remote machine. It executes commands through ssh and receives the complete lv-dump through ssh. So you can create a central backup server, which will backup remotely on a scheduled basis and you can win a redundancy at different physical locations very easily, if your bandwidth and lv-size agrees. If your bandwidth is rather slow, you can pipe the output of dd into gzip on the remote machine - or on the backup server if your connection is fast, but your backup space is rather limited. After backing up, you can mount it the usual way:
mount -o loop backup.img /mnt
Here is the script:
#!/bin/sh if [ $# -ne 7 ] then echo “usage: xen-lvm-backup [HOST] [DOM_U] [BACKUP_LV] [BACKUP_LV_SIZE] [VG] [LV] [DEST]” exit 1 fi HOST=”$1″ DOM_U=”$2″ BACKUP_LV=”$3″ BACKUP_LV_SIZE=”$4″ VG=”$5″ LV=”$6″ DEST=”$7″ if /usr/bin/ssh -o PasswordAuthentication=no -l root $HOST /bin/true; then # able to login? /usr/bin/ssh -o PasswordAuthentication=no -l root $HOST “/usr/sbin/xm pause $DOM_U” /usr/bin/ssh -o PasswordAuthentication=no -l root $HOST “/sbin/lvcreate -L$BACKUP_LV_SIZE -s -n $BACKUP_LV /dev/$VG/$LV” /usr/bin/ssh -o PasswordAuthentication=no -l root $HOST “/usr/sbin/xm unpause $DOM_U” /bin/echo “” > $DEST /usr/bin/ssh -o PasswordAuthentication=no -l root $HOST “/bin/dd if=/dev/$VG/$BACKUP_LV” > $DEST /usr/bin/ssh -o PasswordAuthentication=no -l root $HOST “/sbin/lvremove -f /dev/$VG/$BACKUP_LV” fi
Use it without any warranty.