[HN Gopher] Tale of two hypervisor bugs - Escaping from FreeBSD ...
___________________________________________________________________
Tale of two hypervisor bugs - Escaping from FreeBSD bhyve
Author : 2510c39011c5
Score : 65 points
Date : 2020-04-07 18:26 UTC (4 hours ago)
(HTM) web link (phrack.org)
(TXT) w3m dump (phrack.org)
| saagarjha wrote:
| > 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?!
| EvanAnderson wrote:
| re: "How about not letting the index overflow..."
|
| I'm fairly certain a real hardware VGA implementation would
| maintain that index as an unsigned 8-bit value. There's no
| letting the index overflow, per se. It should overflow back to
| zero when incremented at 0xFF. The mistake was representing it
| as anything other than an 8-bit number because that's what the
| hardware really would have done.
|
| If I had the patience (and a machine close at hand) I'd boot
| MS-DOS and run thru a little test in DEBUG to see how it acts
| on a real card to write beyond address 0xFF via the auto-
| increment feature.
|
| Most of the palette-cycling / setting code I ever wrote just
| updated the entire palette at once and stopped. I can't think
| of any particular reason why somebody would want to overflow
| the DAC write index but it should work. (I suppose there's
| probably some demoscene code out there somewhere that
| repeatedly updates the entire palette, outputting to the
| address write register once then just banging on 0x3c9
| repeatedly...)
| msla wrote:
| > If I had the patience (and a machine close at hand) I'd
| boot MS-DOS and run thru a little test in DEBUG to see how it
| acts on a real card to write beyond address 0xFF via the
| auto-increment feature.
|
| Good excuse to load up a bunch of old games and see how they
| work, or fail to. The old Raymond Chen test: Grab a bunch of
| old software and let the application programmers bang on the
| emulation layer. Abandonware and old shareware on archive.org
| makes this a lot cheaper than you might imagine.
|
| https://archive.org/details/softwarelibrary_msdos
| simcop2387 wrote:
| Time it looks like. Future versions are getting it apparently.
|
| https://wiki.freebsd.org/ASLR
| saagarjha wrote:
| But
|
| > It is disabled by default.
|
| Why?
| yjftsjthsd-h wrote:
| FreeBSD has a very strong commitment to stability and
| making things work in new releases that working in old
| releases. This results in fairly conservative defaults.
| moonchild wrote:
| "Regression in FreeBSD 12.1-RELEASE-p4: the exploit I was
| using in -p3 is no longer usable."
| simcop2387 wrote:
| 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.
| bonzini wrote:
| What privileges does bhyve run under? Exploiting a properly
| sandboxed QEMU does give you access to some potentially
| interesting file descriptor but, unless you can use them to
| get kernel code execution, your process will not have access
| to any resources on the host that wouldn't be already
| accessible from inside the VM.
| saagarjha wrote:
| There's a section on sandbox escapes.
| yjftsjthsd-h wrote:
| Doesn't running it with KVM enabled put you back into
| kernel space? I'm sure doing everything in userspace is
| safer, but TCG is nowhere near as performant...
| monocasa wrote:
| The vast majority of the device emulation is in user
| space, even with KVM.
| monocasa wrote:
| Almost all attacks these days are a chain of exploits that
| each focus on jumping code execution to a new context or
| gaining a new privilege, that only when combined give you
| the access you're looking for as an attacker.
| landr0id wrote:
| 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
| cperciva wrote:
| > politics or something of that sort
|
| I suppose you could classify "the patch doesn't work and
| breaks other things besides" that way.
| int_19h wrote:
| This doesn't let the index overflow with the minimum amount of
| hassle. The behavior of unsigned overflow is well-defined in C,
| so there's no point writing code with an explicit check that is
| tricky to do correctly.
| bArray wrote:
| I really wish phrack.org had an RSS feed so I can keep on top of
| their latest papers.
| heavyset_go wrote:
| So do I!
| monocasa wrote:
| Interestingly this is the kind of thing Rust is great at
| protecting against, and why Firecracker is such a neat project.
| justincormack wrote:
| Firecracker also doesn't have this sort of complex device
| emulation such as VGA, only minimal virtio devices.
| monocasa wrote:
| At the moment.
| dathinab wrote:
| And in the future. The project explicitly does not want to
| provide anything beyond the things required for it's use
| case (mostly non computation intensive course servers like
| used for serverless computing platforms). Part of it's
| upperformance comes from the thinks they don't support.
|
| (Edit: as far as I know)
| monocasa wrote:
| They're in the process of pulling the core out to share
| with VMMs that don't take the same asceticism, but to
| still allow what they at Amazon ship to be a small attack
| surface. This work is in the rust-vmm project.
| kccqzy wrote:
| 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).
| monocasa wrote:
| The palette memory would be bounds checked, which is the real
| bug.
| saagarjha wrote:
| It would prevent the out-of-bounds read and write,
| presumably.
___________________________________________________________________
(page generated 2020-04-07 23:00 UTC)