Re: Re:Why hooking is bad

Comments inline:
“Oliver Schneider” wrote in message
news:xxxxx@ntfsd…
> Don,
>
> The world is not black and white :wink:
>
>> 1. First once you hook you can never unhook. The
>> problem is that you have
>> to assume someone may have come along after you and
>> hooked, if you unhook
>> and unload they will still call you, and their goes
>> the system.
> You can have a jumptable located in nonpaged pool or simply as an exported
> symbol of a KM DLL (of course loaded as a dependency to the driver
> establishing the hook so the DLL will never get unloaded ;-). There is no
> one preventing you from these measures.

None of these approaches are truly reliable, and can crash the system. Walk
through any of these on a multi-processor system and there are scenarios
that break.

>> 2. Second, you have no control over hooking order,
>> so lets say you and
>> another driver start hooking at the same time, you
>> hook five calls and the
>> other driver hooks the same five calls. Well since
>> there is no control,
>> some of the calls will invoke your hook, then the
>> other drivers, and the
>> other calls will invoke the other drivers then your
>> hook.
> This is an argument, if the hook author did not care for #1. However,
> consider filter drivers: these have to behave transparently to anyone
> below
> or above them in the driver stack (depending on their position), so why
> shouldn’t this be possible when hooking functions. The only important
> thing
> is that the actual hooking needs to take place atomically (which is
> definitely no problem with IA32).
> All the rest of the functions must not rely on their position in the
> hook
> chain.

No, firlter drivers live at a single point in the I/O stack. Unfortunately,
hooking creates situations where a pair of functions such as Create/Close
are mismatched. For example the worst I’ve seen was driver A got Create
first, but driver B got Close first. Unfortunately in this case, A blocked
additional opens until it saw a close, but one of those opens was part of a
sequence that allowed B to continue with the close.

>> 3. Third, are you using stack in your hook? How
>> can you tell if you are
>> using too much? It is possible to do without much
>> stack, or leaving any on
>> the stack, but most people are too lazy to do this.
> How can you tell this for anything else? Every stack has “only” 12kB (GUI:
> ~64) - so what? The same applies not only to hooks.

Yes, this applies to everything, but there are paths in the kernel that are
close, hooking doesn’t follow the planned rules, so you are potentially
hitting more. Remember you are doing something that is not approved, and is
not tested. There is no plugfest for hooking drivers!

>> 4. Fourth, the native system calls are undocumented
>> and can change. The
>> common case on this is the changing of the call
>> numbers, but Windows has
>> also added options, changed the parameters and even
>> replaced the call with a
>> newer one. Basically, most hooking drivers lock
>> themselves into a small set
>> of OS versions, but never bother to check if this is
>> correct.
> What if they check?

Hod do you check against a hotfix that changes things? What do you do when
you check and see a version that is not known? Do you disable your driver,
or do you blindly figure “the odds are good things will work”?

>> 5. Five, Microsoft has blocked system call hooking
>> on AMD64. I request
>> that they offer the same capability under X86. I
> How would you do this (on X86)?
>
> Despite that drivers are members of the TCB - “T” being for “Trusted”. So
> if
> you don’t trust a trusted entity you are obviously in trouble. Seems like
> a
> dilemma, no? :wink:

By your philosophy, we need no memory protection in the kernel, just make
all pages read/write and let things scribble where they desire. Even a
“trusted environment” has controls, all the Microsoft did with 64-bit is add
some additional controls including protecting the system call table. I
would like to see these controls be enablable by a boot option for 32-bit.

>> 6. Six, a number of companies are running rootkit
>> detectors, and rejecting
>> software that does hooking. So basically you are
>> using a technique that can
>> get your company thrown out of firms permanently.
> That is definitely an argument that hurts most, so this should have been
> the
> first one I guess.
>
No, this is just nailing people in business, hooking can and does crash
peoples machines.

I agree there are times that hooking is the only way to make things work,
but that is a small percentage of the hooking drivers. Most of this is done
by people who are too lazy to think about this stuff and do it right, or who
believe in scenarios that are ridiculous such as “I can’t use the kernel
callbacks, because the process starts running before I see the image load”,
of course they ignore the fact that until the image load the code they are
concerned with is not present and the callback occurs before control passes
back to the process.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply