Kernel Hooking vs. a sane solution

[Jerry_Schneider]

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?

1. 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”.

2. Microsoft must “back-port” the fixed cm*registerCallback to W2K.

3. 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.

5. 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.

6. 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

[Daniel_Terhell]

Yes, MS is still lightyears away of getting anywhere near getting rid of
allowing us to hook the kernel. I bet it will take just take a couple of
service packs and court settlements before they realize.

Regards,

Daniel Terhell
Resplendence Software Projects Sp
xxxxx@resplendence.com
http://www.resplendence.com

“Jerry Schneider” wrote in message news:xxxxx@ntdev…
> 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?
>
> 1) Microsoft fixes their current implementation of cmregister
> 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”.
>
> 2) Microsoft must “back-port” the fixed cmregisterCallback to W2K.
>
> 3) 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.
>
> 5) 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.
>
> 6) 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
>

[Maxim_S_Shatskih]

> 6) 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

Do not work as Administrator, period. After this - forget about any kernel-mode
security monitoring software. No malware will be injected to the kernel this
way.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

[OSR_Community_User]

> Do not work as Administrator, period. After this - forget

about any kernel-mode
security monitoring software. No malware will be injected to
the kernel this
way.

If only such a world existed. Keep in mind all of the local privilege
escalation problems, both those internal to Microsoft and those exposed by
3rd party products, that a malicious user could use to gain kernel-mode
access. A small sample:

http://osvdb.org/searchdb.php?action=search_title&vuln_title=Windows+privile
ge+escalation&Search=Search

Furthermore, the ability to run code as a non-privileged user can often lead
to the eventual escalation of privileges through more passive tasks, such as
logging key strokes sent to the Run As prompt, for example.

[Maxim_S_Shatskih]

> If only such a world existed. Keep in mind all of the local privilege

escalation problems, both those internal to Microsoft

Very rare. Once per several months or such.

I do not think that polluting the machine with extra software just due to
prevent a problem which occurs once per several months, is properly patched and
is a 2nd chance attack (the attacker must first execute some code as non-admin)
is a good idea.

Also - are you sure that the security software itself will not add a
vulnerability? Why do you think its authors are more trustworthy in terms of
code quality then Microsoft? Remember Kerio firewall which re-created the “ping
of death” bug fixed by Microsoft in around 1997? Or maybe Kerio’s patching
policy is better then MS’s?

Most security problems are solved by:

a) do not work as Administrator (default for many corporate desktops)
b) work from behind a NAT (most DSL routers have this feature) and block some
ill-known ports like RPC, SMB and TFTP. Again a default for many corporate
desktops.
c) run Windows Update frequently. In a company, use SUS.
d) disable HTML mail or use the mailer incapable of it.

No need in resident antivirus at all. Only virus removal tools are used. Run
them from time to time, especially during some next pandemia.

BTW - 88% of virii are caught from email, and 60% of email is spam (source:
Kaspersky Lab).

and those exposed by
3rd party products,

3rd party products must NEVER escalate privileges, and must be designed in a
way it is theoretically impossible. For instance, the database server must be
runnable as non-admin user (and I think that the real database servers are
really such).

logging key strokes sent to the Run As prompt, for example.

Do not use Run As convinient but not secure.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

[Tim_Roberts]

Maxim S. Shatskih wrote:

Most security problems are solved by:

a) do not work as Administrator (default for many corporate desktops)
b) work from behind a NAT (most DSL routers have this feature) and block some
ill-known ports like RPC, SMB and TFTP. Again a default for many corporate
desktops.
c) run Windows Update frequently. In a company, use SUS.
d) disable HTML mail or use the mailer incapable of it.

All of that is good advice except for d). You can’t hide your head in
the sand. HTML e-mail is here to stay, and no corporate IT department
would ever seriously think of eliminating it.

However, if you modify that to “disable active content in HTML mail”,
I’ll sign on for the whole list.

–

• Tim Roberts, xxxxx@probo.com
  Providenza & Boekelheide, Inc.

[OSR_Community_User]

Maxim S. Shatskih wrote:

>logging key strokes sent to the Run As prompt, for example.

Do not use Run As convinient but not secure.

Ahh, yes. The proper result of the run as command would have
been:

