Understanding Microsoft's Stance on Hooking (was re: Hooksys example... )

NTFSD
1

You know I am probably going to get in trouble for this one, but I would love for someone from Microsoft to talk about WHY they are so against hooking. I’m curious.

I can see ample reasons for hooking ranging from wanting to hook a system call or two to suppress its functionality (ie: Preventing the setting of seDebugPrivileges) to backwards compatibility requirements against earlier versions of the OS (ie: the diff for registry hooking vs. the registry callback API available since XP… why manage two entirely different code bases for the same functionality)

I understand the risks, and the issues that Don pointed out that arise from hooks above or below or pointing to the wrong places against the syscall table. What I am curious is to the reason so much effort is being put into preventing it. What threats are trying to be mitigated here, especially when weighed against the possible usefulness of the technique?

James Antognini [MSFT] wrote:

Let me emphasize what Don said: Hooking is not a good idea in the general
case. If you’re doing it to investigate something in your lab, feel free.
But avoid hooking in product code or even in code you distribute widely.

–
Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]

2

One thing i know is that many rootkit drivers use these hooking techniques
to hide themselves. Hooking is one of the most used technique by stealth
malware. Other than that, hooks on top of each other can cause problems (as
pointed by Don). Thirdly hooks are not a documented way of doing things. It
directly manipulate the data structures of the OS and you never know when
you do that in unsafe manner. Like the code in hooksys, which is not
multi-processor safe. I think Microsoft wants to give well defined ways to
do certain important things but they don’t want to expose the secrets of the
OS which can then be exploited by hackers.

Example is, if Microsoft made hooking documented, then there will be 100s of
legal drivers using it and then Microsoft is morally (i don’t know if
legally) bound to maintain and support that interface. This way the stealth
malware will be supported on every new windows version coming. I bet you
don’t want that, right?

–
Pankaj Garg
This posting is provided “AS IS” with no warranties and confers no rights.

“Dana Epp” wrote in message news:xxxxx@ntfsd…
> You know I am probably going to get in trouble for this one, but I would
love for someone from Microsoft to talk about WHY they are so against
hooking. I’m curious.
>
> I can see ample reasons for hooking ranging from wanting to hook a system
call or two to suppress its functionality (ie: Preventing the setting of
seDebugPrivileges) to backwards compatibility requirements against earlier
versions of the OS (ie: the diff for registry hooking vs. the registry
callback API available since XP… why manage two entirely different code
bases for the same functionality)
>
> I understand the risks, and the issues that Don pointed out that arise
from hooks above or below or pointing to the wrong places against the
syscall table. What I am curious is to the reason so much effort is being
put into preventing it. What threats are trying to be mitigated here,
especially when weighed against the possible usefulness of the technique?
>
>
> James Antognini [MSFT] wrote:
>
> > Let me emphasize what Don said: Hooking is not a good idea in the
general
> > case. If you’re doing it to investigate something in your lab, feel
free.
> > But avoid hooking in product code or even in code you distribute widely.
> >
>
>
> –
> Regards,
> Dana Epp
> [Blog: http://silverstr.ufies.org/blog/]
>
>

3

Hey Pankaj,

Thanks for voicing your views. It’s interesting in the fact that there is a belief that by simply not documenting the interfaces that we can reduce the risk against malware that uses it. Greg Hoglund has many examples of using hooking for rootkits, so I fully understand what you are getting at here. The reality is that an adversary can still gain access and do this, with or without Microsoft’s help. At least for now.

I am exploring the rational around the decisions, as well as seeing where the PERCEIVED risks are. I really want to understand what benefits vs. drawbacks there are for eliminating hooking that could have real commercial potential. There are times and situations where I can see hooking being useful without being malicious. Of course anyone with hostile intent can use the same vector to cause harm.

Do I want stealth apps to run with exposed API interface? Of course not. On the other hand, who says hooking cannot be made to allow functional extensions to the system in a safe manner?

Pankaj Garg wrote:

One thing i know is that many rootkit drivers use these hooking techniques
to hide themselves. Hooking is one of the most used technique by stealth
malware. Other than that, hooks on top of each other can cause problems (as
pointed by Don). Thirdly hooks are not a documented way of doing things. It
directly manipulate the data structures of the OS and you never know when
you do that in unsafe manner. Like the code in hooksys, which is not
multi-processor safe. I think Microsoft wants to give well defined ways to
do certain important things but they don’t want to expose the secrets of the
OS which can then be exploited by hackers.

Example is, if Microsoft made hooking documented, then there will be 100s of
legal drivers using it and then Microsoft is morally (i don’t know if
legally) bound to maintain and support that interface. This way the stealth
malware will be supported on every new windows version coming. I bet you
don’t want that, right?

–
Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]

