[grsec] KERNEXEC^Vmware?

[Andrew Griffiths]

Hello,

On Thu, Jan 12, 2006 at 02:15:00AM +0100, pageexec at freemail.hu wrote:
> On 11 Jan 2006 at 12:56, Angelo Dell'Aera wrote:
> > This is the detailed analysis I did about the problem I found while
> > executing Vmware with KERNEXEC enabled we were talking about in the last
> > days. If needed I can provide even my .config and System.map files. So
> > let's start.

[snip]

> the oops nicely gave us the code dump around the offending EIP, the
> actual insn begins with the byte between <> which disassembles to:
> 
> 88D0                         mov         al,dl
> 24F0                         and         al,0F0
> 0C09                         or          al,009
> <88>4105                       mov         [ecx][05],al
> 
> i disassembled some insns before as well to make the explanation
> easier below. this says that we indeed have an insn that writes to
> memory (this is intel syntax, not at&t), we're writing a byte at
> the address held in ecx + 5, which according to the oops happens
> to contain 0xc05bd080 which gives 0xc05bd080+5 = 0xc05bd085, the
> reported fault address. so we can be quite sure we got the right
> guy.
> 
> now we want to know what it tried to modify. as you correctly found
> out, it's c05bd000 R cpu_gdt_table, that is, the GDT, in particular
> it's the TSS descriptor in it as arch/i386/kernel/head.S says that
> at offset 0x80 there's a TSS descriptor. from the few insns before
> we can also see that the code is trying to clear the busy bit in it

[snip]

> now that we also know
> the corresponding linear address, we can easily find out that the
> culprit was: vmmon 0 0 42895 51244 2 - Live 0xc0727000 0xf0693000
> as its code was mapped at 0xc0727000-0xc073178f (the upper boundary
> comes from 0xc0727000 + 42895). so we now know that it's indeed
> vmware that writes to the GDT.
> 
> as for fixing it, you (or vmware, if they cared) would have to add
> pax_open_kernel/pax_close_kernel calls around all the code that
> attempts to modify read-only memory. short of source code, one can
> resort to binary patching, but that'll be a bit of black magic ;-).
> 

I believe the vmmon module source code is in
/usr/lib/vmware/modules/source/vmmon.tar (ymmv) -- not sure how 
complete it is, or if it uses any .o files (doesn't look like it), but
from memory this is used when you're building the vmware modules
yourself. 

No direct reference in the source to cpu_gdt_table, but there are
references to the tss busy bit.

As for VMware caring; the guy who does the vmware-any-any updates works
for vmware last I read up on those updates, and I suspect would be the 
best person to approach to get this in the offical vmware modules.

Hope this helps,
Andrew Griffiths