“Please press CTRL+ALT+DELETE to run %1 as another user.”

The same is true of the file sharing authentication dialogs:

“Please press CTRL+ALT+DELETE to enter your password for
\server\share”

That is what the Secure Attention Sequence was intended for!

So that when the user pressed it, he knew he was talking to
the OS and not some hacker. Like many secure intentions though,
it was sacrificed on the altar of user convenience and backwards
compatibility.

Thanks,

Joseph

[Maxim_S_Shatskih]

> That is what the Secure Attention Sequence was intended for!

Use Fast User Switching instead of Run As

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

[OSR_Community_User]

Maxim S. Shatskih wrote:

>That is what the Secure Attention Sequence was intended for!

Use Fast User Switching instead of Run As

Excellent. Too bad it doesn’t work with domains

Thanks,

Joseph

[OSR_Community_User]

> Very rare. Once per several months or such.

I do not think that polluting the machine with extra software
just due to
prevent a problem which occurs once per several months, is
properly patched and
is a 2nd chance attack (the attacker must first execute some
code as non-admin)
is a good idea.

Once again, if only such a world existed. You are assuming the best case
scenario where every user in the world is smart, has automatic updates
enabled, has anti-virus and anti-spyware filtering at their ISP, and that
they do not run questionable software on their computers. This is not the
real world. Even if this world existed, it would not be enough.

Also - are you sure that the security software itself will not add a
vulnerability? Why do you think its authors are more
trustworthy in terms of
code quality then Microsoft? Remember Kerio firewall which
re-created the “ping
of death” bug fixed by Microsoft in around 1997? Or maybe
Kerio’s patching
policy is better then MS’s?

No, I’m certainly not saying that security software does not also
potentially expose vulnerabilities. There are plenty of examples where
security software, especially virus scanners, can lead to privilege
escalation through kernel level vulnerabilities or other coding mistakes.
The URL I posted previously even includes one of them in the list (symantec
live update).

Most security problems are solved by:

a) do not work as Administrator (default for many corporate desktops)
b) work from behind a NAT (most DSL routers have this
feature) and block some
ill-known ports like RPC, SMB and TFTP. Again a default for
many corporate
desktops.
c) run Windows Update frequently. In a company, use SUS.
d) disable HTML mail or use the mailer incapable of it.

No need in resident antivirus at all. Only virus removal
tools are used. Run
them from time to time, especially during some next pandemia.

BTW - 88% of virii are caught from email, and 60% of email is
spam (source:
Kaspersky Lab).

I think this view is far too limited. You need to consider other attack
vectors such as passive and aggressive software vulnerabilities. Recall for
a moment all of the remotely accessible privileged vulnerabilities (DCOM,
LSASS, etc) that have plagued users. You also need to account for the 20%
of the viruses that, according to Kaspersky, are not caught by virus filters
at ISPs.

Sure, you could set up a firewall and keep lining your defenses, but the
fact of the matter is that this is a response based approach that does not
scale to the real world.

>and those exposed by
> 3rd party products,

3rd party products must NEVER escalate privileges, and must
be designed in a
way it is theoretically impossible. For instance, the
database server must be
runnable as non-admin user (and I think that the real
database servers are
really such).

I’m not really sure how to respond to this. Are you saying that there is
never a case where a company would have a viable reason to write software
that runs software as an administrative user? I know that you aren’t, and
that’s why I’m confused as to why you would propose something of this sort.
It’s definitely true that applications can be designed such that they never
need to escalate privileges from a non-privileged user to a privileged user.
The way that this can be, and is commonly, accomplised is by creating a
layer of separation between privilege levels (such as is the case with a
restricted user application communicating with an administrative service).
This, however, does not preclude applications from being vulnerable to
privilege escalation attacks through vulnerabilities that are exposed in the
layer of separation between the restricted user and the administrative
service. This is just one example, there are others.

So, to summarize, your view is analagous to the opinion that it’s safe to
live in a house with unlocked doors just because you have a wall that is
taller than you think anyone can scale. That’s fine and dandy…up until
the point that a new technique is found to scale super tall walls. Oh…and
don’t forget that this assumes that the technique is released publically,
for if it isn’t public knowledge, you’ll be sitting there the whole time
thinking you’re safe, when in actuality there’s a gremlin hiding in your ice
box.