4

Well I guess my question would be what hooking do you need that isn’t
provided by another mechanism? Microsoft has added callback support for
registry calls so that RegMon didn’t need the kludge hook. I/O is better
handled by filter drivers, than by one massive hook. Process/thread
creation and termination have callbacks, as does executable image load. I
know Microsof has asked developers for things they need in the kernel, so
what do you need to hook that has enough value to justify it?

Note: hooking even if it is well written slows down the system. I did a
driver that hooked all system calls for a security firm that was paranoid,
it didn’t need to do much, but still ran like a turd. Even for that company
I didn’t see the need, or the justification.

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

“Dana Epp” wrote in message news:xxxxx@ntfsd…
> Hey Pankaj,
>
> Thanks for voicing your views. It’s interesting in the fact that there is
a belief that by simply not documenting the interfaces that we can reduce
the risk against malware that uses it. Greg Hoglund has many examples of
using hooking for rootkits, so I fully understand what you are getting at
here. The reality is that an adversary can still gain access and do this,
with or without Microsoft’s help. At least for now.
>
> I am exploring the rational around the decisions, as well as seeing where
the PERCEIVED risks are. I really want to understand what benefits vs.
drawbacks there are for eliminating hooking that could have real commercial
potential. There are times and situations where I can see hooking being
useful without being malicious. Of course anyone with hostile intent can use
the same vector to cause harm.
>
> Do I want stealth apps to run with exposed API interface? Of course not.
On the other hand, who says hooking cannot be made to allow functional
extensions to the system in a safe manner?
>
> Pankaj Garg wrote:
>
> > One thing i know is that many rootkit drivers use these hooking
techniques
> > to hide themselves. Hooking is one of the most used technique by stealth
> > malware. Other than that, hooks on top of each other can cause problems
(as
> > pointed by Don). Thirdly hooks are not a documented way of doing things.
It
> > directly manipulate the data structures of the OS and you never know
when
> > you do that in unsafe manner. Like the code in hooksys, which is not
> > multi-processor safe. I think Microsoft wants to give well defined ways
to
> > do certain important things but they don’t want to expose the secrets of
the
> > OS which can then be exploited by hackers.
> >
> > Example is, if Microsoft made hooking documented, then there will be
100s of
> > legal drivers using it and then Microsoft is morally (i don’t know if
> > legally) bound to maintain and support that interface. This way the
stealth
> > malware will be supported on every new windows version coming. I bet you
> > don’t want that, right?
> >
>
>
> –
> Regards,
> Dana Epp
> [Blog: http://silverstr.ufies.org/blog/]
>
>

5

But the adversary can’t do it right - because there is no right way to do
it, and thus the system will be unstable, alerting you that Something Is
Wrong.

Hooks are a fundamentally flawed way of adding functionality to a system. If
they are to be fully documented and supported, the system must provide safe
ways of adding and deleting them, and support doing so in the context of a
running system. This is harder than it looks, and puts an additional burden
on the writers of the system to support them that spreads into a lot of
system data structures - and additionally winds up introducing the kinds of
concepts you see in the filter manager kit today, things like elevation
(altitude?)) to avoid problems with ordering. (Who shall hook the hookers?)

At the root of all this, hooks could be made to work, but they are
dramatically insecure unless they have lots of infrastructure around them to
verify their security and make them usable. And the developers of the OS
don’t feel any need to add such things to the system because there are other
ways to do what they want to do without hooks.

