FreeBSD VuXML: Documenting security issues in FreeBSD and the FreeBSD Ports Collection

grub2-bhyve -- multiple privilege escalations

Affected packages
grub2-bhyve < 0.40_8


VuXML ID 9d6a48a7-4dad-11ea-8a1d-7085c25400ea
Discovery 2019-12-09
Entry 2020-02-12

Reno Robert reports:

FreeBSD uses a two-process model for running a VM. For booting non-FreeBSD guests, a modified grub-emu is used (grub-bhyve). Grub-bhyve executes command from guest grub.cfg file. This is a security problem because grub was never written to handle inputs from OS as untrusted. In the current design, grub and guest OS works across trust boundaries. This exposes a grub to untrusted inputs from guest.

grub-bhyve (emu) is built without SDL graphics support which reduces lot of gfx attack surface, however font loading code is still accessible. Guest can provide arbitrary font file, which is parsed by grub-bhyve running as root.

In grub-core/font/font.c, read_section_as_string() allocates section->length + 1 bytes of memory. However, untrusted section->length is an unsigned 32-bit number, and the result can overflow to malloc(0). This can result in a controlled buffer overflow via the 'loadfont' command in a guest VM grub2.cfg, eventually leading to privilege escalation from guest to host.

Reno Robert also reports:

GRUB supports commands to read and write addresses of choice. In grub-bhyve, these commands provide a way to write to arbitrary virtual addresses within the grub-bhyve process. This is another way for a guest grub2.cfg, run by the host, to eventually escalate privileges.

These vulnerabilities are mitigated by disabling the 'loadfont', 'write_dword', 'read_dword', 'inl', 'outl', and other width variants of the same functionality in grub2-bhyve.

There is also work in progress to sandbox the grub-bhyve utility such that an escaped guest ends up with nobody:nobody in a Capsium sandbox. It is not included in 0.40_8.