Re: How will PatchGuard change kernel programming?
- From: "Don Burn" <burn@xxxxxxxxxxxxxxxx>
- Date: Sun, 15 Oct 2006 10:03:28 -0400
Comments inline:
"David J. Craig" <Dave@xxxxxxxxxxxxx> wrote in message
news:uZJAMp$7GHA.4572@xxxxxxxxxxxxxxxxxxxxxxx
I don't agree that McAfee has been avoiding or even inhibiting Microsoft
from producing APIs to permit better addon security products. There is a
much improved registry monitoring interface. There is also a much
improved file system filter stack via the minifilter model that solves a
lot of problems that gave so many people using old source code versions of
filemon so many problems.
Actually, I and others at some conferences have asked for additional kernel
API's that would have helped security checking. In some cases I got
reports back that the big two did fight against this with claims that
Microsoft was helping their competitors.
Some of the problem with security companies is that Microsoft has become
a competitor. How can they ask for something without giving away their
trade secrets to a competitor?
How is saying something like, we want an extension to the PsLoadImageNotify
routine to all termination of a process that is running a non-trusted file
letting out their secrets. The items the kernel should be extended for are
things that appear in a lot of papers (including marketing blurbs from the
big two!).
It is ironic that the big two are waving the flag of protect the little
guy. For instance, try running a kernel debugger on a system with their AV
product. Depending on the version you will either get no AV (with no
warning it is disabled) or the system will crash (at least once I corrupted
a disk due to this approach). These guys do this to "protect their IP", of
course it makes it real fun to find out that the reason your file system is
crashing is that they assumed things about the file system interface that
aren't true. My favorite was a version of a product that knew if your file
system had multiple streams it was NTFS, and would make assumptions on
legal calls, and buffering methods based on the presence of a stream!
It is ironic that PatchGuard has been around for over 2 years and now
finally the big two are complaining. This stuff was announce in 2004,
where were they then? I do know I had a conversation with a firm that
would not identify themselves on PatchGuard, I suggested ways their product
could be made to work without hooking, and the response was "Are you
kidding, that kind of development cost would hurt our profits".
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
.
- Follow-Ups:
- Re: How will PatchGuard change kernel programming?
- From: David J. Craig
- Re: How will PatchGuard change kernel programming?
- References:
- How will PatchGuard change kernel programming?
- From: smerf
- Re: How will PatchGuard change kernel programming?
- From: Don Burn
- Re: How will PatchGuard change kernel programming?
- From: David J. Craig
- Re: How will PatchGuard change kernel programming?
- From: Don Burn
- Re: How will PatchGuard change kernel programming?
- From: David J. Craig
- Re: How will PatchGuard change kernel programming?
- From: Don Burn
- Re: How will PatchGuard change kernel programming?
- From: David J. Craig
- How will PatchGuard change kernel programming?
- Prev by Date: Kernel address questions
- Next by Date: SetWindowLong latency
- Previous by thread: Re: How will PatchGuard change kernel programming?
- Next by thread: Re: How will PatchGuard change kernel programming?
- Index(es):
Relevant Pages
|