Bottom line is that the original developers of the OS believe(d) that hooks
were wrong, and simply didn’t want the system to support using them (and
there are several old-timers on this list who know which orginal developers
I’m talking about). So it didn’t. That attitude carries forward to today, so
the system doesn’t support them now - and likely never will.

…dave

(not a Microsoft employee - anymore)

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dana Epp
Sent: Friday, October 22, 2004 1:16 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Understanding Microsoft’s Stance on Hooking (was re:
Hooksys example… )

Hey Pankaj,

Thanks for voicing your views. It’s interesting in the fact that there is a
belief that by simply not documenting the interfaces that we can reduce the
risk against malware that uses it. Greg Hoglund has many examples of using
hooking for rootkits, so I fully understand what you are getting at here.
The reality is that an adversary can still gain access and do this, with or
without Microsoft’s help. At least for now.

I am exploring the rational around the decisions, as well as seeing where
the PERCEIVED risks are. I really want to understand what benefits vs.
drawbacks there are for eliminating hooking that could have real commercial
potential. There are times and situations where I can see hooking being
useful without being malicious. Of course anyone with hostile intent can use
the same vector to cause harm.

Do I want stealth apps to run with exposed API interface? Of course not. On
the other hand, who says hooking cannot be made to allow functional
extensions to the system in a safe manner?

Pankaj Garg wrote:

One thing i know is that many rootkit drivers use these hooking
techniques to hide themselves. Hooking is one of the most used
technique by stealth malware. Other than that, hooks on top of each
other can cause problems (as pointed by Don). Thirdly hooks are not a
documented way of doing things. It directly manipulate the data
structures of the OS and you never know when you do that in unsafe
manner. Like the code in hooksys, which is not multi-processor safe. I
think Microsoft wants to give well defined ways to do certain
important things but they don’t want to expose the secrets of the OS which
can then be exploited by hackers.

Example is, if Microsoft made hooking documented, then there will be
100s of legal drivers using it and then Microsoft is morally (i don’t
know if
legally) bound to maintain and support that interface. This way the
stealth malware will be supported on every new windows version coming.
I bet you don’t want that, right?

–
Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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

6

I don’t think it is fair to criticize Microsoft for ‘security by
obscurity’ here. Hooking isn’t a ‘secret feature’ that they are hiding
from anyone. It’s no feature at all. Given the unfortunate tendency of
everyone and his dog to run systems where everyone has admin access,
it’s nearly impossible for Microsoft to make it impossible, but I give
them nothing but credit for trying to make it difficult.

There is no bound to the number of things that you, or a nasty, can do
inside the kernel. You could commandeer disk.sys by patching the disk
image. Should Microsoft publish a how-to for that?

Microsoft gets credit for including a documented, more-or-less orderly,
supported, security-model-compatible, mechanism for modifying the
behavior of as much as they do – the filter device driver department.
Many operating systems lacked anything remotely resembling that.

7

Dana Epp wrote:

I understand the risks

So, plenty of people have pointed out the risks. I think it’s pretty
clear that MS should do whatever they can to block hooking of various
tables (like is being done in the AMD64 releases).

But HERE’s the fundamental problem: It’s true that many (er, I’d argue
most) of the reasons people hook various things is out of ignorance.
They simply don’t know that there’s a documented (or, perhaps
semi-documented… don’t get me started on this topic) way to accomplish
what they want to do. So, they resort to brute force. It seems to me
that THIS is precisely the sort of thing the MS wants to prevent. You
make hooking harder, perhaps the hacks will look elsewhere for a solution.

OTOH, there are certainly a few legitimate reasons people need to hook
stuff, and no Windows-supplied alternative exists. As a result, if the
perceived business benefits of using the hook-by-brute-force-method
outweigh the RISK (as perceived by the manager who’s making the
decision), people ARE going to find a way to hack-in their hooks.

The ONLY way to stop this is to actually take the time to identify the
common reasons that people tend to brute-force-hook stuff, and (a)
document the existing approved mechanisms for accomplishing those goals,
or (b) add approved mechanisms for accomplishing those goals.

