[Dailydave] Things pipacs said

[Dave Aitel]

Ok, so pipacs is no joke, as is obvious to all of us, but I really wanted
to drill down and shorten his point, which is this:
When you make a hypervisor do real work, you turn it into a kernel. And the
level of access you have on a kernel (even sandboxed) for a reasonable
workload is almost always enough to get full control of it.

I'm sure Halvar has some math which classifies the level of complexity a
kernel needs before it is exploitable, but the general feeling is true.
"Thin hypervisors" are a pipe dream. They almost always expand until you
can get your printer to work.
-dave

Read below:
http://theinvisiblethings.blogspot.pt/2010/08/skeletons-hidden-in-linux-closet.html

Hi Joanna,

i think there's a misunderstanding regarding 'kernel exploits'. to explain
i'll give you an analogy.

so-called return-to-libc attacks have been publicly known since at least
solar_diz's famoust post on bugtraq in the previous millennium. i think
it's obvious to anyone skilled in the art that the name of the technique
itself has never prevented anyone from writing an exploit that relied on
another piece of code, or even arbitrary chunks of code (vs. libc API
calls). in fact we know it for a fact since there're even public exploits
that do just that, many years before the current marketing distractment
called ROP/JOP/etc entered the public mind as if they were something new.
so what we can see here is an exploit technique named after its first
public incarnation but that doesn't mean it wasn't meant to cover the whole
set of techniques that relies on executing existing code, wherever it may
be in memory.

now the analogy is that 'kernel exploits' never meant 'guest kernel
exploits' (regardless of ring-0 or ring-3, or whatever), but they always
meant 'exploits against bugs in the TCB'. and since in a traditional OS
where such exploits were written originally the kernel code running in
ring-0 happens to be part of the TCB, the name stuck.

now what this means for Qubes is that your claim about eliminating
'kernel-level exploits' would require no exploitable bugs in Xen (the
hypervisor) and dom0 at least (be that by provable construction or just
intrusion prevention techniques). and i think we all agree that you don't
have such a thing, nor does anyone else to date ;). the alternative
intrepretation of your claim would be that you solved the problem by
declaring it not to be a problem (e.g., "we don't care about user->ring0
attacks in Qubes ' AppVMs", "In Qubes OS we assume the attacker already has
root in the AppVM" or "We *really* don't care about the attacker going from
user-to-root in a VM.") and i don't think you really meant that ;).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.immunityinc.com/pipermail/dailydave/attachments/20170731/640ce566/attachment.html>