>
> Well, BG 1.0 Free Demo (http://www.immunitysec.com/bodyguard.html) does
> do the dereference. E.G. It checks the system call code itself, not the
> sysent32 table. So theoretically adding exece to BodyGuard's checksum
> table _would_ catch this method, at least for the moment. :> (I'll try
> this later today to make sure.) Did you check to see if you could do the
> same trick to stat64?
yes, you are right. I have a misunderstanding on the checksum issue
and it makes a lot of sense and is a good idea to do checksum on the
function level.
Still the fundamental problem is bodyguard is also trusting a subverted
kernel, this means that any internal kernel function is being used by bodyguard
could be changed in a way that it will detect bodyguards existence and
feed false information or even change bodyguard itself ... for example
ddi_enter_critical or mod_install can be hooked in away that it will do a
kobj_getsymvalue() one or more exported symbols of bodyguard
(myverify, md5_XXXXXX, verify_syscalls...) and if the symbol/s resolve
it will patch that function with a "return TRUE" instruction ... ;-)
ofcourse patching must be done at the entry point somewhere, most likely
the first instruction ....
primary_inhouse_kernel_function_used_by_bodyguard()
{
.....
if(kobj_getsymvalue(verify_syscalls,1)){
do page protection manipulation
patch the proper place with "return TRUE" of the verify_syscalls()
!! this will make verify_syscalls return TRUE meaning no problems
}
....
do the realstuff ...
}
this will render any kernel integrity level checker useless. solution
is simple integrity checkers have to be stealh to like their counterparts
(backdoors)
> spend in the game - something they didn't have until Monday :>.
yes, this is indeed a good product but needs stealthness like the kernel
level backdoors.
> 2. slightly different executables for each customer
sounds promissing, this must be the main motive!
later,
noir
Received on Jul 06 2002
Intro
