/bugzilla3/ Bug 1817 – pv bootloader doesn't check the size of the bzip2 or lzma compressed kernel
Bug 1817 - pv bootloader doesn't check the size of the bzip2 or lzma compressed kernel
: pv bootloader doesn't check the size of the bzip2 or lzma compressed kernel
Product: Xen
: unstable
: All Linux
: P5 major
Assigned To: Xen Bug List
  Show dependency treegraph
Reported: 2012-05-04 01:37 CDT by Xinli Niu
Modified: 2012-08-09 22:48 CDT (History)
2 users (show)

See Also:

pygrub crashed (16.64 KB, image/jpeg)
2012-05-04 01:37 CDT, Xinli Niu
out of memory (25.66 KB, image/jpeg)
2012-05-04 01:38 CDT, Xinli Niu
xen-related processes occupy the cpus, and kswapd is busying swapping (23.80 KB, image/jpeg)
2012-05-04 01:39 CDT, Xinli Niu
domU boots successfully at a great cost (16.87 KB, image/jpeg)
2012-05-04 01:40 CDT, Xinli Niu

Note You need to log in before you can comment on or make changes to this bug.
Description Xinli Niu 2012-05-04 01:37:30 CDT
Created attachment 1053 [details]
pygrub crashed

Description of problem:
The pv bootloader doesn't check the size of a bzip2 or lzma compressed kernel
image.  Denial of service can be caused by padding a large file at the end of
the kernel image, which can be used by a malicious domU root.
I have put this bug at redhat bugzilla, no response yet.

Version-Release number of selected component (if applicable):
Fedora 16 with xen-4.1.2 and possibly all the xen versions that support bzip2
and lzma kernels

How reproducible:

Steps to Reproduce:

1. compile a bzip2-compressed kernel in a pv domU
2. cat  large_file  >>  vmlinuz
3. reboot

Suppose the /boot section is large enough , the pv guest has 512M memory, and
the host is 64-bit.(The same for 32-bit OS but 32-bit OS can't allocate larger
memory space and open bigger file)  

Actual results:

On my machine(a virtual machine in vmware): 
The large_file is 9G in size. (I generated it with dd from /dev/zero)

When I allocate 4G memory to dom0 with 4G swap space, the domU can't be started
for lack of memory.
See attachment 1 [details],2 and 3 for more information. The system is busying
swapping but eventually runs out of memory and swap space, causing pygrub
crashing. It takes nearly 10 minutes. 

Then I allocate 12G memory to dom0, domU can be started but at a great cost. It
takes nearly 5 minutes. See  attachment 4 [details]  for more information.

Expected results:
The guest can't be started because it has only 512M memory. (In a real machine
as long as the machine has enough memory , it can be started)

Additional info:

This bug can be used to launch a denial of service attack. If the domU
automatically restart at a xen-tolerant interval(eg. 2 minutes), the resource
will be occupied by this vm for most of the time.   Also , it is unfair and not
reasonable to allocate 10G memory just for starting a 512M-memory virtual
In a physical machine or a hvm guest, as long as the kernel image it not bigger
than the maximum memory , then the os can be booted. 
As for the gzip-compressed kernel image in a pv-domU,the size is limited to
1G.But this still has the problem, because the dom0 may allocate 512M to start
a 128M-domU.
To make the pv domU more like a real machine, I think the bootloader should not
allocate a memory space larger than the domU has.
Comment 1 Xinli Niu 2012-05-04 01:38:59 CDT
Created attachment 1054 [details]
out of memory
Comment 2 Xinli Niu 2012-05-04 01:39:37 CDT
Created attachment 1055 [details]
xen-related processes occupy the cpus, and  kswapd is busying swapping
Comment 3 Xinli Niu 2012-05-04 01:40:10 CDT
Created attachment 1056 [details]
domU boots successfully at a great cost
Comment 4 Xinli Niu 2012-05-13 03:47:34 CDT
This has been assigned CVE-2012-2625 by MITRE.

The following is the bug track filed at Red Hat Bugzilla:
Comment 5 zhangzhe 2012-08-09 22:48:42 CDT
Congratulations on your brilliant work!
I am trying to make it work on suse 11.3 + xen 4.0.0, but failed all the time
this is my process, need your advice:
1, set up the XEN, with 2 VM installed
2, downloaded a VM image, run it, OK
xm create -c XX.cfg

3, with dd, I padded the image file to 10GB
dd if=/dev/zero of=./tmp bs=1G count=10
cat ./tmp >> ./XX.img
4, trying to redo step 2
the running is OK, no memory/ CPU peak load
can you tell me where i can improve? thank you in advance
my email is zhangzhe@huawei.com