[Jerry_Schneider]

Maxim S. Shatskih wrote:

> 6) 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

Do not work as Administrator, period. After this - forget about any kernel-mode
security monitoring software. No malware will be injected to the kernel this
way.

Interesting advice, especially since Microsoft has written extensively
about why they DEFALUT users on non-domain-based XP systems to run
with Administrative privilege (Two words: user experience"). Yes,
they say that unfortunately most home and small business users would
it too limiting to run with default user account privileges.

Do you believe users of the ~100 million compromised home computers
would have the ability to install their Windows systems to run under
the user account. I’m sure most would trade their bots, cloaked
proxies, keystroke loggers and DDS engines for some inconvenience,
but they would also bitch that most of their older programs and
games don’t run under user accounts, and that they would tire of
continually typing in an Admin password at every requirement for
elevated privileges.

Finally, let’s suppose they all are forced to run under non-admin
accounts. Are you really so sure that I couldn’t infest such a
machine with the gamut of bots and trojans, including some
kernel-resident types? A quick scan of the hacker websites show
an incredible number of ways to exploit still-unpatched and poorly-
designed Windows systems.

I agree with your advice for a corporate setting, since non-Admin
is defacto. Even if there are no compromised corporate systems,
consider the consequences to a corporation when a bunch of the
100 million home systems run a DDS attack on the company’s website
until they pay some foreign mafia a weekly “fee” to stop.

Those systems are the main reason I develop after-market tools
to clean up after the Admin-privileged users unknowingly rake in
the malware. It’s easy to suggest that because everyone on your
block has a new car, everyone else in the world should do likewise.
But life is as it is, not as we want it to be.

Best regards
Jerry Schneider

[OSR_Community_User]

Matt Miller wrote:

>Very rare. Once per several months or such.
>
>I do not think that polluting the machine with extra software
>just due to
>prevent a problem which occurs once per several months, is
>properly patched and
>is a 2nd chance attack (the attacker must first execute some
>code as non-admin)
>is a good idea.
>
>

Once again, if only such a world existed. You are assuming the best case
scenario where every user in the world is smart, has automatic updates
enabled, has anti-virus and anti-spyware filtering at their ISP, and that
they do not run questionable software on their computers. This is not the
real world. Even if this world existed, it would not be enough.

>Also - are you sure that the security software itself will not add a
>vulnerability? Why do you think its authors are more
>trustworthy in terms of
>code quality then Microsoft? Remember Kerio firewall which
>re-created the “ping
>of death” bug fixed by Microsoft in around 1997? Or maybe
>Kerio’s patching
>policy is better then MS’s?
>
>

No, I’m certainly not saying that security software does not also
potentially expose vulnerabilities. There are plenty of examples where
security software, especially virus scanners, can lead to privilege
escalation through kernel level vulnerabilities or other coding mistakes.
The URL I posted previously even includes one of them in the list (symantec
live update).

>Most security problems are solved by:
>
>a) do not work as Administrator (default for many corporate desktops)
>b) work from behind a NAT (most DSL routers have this
>feature) and block some
>ill-known ports like RPC, SMB and TFTP. Again a default for
>many corporate
>desktops.
>c) run Windows Update frequently. In a company, use SUS.
>d) disable HTML mail or use the mailer incapable of it.
>
>No need in resident antivirus at all. Only virus removal
>tools are used. Run
>them from time to time, especially during some next pandemia.
>
>BTW - 88% of virii are caught from email, and 60% of email is
>spam (source:
>Kaspersky Lab).
>
>

I think this view is far too limited. You need to consider other attack
vectors such as passive and aggressive software vulnerabilities. Recall for
a moment all of the remotely accessible privileged vulnerabilities (DCOM,
LSASS, etc) that have plagued users. You also need to account for the 20%
of the viruses that, according to Kaspersky, are not caught by virus filters
at ISPs.

Sure, you could set up a firewall and keep lining your defenses, but the
fact of the matter is that this is a response based approach that does not
scale to the real world.

