Tale of two hypervisor bugs – Escaping from FreeBSD bhyve

2510c39011c5 | 102 points

> The below patch fixed the issue:

          struct {
                  uint8_t         dac_state;
  -               int             dac_rd_index;
  -               int             dac_rd_subindex;
  -               int             dac_wr_index;
  -               int             dac_wr_subindex;
  +               uint8_t         dac_rd_index;
  +               uint8_t         dac_rd_subindex;
  +               uint8_t         dac_wr_index;
  +               uint8_t         dac_wr_subindex;
                  uint8_t         dac_palette[3 * 256];
                  uint32_t        dac_palette_rgb[256];
          } vga_dac;
> The VGA device emulation in bhyve uses 32-bit signed integer as DAC Address Write Mode Register and DAC Address Read Mode Register. These registers are used to access the palette RAM, having 256 entries of intensities for each value of red, green and blue. Data in palette RAM can be read or written by accessing DAC Data Register.

> After three successful I/O access to red, green and blue intensity values, DAC Address Write Mode Register or DAC Address Read Mode Register is incremented automatically based on the operation performed. Here is the issue, the values of DAC Address Read Mode Register and DAC Address Write Mode Register does not wrap under index of 256 since the data type is not 'uint8_t', allowing an untrusted guest to read or write past the palette RAM into adjacent heap memory.

Ugh, this looks like an ugly patch :( How about not letting the index overflow in the first place?

> Though FreeBSD does not have ASLR

Why not?!

saagarjha | 2 months ago

I really wish phrack.org had an RSS feed so I can keep on top of their latest papers.

bArray | 2 months ago

Any reason why phrack talks about 2016 vulnerability 4 years later? I was thinking that once security advisory is published it is a fair game.

takeda | 2 months ago

Wondering if it directly or indirectly affects xhyve and Docker’s HyperKit.

lloeki | 2 months ago

Interestingly this is the kind of thing Rust is great at protecting against, and why Firecracker is such a neat project.

monocasa | 2 months ago