-----Mensaje original-----
De: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]En nombre de Jerry Schneider
Enviado el: mi?rcoles, 23 de marzo de 2005 19:25
Para: Windows System Software Devs Interest List
Asunto: [ntdev] Kernel Hooking vs. a sane solution
Peter Viscarola (OSR) wrote:
> Back to singing my same old song:
>
> You DO realize that much of this goofy hacking the kernel stuff is actively
> prevented on 64-bit Windows systems, right?
From http://www.microsoft.com/whdc/driver/kernel/64bitpatching.mspx:
“Microsoft? Windows? Server 2003 SP1 and later versions of Windows
for x64-based systems do not allow the kernel to be patched except
through authorized Microsoft-originated hot patches.”
It would seem to me that Microsoft’s policy, whether inspired by
arrogance or by real technical necessity, just raises the battle
to the next level; how soon can reverse-engineering figure out how
to circumvent these impediments.
“If your driver must perform a task that you feel cannot be
accomplished without patching the kernel, contact Microsoft
Product Support Services or your Microsoft representative.”
As I have “sung” many times, Microsoft could eliminated most, if
not all need by legitimate drivers to “hook the kernel”, if they
realized the reason most hooks were needed. Can anyone tell me
why the following “solution” would not mitigate their need to hook?
- Microsoft fixes their current implementation of cm*register
Callback so that at least security drivers for anti-virus
and anti-spyware tools to be assured of seeing ALL events!
As currently implemented, the first driver to register for a
callback can “terminate” the event without subsequent callback
holders ever seeing the event. Duh, so why allow more than
one registered callback? I would like to see a method for
(signed?) security drivers to be GUARANTEED to see all callback
events and to be able to prevent an event, while allowing any
other callbacks to see the event but not veto a “prevent”.
-
Microsoft must “back-port” the fixed cm*registerCallback to W2K.
-
Microsoft must implement and backport a similar (Un)register-
Callback mechanism for obtaining “pre” and “post” callbacks for
process and thread creation, deletion, suspend, open, write,
imageload and debug. Again, there must be a mechanism for a
third-party security driver to be guaranteed to see all events
and to have veto-proof control over the completion of the event.
Additionally, there is a need for *(un)registerCallback for
additional events, including read/write/protect virtual memory,
the setting and removal of global and local windows hooks, to
watch for and have control over specified windows messages,
open/read/write of physical memory, to monitor OpenSection,
CreateSymbolicLink, SetSystemInformation, RequestWaitReplyPort,
SetPort, SetQuota, and probably a dozen more. The callback
for these must allow “pre-execution” event control and must be
able to identify the process and thread originating the rqst,
as well as the target process and thread.
-
The need for security tools to monitor things like the network
stack, LSPs, email and http (including the ability to see what
other apps have also intercepted this data) is growing. While
there are new callback-style supported hooks into the network
stack, unless there is a backport to Win2k, kernel hooking will
persist. Likewise, a standard filesystem “filter driver” that
all anti-malware tools could use would prevent many poorly-
written filter drivers from reducing perceived OS quality. -
Finally, it must be realized and accepted that malware authors
continue to find new ways to inject their poison into both the
user-mode and kernel environment. A method to quickly add or
modify, upon showing a specific need, a kernel service hook is
absolutely necessary to prevent a reversion to hooking by the
security tools provide first-response prevention.
I’m sure that other security-related companies could help refine
this requirement, but unless Microsoft can implement it across both
existing OS/platforms and upcoming OS/platforms, the hooking and
resulting loss of OS quality control will continue. Without this,
it’s only a matter of time until the upcoming “patch prevention”
code is circumvented and hooking continues in an even-more hacked
manner.
Best regards
Jerry Schneider
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@pandasoftware.es
To unsubscribe send a blank email to xxxxx@lists.osr.com