>>and those exposed by
>>3rd party products,
>>
>>
>3rd party products must NEVER escalate privileges, and must
>be designed in a
>way it is theoretically impossible. For instance, the
>database server must be
>runnable as non-admin user (and I think that the real
>database servers are
>really such).
>
>

I’m not really sure how to respond to this. Are you saying that there is
never a case where a company would have a viable reason to write software
that runs software as an administrative user? I know that you aren’t, and
that’s why I’m confused as to why you would propose something of this sort.
It’s definitely true that applications can be designed such that they never
need to escalate privileges from a non-privileged user to a privileged user.
The way that this can be, and is commonly, accomplised is by creating a
layer of separation between privilege levels (such as is the case with a
restricted user application communicating with an administrative service).
This, however, does not preclude applications from being vulnerable to
privilege escalation attacks through vulnerabilities that are exposed in the
layer of separation between the restricted user and the administrative
service. This is just one example, there are others.

So, to summarize, your view is analagous to the opinion that it’s safe to
live in a house with unlocked doors just because you have a wall that is
taller than you think anyone can scale. That’s fine and dandy…up until
the point that a new technique is found to scale super tall walls. Oh…and
don’t forget that this assumes that the technique is released publically,
for if it isn’t public knowledge, you’ll be sitting there the whole time
thinking you’re safe, when in actuality there’s a gremlin hiding in your ice
box.

---

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@gmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Maxim,

Commercial security products are usually developed with two pressuring
factors behind them :

* Be as smart as possible when detecting attacks i.e “Whatever you
try to detect, detect it thinking the most briliant hackers”
* Be as simple as possible i.e “Whatever you do, do it for your mom”

The most of the computer users are the people who even do not know which
account and priviledge they are using. They use Microsoft Word for
writing things, they surf the Internet with Internet Explorer and they
use MSN, KAZAA etc.
You can not always expect them to run regular updates, switch accounts,
disable scripting etc. And even with those practises applied, there
always exist a probabiliy of defacement.

Even in enterprise networks, enforcement of advanced security policies
fails for a number of reasons. e.g seperation of duties is a really
difficult task.

Security products claiming to be providing a complete host based
security have to watch every operation to dynamically decide if
something is suspicious. This watching is not just limited to network
traffic but IPC traffic, registry traffic, file traffic etc. Since
currently available Windows versions do not have a supported
infrastructure for developing the every type of those watching
requirements, we sometimes need to hook into kernel.

But this time poor programming practices in these products cause
problems. ZoneAlarm, for example has a bug such that it does not
validate memory it accesses at the user space while hooking
ZwConnectPort native api thus it cause BSOD when facing malformed requests.

This is a race between the Security and availability forming the base
problem of security theory.

Whatever we do, we will always face those problems. We can only mitigate
the risks.
If Microsoft does not decide to analyze security requirements caused by
brillint hackers and required by moms, and provide us a good framework,
we will always have to hook into kernel. We will always try to reference
undocumented ways.

Hopefully, Longhorn is coming wit some enhancements for security
software developers.

Egemen Tas

[Maxim_S_Shatskih]

> This is a race between the Security and availability forming the base

problem of security theory.

Living with such software installed is like living in a house with rat-traps in
all corners, rooms and passages, which are installed under the slogan “rats are
evil”. Sometimes yes, you will find a dead rat or two in them. But sometimes
you will hit it accidentally by your toe, and get your toe trapped there

This is not a race between security and availability. You noticed ZoneAlarm
which sometimes reduces the security (by introducing new attack vectors, which
are nearly 100% deadly unless a patch from ZoneLabs will be installed) instead
of increasing it. This is just plain reducing the security, like
overconsumption of a medicine is poisonous. Availability is, strictly speaking,
another song a bit.

I saw people with 2 resident antivirus products installed (Symantec and
Kaspersky) and ZoneAlarm, which had infected computers. Nothing will help but
user education. Amazing but true.

This is like the usual medical epydemiology. Children must be vaccinated, and
the hygiene must be adequate. This alone reduces the rate of major contagious
diseases a lot.

Nobody will feed his/her child with, say, streptomycine to support his/her
health - people go on with vaccination and hygiene. Well, this is probably
unpleasant for streptomycine producers :), but nevertheless.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

[Prokash_Sinha-1]

