Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tale of two hypervisor bugs – Escaping from FreeBSD bhyve

phrack.org

Post reply on HN
Print view View original

41–47 of 47 posts

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

#41

Post by bonzini »

yjftsjthsd-h wrote: post #25
bonzini wrote: post #17

Earlier quoted context omitted.

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.

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

KVM is indeed one of the potentially interesting file descriptors, but there is relatively little code running in kernel space.

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

#43

Post by int_19h »

saagarjha wrote: post #37
tonyarkles wrote: post #29

Earlier quoted context omitted.

Keep in mind that this is emulating old hardware. See: http://www.osdever.net/FreeVGA/vga/colorreg.htm If the size of the array changed, it would no longer be compatible with the hardware it's trying to emulate. I understand what you're trying to say and agree in general, but this is a good example of "the exception to the rule".

I guess I’m unhappy with the linkage between “this is an 8-bit value” and “this thing just happens to wrap at 256”; I would be much more satisfied if there was a clear “byte” rationale for the latter as well, which there very well might be but it’s not clear contextually. To put it differently, I’m fine with relying on the overflow behavior, but only when the semantics have an actual match. For example, I rely on it…

The array is 256 entries big, because it's a palette for an 8-bit VGA color mode, where each pixel is an index into it. The link is very obvious and natural here.

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

#44

Post by loeg »

landr0id wrote: post #32
cperciva wrote: post #20

Earlier quoted context omitted.

> politics or something of that sort I suppose you could classify "the patch doesn't work and breaks other things besides" that way.

HardenedBSD got the userland running fine. It was iirc mostly irrational fear by the FreeBSD team that someone's bad application would break.

Nope. The code had major problems that were highlighted during code review, and Shawn never fixed them.

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

#45

Post by loeg »

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?

It is trivially bypassed and has some negative performance impact. So why enable it by default? It is left as an option for the paranoid and for "checkbox compliance" type applications.

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

#46

Post by saagarjha »

loeg wrote: post #45
saagarjha wrote: post #4

Earlier quoted context omitted.

But > It is disabled by default. Why?

It is trivially bypassed and has some negative performance impact. So why enable it by default? It is left as an option for the paranoid and for "checkbox compliance" type applications.

Trivially bypassed if you have an address leak…

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

#47

Post by loeg »

saagarjha wrote: post #46
loeg wrote: post #45

Earlier quoted context omitted.

It is trivially bypassed and has some negative performance impact. So why enable it by default? It is left as an option for the paranoid and for "checkbox compliance" type applications.

Trivially bypassed if you have an address leak…

No. Trivially bypassed without a leak. Two of many examples:

https://dl.acm.org/doi/10.5555/3195638.3195686

https://www.vusec.net/projects/anc/

New timing attacks that break ASLR come out ~annually. These are hardware mechanisms that cannot be mitigated by software. ASLR is broken. (Nevermind ROP gadget compilers, etc.)

Post reply on HN