P

8

Hey Don,

I think I am exploring this more to understand it before commenting much on my needs. Its hard to do an needs analysis for support when I don’t yet have the foundation of knowledge on what is expected in these situations.

Right now I am wrestling with managing codebases against backwards compatibility. Things like the new filter manager and IoCreateFileSpecifyDeviceObjectHint have been promised to be backwards compatible to W2K, but haven’t really seen the light of day for commercial use (yet). A perfect example of this was at last years Driver DevCon. I sat with Neil and Darren during an expert lunch session and discussed the new filter manager architecture as they tried to convince me to move my code to the new framework. Don’t get me wrong, I love the new framework; its clean, easier to manage and appears to have a lot of code I have had to manually write by way of normalized pathing etc. At that time I was told that I could expect the W2K support soon ™. Darren just got it compiling on W2K while DevCon was on. I wasn’t entirely convinced and decided to wait… which was a good decision on my part. It’s still not out, and its been a year now.

Another example is IoCreateFileSpecifyDeviceObjectHint. Neil informed the list in August that this would be backported into a security fix for this October instead of rolling out the hotfix to the public. Yet there is no confirmation that this made it into the latest patch. (I haven’t had time to check the new ntoskrl.exe and do a depends on it as Ladislav has recommended.)

Now I am looking at dealing with some filtering stuff with the registry. I have a ‘hooking’ base that works across all commercial versions of Windows since W2K, but it not ‘commercial-ready’ and needs to be cleaned up. I look upon the registry callbacks as a much more elegant and clean solution but note its NOT available for W2K. Can I wait for a backport? From current track record history… not really. Of course, a different solution may exist, but I simply don’t know about it as its not really documented. So do I wrestle with the working hooks? Maintain two entirely different codebases using the callbacks for XP+, and hooking for W2K (yuk)? As I look upon these decisions I read more about the problems with hooking and try to weigh everything accordingly. Which then gets me to look upon other peoples experience like your own to really understand what “other” risks exist, and possible what BETTER solutions exist.

Don’t get me wrong here. I am not blaming Microsoft for anything. I appreciate their insight and feedback on a lot of things. I just want to make sure decisions that I make are based on a strong understanding on both sides. As an example, I simply no longer have a working W2K driver as I decided to use IoCreateFileSpecifyDeviceObjectHint instead of some shadowing techniques I could have used. That decision has a major impact on the codebase… and now the product. As I await the release of the fix from Microsoft which holds the backport, I need to learn from this and figure out the best plan of action in future decisions… which includes knowing what is REALLY going on in the hooking arena.

If you are going to the PlugFest in December, let me buy you a beer. I would love to discuss the experience you had when hooking all the system calls.

Don Burn wrote:

Well I guess my question would be what hooking do you need that isn’t
provided by another mechanism? Microsoft has added callback support for
registry calls so that RegMon didn’t need the kludge hook. I/O is better
handled by filter drivers, than by one massive hook. Process/thread
creation and termination have callbacks, as does executable image load. I
know Microsof has asked developers for things they need in the kernel, so
what do you need to hook that has enough value to justify it?

Note: hooking even if it is well written slows down the system. I did a
driver that hooked all system calls for a security firm that was paranoid,
it didn’t need to do much, but still ran like a turd. Even for that company
I didn’t see the need, or the justification.

–
Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]

9

> Now I am looking at dealing with some filtering

stuff with the registry. I have a ‘hooking’ base
that works across all commercial versions of Windows
since W2K, but it not ‘commercial-ready’ and needs
to be cleaned up. I look upon the registry callbacks
as a much more elegant and clean solution but note
its NOT available for W2K.

The current state of the “registry callback” stuff
seems to be ok for notification purposes, but for more
serious applications it is not sufficient.

If you are going to the PlugFest in December, …

Anyone besides me interested in tracking down the dev
for this stuff at the plugfest? Maybe we can get the
plugfest organizers to set up one of those mini side
classes they sometimes do.

10