ONLY IF WE KNOW, ONLY IF WE KNOW…

This whole discussion is idological crap. The history of science technology
and everything else is flawful. You see after all the efforts Space shuttle
crashed, should we just say plane wrong idea ( well prove otherwise, comeup
with better idea :).

Hooking might be insane, unless there are some well documented proven
examples, then whatever is done noone wants to roleback. Only way to solve
these is to comeup with an idea that clearly shows folks you dont need any
of the *mycins.

I can argue for 10 thousand years “why the hell we need computers”.
Civilization is zillion years old. And use of computer is not even 100 yrs.

Once upon a time there was a real need for DOS, I mean real, otherwise we
would have been around glass house for forever. Now these security products
are need, well at least most of the people think that way. Once someone
comeup with the magic mantra, then people would start believing it, and
those products would not be necessary.

Until then we are with what we have !!!

----- Original Message -----
From: “Maxim S. Shatskih”
To: “Windows System Software Devs Interest List”
Sent: Thursday, March 24, 2005 10:57 AM
Subject: Re: [ntdev] Kernel Hooking vs. a sane solution

>> This is a race between the Security and availability forming the base
>> problem of security theory.
>
> Living with such software installed is like living in a house with
> rat-traps in
> all corners, rooms and passages, which are installed under the slogan
> “rats are
> evil”. Sometimes yes, you will find a dead rat or two in them. But
> sometimes
> you will hit it accidentally by your toe, and get your toe trapped there
>
>
> This is not a race between security and availability. You noticed
> ZoneAlarm
> which sometimes reduces the security (by introducing new attack vectors,
> which
> are nearly 100% deadly unless a patch from ZoneLabs will be installed)
> instead
> of increasing it. This is just plain reducing the security, like
> overconsumption of a medicine is poisonous. Availability is, strictly
> speaking,
> another song a bit.
>
> I saw people with 2 resident antivirus products installed (Symantec and
> Kaspersky) and ZoneAlarm, which had infected computers. Nothing will help
> but
> user education. Amazing but true.
>
> This is like the usual medical epydemiology. Children must be vaccinated,
> and
> the hygiene must be adequate. This alone reduces the rate of major
> contagious
> diseases a lot.
>
> Nobody will feed his/her child with, say, streptomycine to support his/her
> health - people go on with vaccination and hygiene. Well, this is probably
> unpleasant for streptomycine producers :), but nevertheless.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

[Lyndon_J_Clarke-2]

Hey Jerry

The Cm callbacks are complete and utter useless on W2K3 GOLD as has been
discussed here before since system crashes are inevitable; search for posts
from Douglas Hanley for considerable detail. Microsoft told us this has been
fixed in W2K3 SP1 (but not WXP SP2) and the specific error reported by
Douglas Hanley does seem to have been fixed in W2K3 SP1 RC2; but our lab
tests so far indicate there appear to be further crash causing troubles with
the Cm callbacks on SP1 RC2.

Cheers
Lyndon

“Jerry Schneider” wrote in message news:xxxxx@ntdev…
> 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?
>
> 1) Microsoft fixes their current implementation of cmregister
> 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”.
>
> 2) Microsoft must “back-port” the fixed cmregisterCallback to W2K.
>
> 3) 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.
>
> 5) 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.
>
> 6) 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
>

[Jerry_Schneider]

Lyndon J Clarke wrote:

The Cm callbacks are complete and utter useless on W2K3 GOLD as has been
discussed here before since system crashes are inevitable; search for posts
from Douglas Hanley for considerable detail. Microsoft told us this has been
fixed in W2K3 SP1 (but not WXP SP2) and the specific error reported by
Douglas Hanley does seem to have been fixed in W2K3 SP1 RC2; but our lab
tests so far indicate there appear to be further crash causing troubles with
the Cm callbacks on SP1 RC2.

Lyndon,

Many thanks for the pointer to this. I am in the process of backporting
a “compatible” version of cm*registercallback to win2k, thinking that at
least I don’t have to write it also for winXP or w23k. Darn, looks like
I’ll have to cover everything up to Longhorde.

