Don,
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.
It can always break if someone does not follow something like “common-sense
rules” - sadly there is at most a common sense, but no other rules how a
hooking driver should behave, just because MS does not want to endorse it.
Yet you can find quite some AV drivers hooking functions such as
NtCreateProcess() (and even more).
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.
Just don’t rely on sequences. This is what I said. It is *your*
responsibility to not break anything when hooking. I recently found one
driver which BSODed the system because it couldn’t handle invalid parameters
passed down into one of the hooked routines. This is certainly a problem of
the respective company.
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!
I would say: “it depends!” - perhaps you are right for drivers targeted at
production environments. However, you can hardly tell from questions asked
on this list whether the problem occurs only in a product used internally in
a company (say, to trace malware) or whether they want to ship it. And even
if *they* want to ship it it is not *your* problem
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”?
Good behavior would be to disable the driver, so I’d do that and perhaps
notify the user of it. Depends on the job I am supposed to do in my driver.
By your philosophy, we need no memory protection in the kernel, just
make all pages read/write and let things scribble where they desire.
It’s not a philosophy, it is just a raw fact. There are no ifs and buts in
that. If you don’t trust someone you are actually supposed to trsut then you
are in a dilemma.
It’s the same for software protections: if you don’t trust the user don’t
give him the key to run your program - if you give him the key to run it
don’t complain that you don’t trust him.
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.
… which would certainly break a lot of existing programs.
Let me cite MS: “For x86-based systems, Microsoft discourages such practices
but does not prevent them programmatically, because doing so would break
compatibility for a significant amount of released software.”
[http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx]
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.
It has been discussed (I do not remember when exactly, but at least 1 year
back) on this very list how to use process creation notification routines
(not image load notification) to “prevent” processes from running.
As I said, it always depends on what you want to achieve and in which
environment it will run. Certainly I do not care if the VM of one of our
researchers crashes from time to time, I’d just figure it out and correct
it.
But you are right, of course, that usually one should not resort to this
type of “hackery”, especially when shipping serious products.
Have a nice weekend,
Oliver
(no cool titles here, yet … 
–
May the source be with you, stranger
ICQ: #281645
URL: http://assarbad.net