Comment 0 for bug 1449062

This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added as to the bug as attachments.

Reported via private E-mail from Richard W.M. Jones.

Turns out qemu image parser is not hardened against malicious input and can be abused to allocated an arbitrary amount of memory and/or dump a lot of information when used with "--output=json".

The solution seems to be: limit qemu-img ressource using ulimit.

Example of abuse:

-- afl1.img --

$ /usr/bin/time qemu-img info afl1.img
image: afl1.img
[...]
0.13user 0.19system 0:00.36elapsed 92%CPU (0avgtext+0avgdata 642416maxresident)k
0inputs+0outputs (0major+156927minor)pagefaults 0swaps

The original image is 516 bytes, but it causes qemu-img to allocate 640 MB.

-- afl2.img --

$ qemu-img info --output=json afl2.img | wc -l
589843

This is a 200K image which causes qemu-img info to output half a
million lines of JSON (14 MB of JSON).

Glance runs the --output=json variant of the command.

-- afl3.img --

$ /usr/bin/time qemu-img info afl3.img
image: afl3.img
[...]
0.09user 0.35system 0:00.47elapsed 94%CPU (0avgtext+0avgdata 1262388maxresident)k
0inputs+0outputs (0major+311994minor)pagefaults 0swaps

qemu-img allocates 1.3 GB (actually, a bit more if you play with
ulimit -v). It appears that you could change it to allocate
arbitrarily large amounts of RAM.