To add to the problems, I just found several posts saying that trying to
see dynamically if I can link to the kernel’s cm*callback stuff for XP/W2k3
causes a lockup in MmGetSystemRoutineAddress() when the first two letters
of the routine name begin with “cm”. If this turns out to be true, then
I can’t reliably make the run-time decision to use the Microsoft-supplied
“solution”, meaning I’m back to hooking the kernel’s registry service calls
for all released OSes.

Too bad the “pain” from these failures of implementation fall on a few
developers and not upon the upper management at Microsoft. If it affected
their stock price, I’ll bet we would have a fix tomorrow!

Best regards
Jerry Schneider

[Lyndon_J_Clarke-2]

Jerry

very interesting … can you offer a pointer to the possts you refer to
which meantion “… cm*callback stuff for XP/W2k3
causes a lockup in MmGetSystemRoutineAddress …”?

Thanks
Lyndon

“Jerry Schneider” wrote in message news:xxxxx@ntdev…
> Lyndon J Clarke wrote:
>> The Cm callbacks are complete and utter useless on W2K3 GOLD as has been
>> discussed here before since system crashes are inevitable; search for
>> posts from Douglas Hanley for considerable detail. Microsoft told us this
>> has been fixed in W2K3 SP1 (but not WXP SP2) and the specific error
>> reported by Douglas Hanley does seem to have been fixed in W2K3 SP1 RC2;
>> but our lab tests so far indicate there appear to be further crash
>> causing troubles with the Cm callbacks on SP1 RC2.
>
> Lyndon,
>
> Many thanks for the pointer to this. I am in the process of backporting
> a “compatible” version of cmregistercallback to win2k, thinking that at
> least I don’t have to write it also for winXP or w23k. Darn, looks like
> I’ll have to cover everything up to Longhorde.
>
> To add to the problems, I just found several posts saying that trying to
> see dynamically if I can link to the kernel’s cmcallback stuff for
> XP/W2k3
> causes a lockup in MmGetSystemRoutineAddress() when the first two letters
> of the routine name begin with “cm”. If this turns out to be true, then
> I can’t reliably make the run-time decision to use the Microsoft-supplied
> “solution”, meaning I’m back to hooking the kernel’s registry service
> calls
> for all released OSes.
>
> Too bad the “pain” from these failures of implementation fall on a few
> developers and not upon the upper management at Microsoft. If it affected
> their stock price, I’ll bet we would have a fix tomorrow!
>
>
> Best regards
> Jerry Schneider
>

[Lyndon_J_Clarke-2]

Okay Jerry I found the post(s?) to which you refer, and thanks for the
mention. I see no extra problem here for me or you … just check the o/s
version before attempting to call MmGetSystemRoutineAddress() for the Cm*
routines?

Cheers
Lyndon

“Jerry Schneider” wrote in message news:xxxxx@ntdev…
> Lyndon J Clarke wrote:
>> The Cm callbacks are complete and utter useless on W2K3 GOLD as has been
>> discussed here before since system crashes are inevitable; search for
>> posts from Douglas Hanley for considerable detail. Microsoft told us this
>> has been fixed in W2K3 SP1 (but not WXP SP2) and the specific error
>> reported by Douglas Hanley does seem to have been fixed in W2K3 SP1 RC2;
>> but our lab tests so far indicate there appear to be further crash
>> causing troubles with the Cm callbacks on SP1 RC2.
>
> Lyndon,
>
> Many thanks for the pointer to this. I am in the process of backporting
> a “compatible” version of cmregistercallback to win2k, thinking that at
> least I don’t have to write it also for winXP or w23k. Darn, looks like
> I’ll have to cover everything up to Longhorde.
>
> To add to the problems, I just found several posts saying that trying to
> see dynamically if I can link to the kernel’s cmcallback stuff for
> XP/W2k3
> causes a lockup in MmGetSystemRoutineAddress() when the first two letters
> of the routine name begin with “cm”. If this turns out to be true, then
> I can’t reliably make the run-time decision to use the Microsoft-supplied
> “solution”, meaning I’m back to hooking the kernel’s registry service
> calls
> for all released OSes.
>
> Too bad the “pain” from these failures of implementation fall on a few
> developers and not upon the upper management at Microsoft. If it affected
> their stock price, I’ll bet we would have a fix tomorrow!
>
>
> Best regards
> Jerry Schneider
>