Phrack issue #65, article #8

Discuss and suggest new grsecurity features

Phrack issue #65, article #8

Postby xstasi » Mon Apr 14, 2008 7:10 am

Hello grsecurity,

As you may have noticed, phrack #65 is out.
Those who already have read it may have seen an interesting article about a new rootkit technique (which they say has been out for 8 years already, "on the wild")
This technique relies on the Intel debug registers
You can read the full article ("Mystifying the debugger for ultimate stealthness") here:
http://phrack.org/issues.html?issue=65&id=8

Since phrack.org seems to be down ATM, you can download the .tgzed issue from my website:
http://shiningsun.altervista.org/p65.tgz

I've seen that grsecurity already did put efforts in rootkit prevention, such as the /dev/[k]mem RO support

I wonder if it's the case that we put some effort against this too, since it seems to be something serious.

I wait for your opinions...

Cheers

xstasi
xstasi
 
Posts: 13
Joined: Tue Feb 19, 2008 10:09 am

Re: Phrack issue #65, article #8

Postby spender » Mon Apr 14, 2008 9:39 am

KERNEXEC already helps prevent this rootkit technique, and the author's claims regarding its stealthiness are quite exaggerated (sorry halfdead, do some googling). KERNEXEC will prevent code modification as well as IDT modification.

To detect the hook which they claim to have implemented with "ultimate stealth" simply create a PTE which points to the same physical memory as the virtual address of the hook you wish to inspect.

Anyways, it's a good copy+paste of Intel documentation and 3 year old public windows rootkit information, applied to an easier platform ;)

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Re: Phrack issue #65, article #8

Postby halfdead » Mon Apr 14, 2008 5:29 pm

Dear Brad,

The technique I described in my paper is not new, I never claimed that. As a matter of fact, the very same technique was used before 96-97, with slight modifications, in DOS and later on in Windows. The beauty about this technique though is that it is basically an important cpu feature. My paper was indeed based on old Intel manuals, but if you are familiar with IA-32 debugging mechanism, you know there is not much documentation available for this topic apart from that.

You claim you can detect this technique by creating a PTE, I have my doubts. The thing is, this kind of technique is easy to defeat if you know the mechanism, otherwise it remains stealth. The purpose of my paper wasn't to feed the kiddies with an ultimate stealthy e-weapon, but to have them strive for knowledge and get themselves to learn more about Intel internals or the kernel. That was the reason there was no source code, I don't believe in spreading source code.

But yeah, your users should still feel safe, as they are on great hands. Keep up the good work and give us all a safer e-environment! ;)

- halfdead
halfdead
 
Posts: 1
Joined: Mon Apr 14, 2008 4:24 pm


Return to grsecurity development