So what are the common reasons for hooking system calls as opposed to
using well known, well understood methods of filtering APIs via DDK and
IFS kit & filter manager, which level the playing field for all vendors
so they can interop with each other? I’d love to know the specifics
(just so that we can improve the experience if, given all the
limitations we have with respect to backward compatibility and release
schedules and conflicting requests).

But don’t apply if you are writing a root kit.
Ravi

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of PeterGV
Sent: Friday, October 22, 2004 2:25 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Understanding Microsoft’s Stance on Hooking (was re:
Hooksys example… )

Dana Epp wrote:

I understand the risks

So, plenty of people have pointed out the risks. I think it’s pretty
clear that MS should do whatever they can to block hooking of various
tables (like is being done in the AMD64 releases).

But HERE’s the fundamental problem: It’s true that many (er, I’d argue
most) of the reasons people hook various things is out of ignorance.
They simply don’t know that there’s a documented (or, perhaps
semi-documented… don’t get me started on this topic) way to accomplish
what they want to do. So, they resort to brute force. It seems to me
that THIS is precisely the sort of thing the MS wants to prevent. You
make hooking harder, perhaps the hacks will look elsewhere for a
solution.

OTOH, there are certainly a few legitimate reasons people need to hook
stuff, and no Windows-supplied alternative exists. As a result, if the
perceived business benefits of using the hook-by-brute-force-method
outweigh the RISK (as perceived by the manager who’s making the
decision), people ARE going to find a way to hack-in their hooks.

The ONLY way to stop this is to actually take the time to identify the
common reasons that people tend to brute-force-hook stuff, and (a)
document the existing approved mechanisms for accomplishing those goals,
or (b) add approved mechanisms for accomplishing those goals.

P

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

11

1 reason would be to intercept API operations that are not normally

available for monitoring in some other way. For example, Regmon
traditionally was implemented by "hooking" the system calls for the
registry. Long ago, we used the same mechanism for detecting when a
file was being memory mapped by an application.

Other examples are a bit more complex: taking over the debug message
interface so you can redirect the debug messages (debugmon) - that's not
hooking the system call interface (since it is done through the
interrupt dispatch table). Real-time extensions to the OS might take
over the clock interrupt handler. We've been involved in projects that
take over the page fault handler. As Peter pointed out, THESE are cases
where it might be appropriate because there is no other mechanism for
achieving the requirements of the project.

However, companies that patch code (I know of AV vendors that patch
IoCreateFile) often do so because that's the way they learned to do it
on Windows 3.1/95/98/ME - and thus the are working with the paradigm the
used.

Regards,

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ravisankar Pudipeddi
Sent: Friday, October 22, 2004 9:02 PM
To: ntfsd redirect
Subject: RE: [ntfsd] Understanding Microsoft's Stance on Hooking (was
re: Hooksys example... )

So what are the common reasons for hooking system calls as opposed to
using well known, well understood methods of filtering APIs via DDK and
IFS kit & filter manager, which level the playing field for all vendors
so they can interop with each other? I'd love to know the specifics
(just so that we can improve the experience if, given all the
limitations we have with respect to backward compatibility and release
schedules and conflicting requests).

But don't apply if you are writing a root kit.
Ravi

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of PeterGV
Sent: Friday, October 22, 2004 2:25 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Understanding Microsoft's Stance on Hooking (was re:
Hooksys example... )

Dana Epp wrote:

I understand the risks

So, plenty of people have pointed out the risks. I think it's pretty
clear that MS should do whatever they can to block hooking of various
tables (like is being done in the AMD64 releases).

