Tale of two hypervisor bugs – Escaping from FreeBSD bhyve • Hacker News Board

Tale of two hypervisor bugs – Escaping from FreeBSD bhyve

#1

Post by 2510c39011c5 » Tue, Apr 07, 2020, 6:26 PM UTC

Tale of two hypervisor bugs – Escaping from FreeBSD bhyve
phrack.org

Re: Tale of two hypervisor bugs – Escaping from FreeBSD bhyve

#2

Post by saagarjha » Tue, Apr 07, 2020, 6:59 PM UTC

> 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?!

Re: Tale of two hypervisor bugs – Escaping from FreeBSD bhyve

#3

Post by simcop2387 » Tue, Apr 07, 2020, 7:05 PM UTC

saagarjha wrote: post #2

> 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…

Time it looks like. Future versions are getting it apparently.

https://wiki.freebsd.org/ASLR

Re: Tale of two hypervisor bugs – Escaping from FreeBSD bhyve

#4

Post by saagarjha » Tue, Apr 07, 2020, 7:08 PM UTC

simcop2387 wrote: post #3

saagarjha wrote: post #2

> 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…

Time it looks like. Future versions are getting it apparently. https://wiki.freebsd.org/ASLR

But

> It is disabled by default.

Why?

Re: Tale of two hypervisor bugs – Escaping from FreeBSD bhyve

#5

Post by simcop2387 » Tue, Apr 07, 2020, 7:11 PM UTC

saagarjha wrote: post #4

simcop2387 wrote: post #3

Earlier quoted context omitted.

Time it looks like. Future versions are getting it apparently. https://wiki.freebsd.org/ASLR

But > It is disabled by default. Why?

Judging by the fact that at least ntpd gets broken by it I suspect it's again more a time issue. It'll take time to make sure that anything broken by it either gets fixed or properly documented as needing a work-around. Otherwise when it first ships it's going to break a lot of systems when people switch.

Re: Tale of two hypervisor bugs – Escaping from FreeBSD bhyve

#6

Post by monocasa » Tue, Apr 07, 2020, 7:16 PM UTC

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

Re: Tale of two hypervisor bugs – Escaping from FreeBSD bhyve

#7

Post by justincormack » Tue, Apr 07, 2020, 7:26 PM UTC

monocasa wrote: post #6

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

Firecracker also doesn't have this sort of complex device emulation such as VGA, only minimal virtio devices.

Re: Tale of two hypervisor bugs – Escaping from FreeBSD bhyve

#8

Post by kccqzy » Tue, Apr 07, 2020, 7:30 PM UTC

monocasa wrote: post #6

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

How does Rust prevent you from choosing the wrong size for an integer? It's easy to imagine a bug in Rust code in which someone is supposed to write "u8" as in this case, but didn't think carefully and just used "usize" (the most typical integer type used for indices).

Re: Tale of two hypervisor bugs – Escaping from FreeBSD bhyve

#9

Post by saagarjha » Tue, Apr 07, 2020, 7:33 PM UTC

kccqzy wrote: post #8

monocasa wrote: post #6

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

How does Rust prevent you from choosing the wrong size for an integer? It's easy to imagine a bug in Rust code in which someone is supposed to write "u8" as in this case, but didn't think carefully and just used "usize" (the most typical integer type used for indices).

It would prevent the out-of-bounds read and write, presumably.

Re: Tale of two hypervisor bugs – Escaping from FreeBSD bhyve

#10

Post by landr0id » Tue, Apr 07, 2020, 7:46 PM UTC

simcop2387 wrote: post #3

saagarjha wrote: post #2

> 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…

Time it looks like. Future versions are getting it apparently. https://wiki.freebsd.org/ASLR

HardenedBSD (FreeBSD fork) has had ASLR and other mitigations since forever. Shawn submitted a patch that was never merged because of mailing list politics or something of that sort + people afraid it was going to break the world.

https://reviews.freebsd.org/D473