But HERE's the fundamental problem: It's true that many (er, I'd argue
most) of the reasons people hook various things is out of ignorance.
They simply don't know that there's a documented (or, perhaps
semi-documented... don't get me started on this topic) way to accomplish
what they want to do. So, they resort to brute force. It seems to me
that THIS is precisely the sort of thing the MS wants to prevent. You
make hooking harder, perhaps the hacks will look elsewhere for a
solution.

OTOH, there are certainly a few legitimate reasons people need to hook
stuff, and no Windows-supplied alternative exists. As a result, if the
perceived business benefits of using the hook-by-brute-force-method
outweigh the RISK (as perceived by the manager who's making the
decision), people ARE going to find a way to hack-in their hooks.

The ONLY way to stop this is to actually take the time to identify the
common reasons that people tend to brute-force-hook stuff, and (a)
document the existing approved mechanisms for accomplishing those goals,
or (b) add approved mechanisms for accomplishing those goals.

P

Questions? First check the IFS FAQ at

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the IFS FAQ at

You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
''
To unsubscribe send a blank email to xxxxx@lists.osr.com

12

The driver I worked on that hooked all the system calls was to try to
determine patterns that showed virus infection. For this they wanted to see
a log of all calls from applications.

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

“Ravisankar Pudipeddi” wrote in message
news:xxxxx@ntfsd…
So what are the common reasons for hooking system calls as opposed to
using well known, well understood methods of filtering APIs via DDK and
IFS kit & filter manager, which level the playing field for all vendors
so they can interop with each other? I’d love to know the specifics
(just so that we can improve the experience if, given all the
limitations we have with respect to backward compatibility and release
schedules and conflicting requests).

But don’t apply if you are writing a root kit.
Ravi

13

> Now I am looking at dealing with some filtering stuff with the registry.

I have a ‘hooking’ base that works across all commercial versions
of Windows since W2K, but it not ‘commercial-ready’ and needs
to be cleaned up. I look upon the registry callbacks as a much more
elegant and clean solution but note its NOT available for W2K.

Well, so be prepared that many things can happen
in the future to prevent your product work.
For example, if I were Microsoft and I knew that
various malware hooks the system, I would
implement a hook-check thread into the kernel, which
tests the system service table and does something if they don’t
agree. This change will prevent system software that hooks the system
from work.

(As far as I remember, we already discussed that option here).

L.

14

Ravisankar Pudipeddi wrote:

So what are the common reasons for hooking system calls as opposed to
using well known, well understood methods of filtering APIs via DDK and
IFS kit & filter manager, which level the playing field for all vendors
so they can interop with each other?

So as not to put the cart before the hourse, I’d suggest those “well
known, well understood” methods should become “documented” methods. For
example, we’ve talked in passing about the registry APIs. Are those now
documented and officially public? Last I heared they were not. But I
admit I haven’t exactly been following the topic closely.

We spent some time on this question here at OSR a few months ago. Our
research showed that the majority of reasons people cite for wanting to
hack/hook stuff was because they didn’t know a better way. One example
here is people who manually hook the vector for NMIs. There’s actually
a documented DDI for this… IF people knew it was there, and IF it were
backwards compatible to Win2K.

OTOH, as Tony mentioned, there are LOTS of people who want/need to hook
particular APIs because they want to track, restrict, manage them in
some unique way. They often see hooking the System Service Table as the
solution. What’s the preferred mechanism for accomplishing this goal?
Heck, I’m not even sure there’s general agreement on ways to do this.
I, for one, would suggest placing the hook in the appropriate user-mode
DLL dispatch routine instead of in the System Service Table. I wonder
if that’s documented anywhere.

Our research revealed a very significant number of community members who
want/need to be able to veto execution of a given program. The process
creation hook in the kernel is good for information purposes, but there
is no documented/approved way to use this mechanism to say “Now that I
see this is being invoked, let’s not allow it.” This was probably the
number one “legitimate” use of hooking.

Tony also mentioned the debug interrupt (used to display DbgPrint).
Heck, we at OSR hook that one ourselves. Wanting access to this
interrupt (to redirect debug messages) is legitimate – Though I can
certainly see that providing such a hook wouldn’t be a priority.

Peter
OSR

15

Hi Peter,

I, for one, would suggest placing the hook in the
> appropriate user-mode DLL dispatch routine instead
> of in the System Service Table. I wonder if that’s
> documented anywhere.

It is not, and with reason: It is not good enough. Hooking is most often
done by security software in the most general sense, as you observed;
such software attempts to place additional restraints on the behaviour
of running programs. I believe that the authors of paranoid software
would be rather unhappy with a proposal that can be circumvented with a
simple “sysenter” (or “int 2eh”, as the case may be).

Our research revealed a very significant number of
> community members who want/need to be able to veto
> execution of a given program. The process creation
> hook in the kernel is good for information purposes,
> but there is no documented/approved way to use this
> mechanism to say “Now that I see this is being
> invoked, let’s not allow it.”

The same goes for the loaded-image call-back (oh, and not only is the
module only halfway loaded – the caller also hold the address-space
lock while invoking call-backs).

Essentially, NT is rather unfriendly towards those who want to influence
the behaviour of the OS on a higher level than “open, read, write,
close”.

Cheers,
Felix.

16

Hooking inevitably produces the interop issues between 2 hookers. After
this MS will be blamed for the OS crash.

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

----- Original Message -----
From: “Dana Epp”
To: “Windows File Systems Devs Interest List”
Sent: Friday, October 22, 2004 6:36 AM
Subject: Understanding Microsoft’s Stance on Hooking (was re: [ntfsd] Hooksys
example… )

> You know I am probably going to get in trouble for this one, but I would love
for someone from Microsoft to talk about WHY they are so against hooking. I’m
curious.
>
> I can see ample reasons for hooking ranging from wanting to hook a system
call or two to suppress its functionality (ie: Preventing the setting of
seDebugPrivileges) to backwards compatibility requirements against earlier
versions of the OS (ie: the diff for registry hooking vs. the registry callback
API available since XP… why manage two entirely different code bases for the
same functionality)
>
> I understand the risks, and the issues that Don pointed out that arise from
hooks above or below or pointing to the wrong places against the syscall table.
What I am curious is to the reason so much effort is being put into preventing
it. What threats are trying to be mitigated here, especially when weighed
against the possible usefulness of the technique?
>
>
> James Antognini [MSFT] wrote:
>
> > Let me emphasize what Don said: Hooking is not a good idea in the general
> > case. If you’re doing it to investigate something in your lab, feel free.
> > But avoid hooking in product code or even in code you distribute widely.
> >
>
>
> –
> Regards,
> Dana Epp
> [Blog: http://silverstr.ufies.org/blog/]
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

17

Very interesting question. No real answers yet
besides “that’s the way MS does it” (which is a
perfectly valid reason). BTW, if there really is a
security issue with hooking, probably no one who knows
will discuss it here.

Here are some random thoughts:

Security
If I manage to get a kernel driver loaded on a box, I
can own the box. It doesn’t matter what interfaces I
use.

Speed
Seems to me that hooking will always be faster (less
overhead).

Level of Difficulty
Much simpler initially to hook. For example, a driver
that printed out the return code for open calls would
take about 10 lines when hooking vs. a lot more with a
filter. Once the complexity of the driver reaches a
certain point, this isn’t very important. Don’t know
how a mini-filter would do here.

Interop
What are the main issues with interop between drivers?
Here are some I’ve seen:

  • Recursion
  • Stack usage
  • Context
    Seems to me that all of these do better in a hooking
    model.

Completion and Context
Simpler to call the routine below you and deal with
the return in the same function rather than
registering a completion routine, high IRQLs, worker
threads, etc. Of course, syncing back to the dispatch
routine is pretty simple and similar to the hooking
model…

Stability
With a proper hooking API this can be stable.

Functionality Coverage
The good thing with hooking is that you have access to
all functionality…no need to have MS provide an
interface. The bad thing with hooking is that you
have access to all functionalilty without MS providing
you an interface :slight_smile:

Unloading
This can be done more easily with hooking. What’s one
of the main reasons filter drivers can’t unload: They
have registered a completion routine in an IRP that is
below them. With a hook, you can get out anytime,
unless you need to undo changes you have made to
requests that have been sent down… This would of
course assume a proper unhook API or methodology.

It would be interesting to have someone familiar with
the filter manager detail how it addresses some of
these issues.

I’m sure there are some things that I’m not thinking
about. The grass is always greener…right?

18

One good argument for hooking: More context. A filter sees a file being
opened or read through the paging I/O path; a hook can actually tell
that a file was opened with execute access and is now used to create a
section object (again with execution allowed) and is being mapped into
PAGE_EXECUTE memory.

One good argument against hooking: If I were MS, I would break every
hook in every FE or at least SP, just so people cannot come back later
and whine about backwards compatibility. Raymond Chen has some good
(well, not so good) war stories –
http://blogs.msdn.com/oldnewthing/category/2282.aspx is the “history”
category of his blog.

One bad argument against hooking: Some of the original designers of NT
don’t like hooks (and call-backs, and every other way to modify the OS’s
behaviour). I have heard claims about how hooking drivers might make MS
look bad if they are slow or buggy. Well, duh. As if filter drivers were
always as pure as the driven snow.

I’d rather see an official hooking API and/or rich set of call-backs –
and in the dump file header, and every tenth second in the kernel
debugger, there should be fat bold lettering “HOOKS ARE IN USE. IT IS
*THEIR* FAULT” or something to that effect.

Oh well. Unless NT learns to provide a decent interface to its
functionality (from both sides), I am afraid hooks are here to stay. and
as you imply, once a driver is in the system, it can just go and disable
whatever the OS did to make the system service table read-only, up to
patching any run-time validators out of existence. (I can think of
hardware that would be waterproof, but nothing within reach of current
hardware.)

Cheers,
Felix.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Randy Cook
Sent: Tuesday, 26 October 2004 14:17
To: Windows File Systems Devs Interest List
Subject: Re: Understanding Microsoft’s Stance on Hooking (was re:
[ntfsd] Hooksys example… )

Very interesting question. No real answers yet
besides “that’s the way MS does it” (which is a
perfectly valid reason). BTW, if there really is a
security issue with hooking, probably no one who knows
will discuss it here.

Here are some random thoughts:

Security
If I manage to get a kernel driver loaded on a box, I
can own the box. It doesn’t matter what interfaces I
use.

Speed
Seems to me that hooking will always be faster (less
overhead).

Level of Difficulty
Much simpler initially to hook. For example, a driver
that printed out the return code for open calls would
take about 10 lines when hooking vs. a lot more with a
filter. Once the complexity of the driver reaches a
certain point, this isn’t very important. Don’t know
how a mini-filter would do here.

Interop
What are the main issues with interop between drivers?
Here are some I’ve seen:

  • Recursion
  • Stack usage
  • Context
    Seems to me that all of these do better in a hooking
    model.

Completion and Context
Simpler to call the routine below you and deal with
the return in the same function rather than
registering a completion routine, high IRQLs, worker
threads, etc. Of course, syncing back to the dispatch
routine is pretty simple and similar to the hooking
model…

Stability
With a proper hooking API this can be stable.

Functionality Coverage
The good thing with hooking is that you have access to
all functionality…no need to have MS provide an
interface. The bad thing with hooking is that you
have access to all functionalilty without MS providing
you an interface :slight_smile:

Unloading
This can be done more easily with hooking. What’s one
of the main reasons filter drivers can’t unload: They
have registered a completion routine in an IRP that is
below them. With a hook, you can get out anytime,
unless you need to undo changes you have made to
requests that have been sent down… This would of
course assume a proper unhook API or methodology.

It would be interesting to have someone familiar with
the filter manager detail how it addresses some of
these issues.

I’m sure there are some things that I’m not thinking
about. The grass is always greener…right?

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@mvps.org
To unsubscribe send a blank email to xxxxx@lists.osr.com

19

> Unloading

This can be done more easily with hooking. What’s one

You cannot unload the hooker driver. Just forget about it. There is no stable
ways of doing this.

Anyway unloading is not an issue and gives no market value to the product.

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

20

> > Unloading This can be done more easily with hooking. What’s one

You cannot unload the hooker driver. Just forget about it.
There is no stable ways of doing this.

Anyway unloading is not an issue and gives no market value to the
product.

That is not entirely true; unloading such that you may perform an
upgrade without a reboot is a wonderful feature to provide to your
customers.