Hooking and vista

NTFSD
1

I have put this out on one of the beta groups for Vista. With our
discussions here about hooking, I figured I should repeat it here.
Hopefully, people will help push Microsoft to do the right thing.

With all the stuff about Sony’s DRM rootkit, it seems like a good time to
ask Microsoft to reconsider their stance on no hook protection for 32-bit
systems. Yes I realize there are a number of products that hook, but with
the capability being blocked on 64-bit system, hopefully these products are
changing. Even if they are not, how about making it a boot option, that the
customer can disable the hook checks if they have a product that does this.

Some of us have been asking for the ability to block hooks for years, it is
time for this to be present in all future versions of the OS.

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

2

I know hooking is not at all the fashion these days but in a thread a few
days ago, it was you admitting that in certain situations hooking is
necessary (although evil according to you) . It is usually only
theoreticians or people writing drivers for hardware devices but never those
who write real software solutions to the problems we are facing in this
world coming up with these suggestions. Instead of a boot option, I suggest
a registry value which is set to allow by default. The alternatives that
Microsoft has provided such as the registry callbacks are even much more
operating system dependent and leave a lot to be desired for many reasons.
What this world really needs is a proper interface for intercepting kernel
calls and documentation how to do it properly. This will resolve all of the
possible problems you have managed to sum up so far.

Regards,

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

“Don Burn” wrote in message news:xxxxx@ntfsd…
>I have put this out on one of the beta groups for Vista. With our
>discussions here about hooking, I figured I should repeat it here.
>Hopefully, people will help push Microsoft to do the right thing.
>
>
> With all the stuff about Sony’s DRM rootkit, it seems like a good time to
> ask Microsoft to reconsider their stance on no hook protection for 32-bit
> systems. Yes I realize there are a number of products that hook, but with
> the capability being blocked on 64-bit system, hopefully these products
> are
> changing. Even if they are not, how about making it a boot option, that
> the
> customer can disable the hook checks if they have a product that does
> this.
>
> Some of us have been asking for the ability to block hooks for years, it
> is
> time for this to be present in all future versions of the OS.
>
>

3

Daniel,

> is usually only theoreticians or people writing drivers for hardware
> devices but never those who write real software solutions to the problems
> we are facing in this

Lemme guess. Your one of those tough heros which write “real code” ™.
Congratulations. And you see a reson for hooking everywhere. Because you
are a
hard working coder, and not a teoretician. Despite your position, real need
for hooking
arise in extremly few situations. There are legitimate situations to do
this, but despite
the very poular beleif that are a lot of them, guess what, there are very
few of them.

I have no ideea what products you write , and maybe you have a legitimate
need for hooking,
but keep in mind that I would incline to call you a diletante and
theoretician, and one which
writes fishy code, then listenig to your self righteous carachterizations of
other ppl.

Dan

----- Original Message -----
From: “Daniel Terhell”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Friday, November 11, 2005 7:06 PM
Subject: Re:[ntfsd] Hooking and vista

>I know hooking is not at all the fashion these days but in a thread a few
>days ago, it was you admitting that in certain situations hooking is
>necessary (although evil according to you) . It is usually only
>theoreticians or people writing drivers for hardware devices but never
>those who write real software solutions to the problems we are facing in
>this world coming up with these suggestions. Instead of a boot option, I
>suggest a registry value which is set to allow by default. The alternatives
>that Microsoft has provided such as the registry callbacks are even much
>more operating system dependent and leave a lot to be desired for many
>reasons. What this world really needs is a proper interface for
>intercepting kernel calls and documentation how to do it properly. This
>will resolve all of the possible problems you have managed to sum up so
>far.
>
> Regards,
>
> Daniel Terhell
> Resplendence Software Projects Sp
> xxxxx@resplendence.com
> http://www.resplendence.com
>
>
>
>
>
>
>
>
> “Don Burn” wrote in message news:xxxxx@ntfsd…
>>I have put this out on one of the beta groups for Vista. With our
>>discussions here about hooking, I figured I should repeat it here.
>>Hopefully, people will help push Microsoft to do the right thing.
>>
>>
>> With all the stuff about Sony’s DRM rootkit, it seems like a good time to
>> ask Microsoft to reconsider their stance on no hook protection for 32-bit
>> systems. Yes I realize there are a number of products that hook, but
>> with
>> the capability being blocked on 64-bit system, hopefully these products
>> are
>> changing. Even if they are not, how about making it a boot option, that
>> the
>> customer can disable the hook checks if they have a product that does
>> this.
>>
>> Some of us have been asking for the ability to block hooks for years, it
>> is
>> time for this to be present in all future versions of the OS.
>>
>>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to xxxxx@lists.osr.com

4

There is a tension here: between those who want to do something
legitimate (think about Irp Tracker - it relies upon system call hooking
in order to observe the system calls) and those who want to use the same
techniques for something illegitimate (think “root kit”.)

There are two ways of looking at the anti-hooking code:

  • It is there to prevent ALL hooking (good or benign); or
  • Is is there to raise the bar for hooking so that by the time you CAN
    hook, you should know enough to make it work right.

Then there are kits (like the Sony DRM product) that “walk the line”
between these two. I had multiple people point out that I had answered
questions for one of the developers of that product (with the
implication that by answering questions for “such people” *I* had done
something wrong.)

And yet, years ago we worked with a large company that wanted a DRM
product that would hide itself and allow them to do many of the same
things that the Sony product did - I insisted that they had to
explicitly indemnify us against their use of this product. Their
lawyer’s balked. In hindsight, it looks like my concerns were not as
radical or ludicrous as it might have seemed at the time.

I do agree that it would behoove Cutler’s team to consider providing an
alternative to the “hooking” interface. But apparently nobody’s been
able to make a convincing case to him thus far (although I have to say
that losing IrpTracker and other diagnostic tools of this type is a
significant loss.)

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Daniel Terhell
Sent: Friday, November 11, 2005 12:06 PM
To: ntfsd redirect
Subject: Re:[ntfsd] Hooking and vista

I know hooking is not at all the fashion these days but in a thread a
few
days ago, it was you admitting that in certain situations hooking is
necessary (although evil according to you) . It is usually only
theoreticians or people writing drivers for hardware devices but never
those
who write real software solutions to the problems we are facing in this
world coming up with these suggestions. Instead of a boot option, I
suggest
a registry value which is set to allow by default. The alternatives that

Microsoft has provided such as the registry callbacks are even much more

operating system dependent and leave a lot to be desired for many
reasons.
What this world really needs is a proper interface for intercepting
kernel
calls and documentation how to do it properly. This will resolve all of
the
possible problems you have managed to sum up so far.

Regards,

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

“Don Burn” wrote in message news:xxxxx@ntfsd…
>I have put this out on one of the beta groups for Vista. With our
>discussions here about hooking, I figured I should repeat it here.
>Hopefully, people will help push Microsoft to do the right thing.
>
>
> With all the stuff about Sony’s DRM rootkit, it seems like a good time
to
> ask Microsoft to reconsider their stance on no hook protection for
32-bit
> systems. Yes I realize there are a number of products that hook, but
with
> the capability being blocked on 64-bit system, hopefully these
products
> are
> changing. Even if they are not, how about making it a boot option,
that
> the
> customer can disable the hook checks if they have a product that does
> this.
>
> Some of us have been asking for the ability to block hooks for years,
it
> is
> time for this to be present in all future versions of the OS.
>
>

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

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

5

I admit, not being a theoretician, the suggestion for a registry value is
not a reliable solution and not well though over. But the issue is if we let
all those tough heros like me write write filter drivers for every little
thing in the OS that needs to be monitored, a real mess is guaranteed.
Hooking system calls I think has been a fundamental part of operating
systems since the beginning of operating systems. The idea that now we have
thus far evolved that we have such a safe and compelte operating system that
it is no longer needed is an illusion and I think one of the reasons why the
development of 64 bit software is not really taking off. Developers will
continue to innovate new solutions for which modification of the way the
operating system works is unavoidable, and the current situation for Win x64
I consider a deprivation of third-party innovation rather than a security
measure .

/Daniel

“Dan Partelly” wrote in message news:xxxxx@ntfsd…
>>> is usually only theoreticians or people writing drivers for hardware
>>> devices but never those who write real software solutions to the
>>> problems we are facing in this
>
> Lemme guess. Your one of those tough heros which write “real code” ™.
> Congratulations. And you see a reson for hooking everywhere. Because you
> are a
> hard working coder, and not a teoretician. Despite your position, real
> need for hooking
> arise in extremly few situations. There are legitimate situations to do
> this, but despite
> the very poular beleif that are a lot of them, guess what, there are very
> few of them.
>
> I have no ideea what products you write , and maybe you have a legitimate
> need for hooking,
> but keep in mind that I would incline to call you a diletante and
> theoretician, and one which
> writes fishy code, then listenig to your self righteous carachterizations
> of other ppl.
>
> Dan
>
>
>
>
> ----- Original Message -----
> From: “Daniel Terhell”
> Newsgroups: ntfsd
> To: “Windows File Systems Devs Interest List”
> Sent: Friday, November 11, 2005 7:06 PM
> Subject: Re:[ntfsd] Hooking and vista
>
>
>>I know hooking is not at all the fashion these days but in a thread a few
>>days ago, it was you admitting that in certain situations hooking is
>>necessary (although evil according to you) . It is usually only
>>theoreticians or people writing drivers for hardware devices but never
>>those who write real software solutions to the problems we are facing in
>>this world coming up with these suggestions. Instead of a boot option, I
>>suggest a registry value which is set to allow by default. The
>>alternatives that Microsoft has provided such as the registry callbacks
>>are even much more operating system dependent and leave a lot to be
>>desired for many reasons. What this world really needs is a proper
>>interface for intercepting kernel calls and documentation how to do it
>>properly. This will resolve all of the possible problems you have managed
>>to sum up so far.
>>
>> Regards,
>>
>> Daniel Terhell
>> Resplendence Software Projects Sp
>> xxxxx@resplendence.com
>> http://www.resplendence.com
>>
>>
>>
>>
>>
>>
>>
>>
>> “Don Burn” wrote in message news:xxxxx@ntfsd…
>>>I have put this out on one of the beta groups for Vista. With our
>>>discussions here about hooking, I figured I should repeat it here.
>>>Hopefully, people will help push Microsoft to do the right thing.
>>>
>>>
>>> With all the stuff about Sony’s DRM rootkit, it seems like a good time
>>> to
>>> ask Microsoft to reconsider their stance on no hook protection for
>>> 32-bit
>>> systems. Yes I realize there are a number of products that hook, but
>>> with
>>> the capability being blocked on 64-bit system, hopefully these products
>>> are
>>> changing. Even if they are not, how about making it a boot option, that
>>> the
>>> customer can disable the hook checks if they have a product that does
>>> this.
>>>
>>> Some of us have been asking for the ability to block hooks for years, it
>>> is
>>> time for this to be present in all future versions of the OS.
>>>
>>>
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>

6

Just my two cents worth which is probably not worth much more than that.

I like the idea of a boot time registry entry that allows hooks with
the default set to OFF. Why off??? Because it protects people who don’t
want the intrusion. I’d actually be in favor of the same for 3rd party
filter drivers, but that’s another discussion.

The boot time registry entry should be settable only after explicit
consent by the user of the computer. I assume that Microsoft could
easily invent protected registry entries that can only be set after
a forced dialogue box (standardized) has been run to describe what
is happening and gain consent by the end user.

I also agree that it should be a defined interface that is documented.
The interface should be implemented so that ONLY specially signed
drivers are capable of using it. The one exception I woudl make would
be when a Kernel debugger is running and/or the checked build is running.

This would require people to register with Microsoft their solutions.
Microsoft should NOT be the judge as to the ligitimacy of the need,
just the registrar. They should also make the the registry of
applications available publically.

Every person registering should have to explain their reason for using
the hooking interface - again not to be judged, just for disclosure
purposes. This information should also be public.

The rules should state that if it is discovered that a registered
application is doing something significantly different than is stated,
Microsoft can (at their discretion) revoke the registration and therefore
the signing of their driver.

Another rule should require that the hooking software be easily
removable from the system.

For the sake of development before release of a product, I would
propose that when a Kernel debugger and/or the checked build are
running that the checking be turned off. Developers should be able
to live with those restrictions for the sake of product development
issues.

Just my humble opinion,

Rick Cadruvi…

P.S. I have never needed to do hooking on Windows, but I can definately
see legitimate reasons why a product might need to.

7

Your most likely writting security products , me thinks,
from the description of

" all those tough heros like me write write filter drivers for every little

thing in the OS that needs to be monitored, a real mess is guaranteed"

But in generail ,why do you consider filter drivers a “real mess” ?
You cant handle them ? They happen to be wondefull, and I wish that
other operating systems adopt the phiosophy.

>Hooking system calls I think has been a fundamental part of operating
>systems since the beginning of operating systems.

Who told you this ? I dont think so. Drivers, and API / ABIs s , where
always part of operating system since beggining. Syscalls
where not hookable by design. Show me a single 32/64 bit
operating system which have syscall hooking by design,
which means it provides APIs for hook/unhook a syscall.

----- Original Message -----
From: “Daniel Terhell”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Friday, November 11, 2005 7:40 PM
Subject: Re:[ntfsd] Re:Hooking and vista

>I admit, not being a theoretician, the suggestion for a registry value is
>not a reliable solution and not well though over. But the issue is if we
>let all those tough heros like me write write filter drivers for every
>little thing in the OS that needs to be monitored, a real mess is
>guaranteed. Hooking system calls I think has been a fundamental part of
>operating systems since the beginning of operating systems. The idea that
>now we have thus far evolved that we have such a safe and compelte
>operating system that it is no longer needed is an illusion and I think one
>of the reasons why the development of 64 bit software is not really taking
>off. Developers will continue to innovate new solutions for which
>modification of the way the operating system works is unavoidable, and the
>current situation for Win x64 I consider a deprivation of third-party
>innovation rather than a security measure .
>
> /Daniel
>
>
>
> “Dan Partelly” wrote in message
> news:xxxxx@ntfsd…
>>>> is usually only theoreticians or people writing drivers for hardware
>>>> devices but never those who write real software solutions to the
>>>> problems we are facing in this
>>
>> Lemme guess. Your one of those tough heros which write “real code” ™.
>> Congratulations. And you see a reson for hooking everywhere. Because you
>> are a
>> hard working coder, and not a teoretician. Despite your position, real
>> need for hooking
>> arise in extremly few situations. There are legitimate situations to do
>> this, but despite
>> the very poular beleif that are a lot of them, guess what, there are very
>> few of them.
>>
>> I have no ideea what products you write , and maybe you have a legitimate
>> need for hooking,
>> but keep in mind that I would incline to call you a diletante and
>> theoretician, and one which
>> writes fishy code, then listenig to your self righteous carachterizations
>> of other ppl.
>>
>> Dan
>>
>>
>>
>>
>> ----- Original Message -----
>> From: “Daniel Terhell”
>> Newsgroups: ntfsd
>> To: “Windows File Systems Devs Interest List”
>> Sent: Friday, November 11, 2005 7:06 PM
>> Subject: Re:[ntfsd] Hooking and vista
>>
>>
>>>I know hooking is not at all the fashion these days but in a thread a few
>>>days ago, it was you admitting that in certain situations hooking is
>>>necessary (although evil according to you) . It is usually only
>>>theoreticians or people writing drivers for hardware devices but never
>>>those who write real software solutions to the problems we are facing in
>>>this world coming up with these suggestions. Instead of a boot option, I
>>>suggest a registry value which is set to allow by default. The
>>>alternatives that Microsoft has provided such as the registry callbacks
>>>are even much more operating system dependent and leave a lot to be
>>>desired for many reasons. What this world really needs is a proper
>>>interface for intercepting kernel calls and documentation how to do it
>>>properly. This will resolve all of the possible problems you have managed
>>>to sum up so far.
>>>
>>> Regards,
>>>
>>> Daniel Terhell
>>> Resplendence Software Projects Sp
>>> xxxxx@resplendence.com
>>> http://www.resplendence.com
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> “Don Burn” wrote in message news:xxxxx@ntfsd…
>>>>I have put this out on one of the beta groups for Vista. With our
>>>>discussions here about hooking, I figured I should repeat it here.
>>>>Hopefully, people will help push Microsoft to do the right thing.
>>>>
>>>>
>>>> With all the stuff about Sony’s DRM rootkit, it seems like a good time
>>>> to
>>>> ask Microsoft to reconsider their stance on no hook protection for
>>>> 32-bit
>>>> systems. Yes I realize there are a number of products that hook, but
>>>> with
>>>> the capability being blocked on 64-bit system, hopefully these products
>>>> are
>>>> changing. Even if they are not, how about making it a boot option,
>>>> that the
>>>> customer can disable the hook checks if they have a product that does
>>>> this.
>>>>
>>>> Some of us have been asking for the ability to block hooks for years,
>>>> it is
>>>> time for this to be present in all future versions of the OS.
>>>>
>>>>
>>>
>>>
>>>
>>> —
>>> Questions? First check the IFS FAQ at
>>> https://www.osronline.com/article.cfm?id=17
>>>
>>> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
>>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to xxxxx@lists.osr.com

8

Rick,

I like the idea of a boot time registry entry that allows hooks with
the default set to OFF. Why off??? Because it protects people who don’t
want the intrusion. I’d actually be in favor of the same for 3rd party
filter drivers, but that’s another discussion.
What if “someone” finds a “workaround” and if this “someone” is a bad guy.
The end-user still feels safe - I mean he had turned on this option, didn’t
he. So how would you feel being the end-user and finally finding out that:
“Well, hooking is restricted, but the bad guys with the bad methods still
find a way in”?

Oliver

–

May the source be with you, stranger :wink:

ICQ: #281645
URL: http://assarbad.net

9

“Daniel Terhell” wrote in message
news:xxxxx@ntfsd…
> Hooking system calls I think has been a fundamental part of operating
> systems since the beginning of operating systems.

I’ve only been around the OS world for 35 years, most of that time hooking
was considered an extremely bad thing. A minicomputer company I worked for
had that in their license that you would not hook, and sued out of existance
a software firm that did.

Yes I said there are rare occasions when you need to hook, but they are a
lot rarer than most people think, and most of them are for things like
IrpTracker. For a commercial product having to hook normally means you did
a lousy design.

Note: I am not proposing anything new, just apply the hook checks that
Microsoft is doing when you go to 64-bit to the 32-bit world. I don’t want
a registry setting it is too easy to override, just like the /noexecute
switch which can also break things this ought to be a command line option.

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

10

>What if “someone” finds a “workaround” and if this “someone” is a bad guy.

The end-user still feels safe - I mean he had turned on this option, didn’t
he. So how would you feel being the end-user and finally finding out that:
“Well, hooking is restricted, but the bad guys with the bad methods still
find a way in”?

Oliver,

There probably isn’t anyway to guarantee that “bad” people won’t find
a workaround to ANY solution including the proposed Microsoft changes.
From what little I’ve read about how Microsoft would close this off, I
think I already know how to get around their changes entirely. I’ve
done this exact thing on VMS before at several layers.

At least with my proposal, people MOSTLY are given the information.
As it is now, the end use has NO idea about hooks and therefore
doesn’t even have a fighting chance, and even if they find out,
removing the offending software can be tricky at best.

As long as it is JUST software, you can’t fully secure it, expecially
if you allow ANY Kernel mode code at all written outside the Operating
System group. Are you proposing that NO device drivers should be able
to be written by people outside Microsoft???

The REAL solution is to go after the “bad” people with REAL law
enforcement and treat what they do as serious crimes. However,
that’s not likely to happen.

Just my humble opinions,

Rick Cadruvi…

11

Rick,

thanks for your reply.

At least with my proposal, people MOSTLY are given the information.
As it is now, the end use has NO idea about hooks and therefore
doesn’t even have a fighting chance, and even if they find out,
removing the offending software can be tricky at best.
Okay. I take that for an argument.
Sometimes it is hard to think like the user would, although I try :wink: … and
the lack of knowledge about hooks is simply something I cannot imagine.

As long as it is JUST software, you can’t fully secure it, expecially
if you allow ANY Kernel mode code at all written outside the Operating
System group. Are you proposing that NO device drivers should be able
to be written by people outside Microsoft???
Nope. That is what I mentioned multiple times (also in the discussion a few
days ago). Kernel mode code is trusted, if it’s trusted you cannot mistrust
it.

Have a nice weekend,

Oliver

–

May the source be with you, stranger :wink:

ICQ: #281645
URL: http://assarbad.net

12

> This would require people to register with Microsoft their solutions.

Microsoft should NOT be the judge as to the ligitimacy of the need,

The situation is rather interesting.

First of all, there is no market-driven demand to keep the OS clean. Yes,
really so.

If some small company will want to do some software deeply based on hooking and
will find the investors to support them with money on startup phase - then
sorry, they will go on, and will never stop due to “hooking is bad” attitude.

So, if we will take only the monetary interests of the 3rd party ISVs, and not
moral ones - then they are pro-hooking. As about “moral ones” - these are
usually the interests of the developers and not the executive management, who
do not thing that hooking is immoral, and often admire the developers who do
hooking - “the real guys! the can go and solve the task!”.

As about “deteritoriating the platform” - they do not care, if their software
will misbehave - people will blame Microsoft :slight_smile:

The mass consumer cannot be anti-hooking due to absolute (usually) lack of
knowledge on how the software is developed, the decisions of
quality-vs-deadline made late in the development cycle, and so on.

So, Microsoft seems to be the only real player on the market who is really
anti-hooking. Windows crashed due to lots of hooking software == Microsoft
being blamed.

Yes, non-IT people often consider the authors of the small software titles to
be professionaly better then Microsoft, and MS is perceived among many of them
as a “huge suffocator and subjugator full of pawns and no Real Men”.

It was amazing but, when XP SP2 broke some software titles, people were blaming
Microsoft. And yes, the vendors of these titles had the betas and had the time
to prepare.

On the other hand: sometimes it is too hard for Microsoft to support the 3rd
party ISV who want to do the product in “kosher” Microsoft-approved ways. Then
the 3rd party has no other choices but hooking.

Most of this “hard to support” from MS’s side is - why not document some stuff?
Why not document PsLookupProcessByProcessId? Why not document most of Ntxxx
syscalls? Why not document the PEB structure, or some other way to get the full
EXE pathname of the process? Why not expose the interface to vendor specific
features of the ACPI EC, so that Asus and others will not use PortIO code to
access the fan speed meter?

People go on and do hooking and other dirty development styles for such things.

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

13

You cannot monitor file IO by hooks, BTW. Paging IO on mapped files will
skip this.

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

----- Original Message -----
From: “Dan Partelly”
To: “Windows File Systems Devs Interest List”
Sent: Friday, November 11, 2005 9:10 PM
Subject: Re: Re:[ntfsd] Re:Hooking and vista

> Your most likely writting security products , me thinks,
> from the description of
>
> " all those tough heros like me write write filter drivers for every little
> >thing in the OS that needs to be monitored, a real mess is guaranteed"
>
> But in generail ,why do you consider filter drivers a “real mess” ?
> You cant handle them ? They happen to be wondefull, and I wish that
> other operating systems adopt the phiosophy.
>
>
> >>Hooking system calls I think has been a fundamental part of operating
> >>systems since the beginning of operating systems.
>
> Who told you this ? I dont think so. Drivers, and API / ABIs s , where
> always part of operating system since beggining. Syscalls
> where not hookable by design. Show me a single 32/64 bit
> operating system which have syscall hooking by design,
> which means it provides APIs for hook/unhook a syscall.
>
>
>
> ----- Original Message -----
> From: “Daniel Terhell”
> Newsgroups: ntfsd
> To: “Windows File Systems Devs Interest List”
> Sent: Friday, November 11, 2005 7:40 PM
> Subject: Re:[ntfsd] Re:Hooking and vista
>
>
> >I admit, not being a theoretician, the suggestion for a registry value is
> >not a reliable solution and not well though over. But the issue is if we
> >let all those tough heros like me write write filter drivers for every
> >little thing in the OS that needs to be monitored, a real mess is
> >guaranteed. Hooking system calls I think has been a fundamental part of
> >operating systems since the beginning of operating systems. The idea that
> >now we have thus far evolved that we have such a safe and compelte
> >operating system that it is no longer needed is an illusion and I think one
> >of the reasons why the development of 64 bit software is not really taking
> >off. Developers will continue to innovate new solutions for which
> >modification of the way the operating system works is unavoidable, and the
> >current situation for Win x64 I consider a deprivation of third-party
> >innovation rather than a security measure .
> >
> > /Daniel
> >
> >
> >
> > “Dan Partelly” wrote in message
> > news:xxxxx@ntfsd…
> >>>> is usually only theoreticians or people writing drivers for hardware
> >>>> devices but never those who write real software solutions to the
> >>>> problems we are facing in this
> >>
> >> Lemme guess. Your one of those tough heros which write “real code” ™.
> >> Congratulations. And you see a reson for hooking everywhere. Because you
> >> are a
> >> hard working coder, and not a teoretician. Despite your position, real
> >> need for hooking
> >> arise in extremly few situations. There are legitimate situations to do
> >> this, but despite
> >> the very poular beleif that are a lot of them, guess what, there are very
> >> few of them.
> >>
> >> I have no ideea what products you write , and maybe you have a legitimate
> >> need for hooking,
> >> but keep in mind that I would incline to call you a diletante and
> >> theoretician, and one which
> >> writes fishy code, then listenig to your self righteous carachterizations
> >> of other ppl.
> >>
> >> Dan
> >>
> >>
> >>
> >>
> >> ----- Original Message -----
> >> From: “Daniel Terhell”
> >> Newsgroups: ntfsd
> >> To: “Windows File Systems Devs Interest List”
> >> Sent: Friday, November 11, 2005 7:06 PM
> >> Subject: Re:[ntfsd] Hooking and vista
> >>
> >>
> >>>I know hooking is not at all the fashion these days but in a thread a few
> >>>days ago, it was you admitting that in certain situations hooking is
> >>>necessary (although evil according to you) . It is usually only
> >>>theoreticians or people writing drivers for hardware devices but never
> >>>those who write real software solutions to the problems we are facing in
> >>>this world coming up with these suggestions. Instead of a boot option, I
> >>>suggest a registry value which is set to allow by default. The
> >>>alternatives that Microsoft has provided such as the registry callbacks
> >>>are even much more operating system dependent and leave a lot to be
> >>>desired for many reasons. What this world really needs is a proper
> >>>interface for intercepting kernel calls and documentation how to do it
> >>>properly. This will resolve all of the possible problems you have managed
> >>>to sum up so far.
> >>>
> >>> Regards,
> >>>
> >>> Daniel Terhell
> >>> Resplendence Software Projects Sp
> >>> xxxxx@resplendence.com
> >>> http://www.resplendence.com
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> “Don Burn” wrote in message news:xxxxx@ntfsd…
> >>>>I have put this out on one of the beta groups for Vista. With our
> >>>>discussions here about hooking, I figured I should repeat it here.
> >>>>Hopefully, people will help push Microsoft to do the right thing.
> >>>>
> >>>>
> >>>> With all the stuff about Sony’s DRM rootkit, it seems like a good time
> >>>> to
> >>>> ask Microsoft to reconsider their stance on no hook protection for
> >>>> 32-bit
> >>>> systems. Yes I realize there are a number of products that hook, but
> >>>> with
> >>>> the capability being blocked on 64-bit system, hopefully these products
> >>>> are
> >>>> changing. Even if they are not, how about making it a boot option,
> >>>> that the
> >>>> customer can disable the hook checks if they have a product that does
> >>>> this.
> >>>>
> >>>> Some of us have been asking for the ability to block hooks for years,
> >>>> it is
> >>>> time for this to be present in all future versions of the OS.
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> —
> >>> Questions? First check the IFS FAQ at
> >>> https://www.osronline.com/article.cfm?id=17
> >>>
> >>> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> >>> To unsubscribe send a blank email to xxxxx@lists.osr.com
> >>
> >>
> >>
> >
> >
> >
> > —
> > Questions? First check the IFS FAQ at
> > https://www.osronline.com/article.cfm?id=17
> >
> > You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> 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

14

Well. It is a point of view, but a false one, IMHO, It depends by
your personal level of paranoia, or real security requirments. Or do
you imply I should trust all shity kernel mode software that
might get instaled on my PC ?

Sony DRM story is a example of drivers which run part of TCB,
but are on the border of malware. There are places in this wrold
where not even MS code is trusted. Ohh no =) Why, do you trust
an OS which leaves so many holes ? Just look at the number of hot fixes
issued by MS.

Dan

----- Original Message -----
From: “Oliver Schneider”
To: “Windows File Systems Devs Interest List”
Sent: Saturday, November 12, 2005 1:53 AM
Subject: Re: [ntfsd] Hooking and vista

> Rick,
>
> thanks for your reply.
>
>> At least with my proposal, people MOSTLY are given the information.
>> As it is now, the end use has NO idea about hooks and therefore
>> doesn’t even have a fighting chance, and even if they find out,
>> removing the offending software can be tricky at best.
> Okay. I take that for an argument.
> Sometimes it is hard to think like the user would, although I try :wink: …
> and
> the lack of knowledge about hooks is simply something I cannot imagine.
>
>> As long as it is JUST software, you can’t fully secure it, expecially
>> if you allow ANY Kernel mode code at all written outside the Operating
>> System group. Are you proposing that NO device drivers should be able
>> to be written by people outside Microsoft???
> Nope. That is what I mentioned multiple times (also in the discussion a
> few
> days ago). Kernel mode code is trusted, if it’s trusted you cannot
> mistrust
> it.
>
> Have a nice weekend,
>
> Oliver
>
> –
> ---------------------------------------------------
> May the source be with you, stranger :wink:
>
> ICQ: #281645
> URL: http://assarbad.net
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to xxxxx@lists.osr.com

15

> able to make a convincing case to him thus far (although I have to say

that losing IrpTracker and other diagnostic tools of this type is a
significant loss.)

If it would be done using a boot.ini option and/or registry switch,
then nothing prevents users of IrpTracker (including me) to
enable hooking on my developing machine. Let developers to allow
hooking and whatever else pervert things with their machines,
but let normal user’s machines protected against it.

However I think that a registry switch will just add setting this switch
on in the tool’s installation program.

L.

16

Why not just make it where hooks could only be used if logged in as an
admin? Sid’s would help in this i think.
Second, don’t let code that hooks run under any other account, it must
run under the currently logged on admin
account. What is wrong with this approach? I think it’s better than
using reg and ini settings that any trojan could
change…

I think a comprimise like this would protect ‘home users’ and at the
same time allow everyone to continue using
their favorite dev tools and toys.

m

Ladislav Zezula wrote:

> able to make a convincing case to him thus far (although I have to say
> that losing IrpTracker and other diagnostic tools of this type is a
> significant loss.)

If it would be done using a boot.ini option and/or registry switch,
then nothing prevents users of IrpTracker (including me) to
enable hooking on my developing machine. Let developers to allow
hooking and whatever else pervert things with their machines,
but let normal user’s machines protected against it.

However I think that a registry switch will just add setting this switch
on in the tool’s installation program.

L.

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

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

17

> Well. It is a point of view, but a false one, IMHO,
I think it’s not a matter of opinion, but a matter of acknowledgement of the
operating system structure. And since installation of TCB code requires
either certain privileges or serious security holes, there is a certain
“trust relationship” (in the first case).
What would we do without brave men such as Mark Russinovich that withstand
all recommendations to not run under administrative accounts? :wink:

It depends by
your personal level of paranoia, or real security requirments. Or do
you imply I should trust all shity kernel mode software that
might get instaled on my PC ?
Well, *I* do not always trust it, but the operating system does - and that’s
all that counts. Certainly it was “me” (my user context, not necessarily me
sitting in front of the screen) who allowed the OS to install the code into
the TCB, no?!
The OS asks you for permission (because of your privileges) to install code.
So yes, you trust every shitty kernel mode software, or you are in trouble.
The principle says you (your user context) trusted it because you (your user
context) installed it, so how can you mistrust it?

Have a nice weekend,

Oliver

–

May the source be with you, stranger :wink:

ICQ: #281645
URL: http://assarbad.net

18

Everything is a matter of opinion and interpretation , excepting math
and a part of physics :stuck_out_tongue:

> What would we do without brave men such as Mark Russinovich that
> withstand

I would do just well. How about you ?

> The principle says you (your user context) trusted it because you (your
> user
> context) installed it, so how can you mistrust it?

You cant trust anything nowdays, unless you have the source code and pay
thousands of US$ for intensive auditing. Im not necesarely talking about
mallware
, but bugs.

I start with a simplier approach then yours Oliver. I dont even trust the OS
itself. Its a known fact , almost every OS out there has serious security
flaws.
You whole logic is flawed , because you start by trusting your so called
TCB.
TCB is a concept which looks good on paper , but does not work in real world
too well, because of the contless flaws and bugs in the OS. You are arguing
on completly thorethical asspects of OS theory, but all this theory have
very little
value for me in the real world where you are at risk of mallware and
spyware,
and corruption of critical OS components every day.

----- Original Message -----
From: “Oliver Schneider”
To: “Windows File Systems Devs Interest List”
Sent: Saturday, November 12, 2005 1:46 PM
Subject: Re: [ntfsd] Hooking and vista

>
>> Well. It is a point of view, but a false one, IMHO,
> I think it’s not a matter of opinion, but a matter of acknowledgement of
> the
> operating system structure. And since installation of TCB code requires
> either certain privileges or serious security holes, there is a certain
> “trust relationship” (in the first case).
> What would we do without brave men such as Mark Russinovich that withstand
> all recommendations to not run under administrative accounts? :wink:
>
>> It depends by
>> your personal level of paranoia, or real security requirments. Or do
>> you imply I should trust all shity kernel mode software that
>> might get instaled on my PC ?
> Well, I do not always trust it, but the operating system does - and
> that’s
> all that counts. Certainly it was “me” (my user context, not necessarily
> me
> sitting in front of the screen) who allowed the OS to install the code
> into
> the TCB, no?!
> The OS asks you for permission (because of your privileges) to install
> code.
> So yes, you trust every shitty kernel mode software, or you are in
> trouble.
> The principle says you (your user context) trusted it because you (your
> user
> context) installed it, so how can you mistrust it?
>
> Have a nice weekend,
>
> Oliver
>
> –
> ---------------------------------------------------
> May the source be with you, stranger :wink:
>
> ICQ: #281645
> URL: http://assarbad.net
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to xxxxx@lists.osr.com

19

Some of what they do in the x64 world can’t easily be reproduced in the
x86 world - notice those convenient 32-bit relative offsets? They’ve
put all the system calls into a region of memory that you can’t allocate
(of course, you could play games with page tables, but that raises the
bar again…) One advantage of having a HUGE address space (256TB
total) is that burning 4GB of it isn’t such a big deal.

Note that this isn’t the ONLY thing going on to prevent hooking (and
code patching) but it certainly is one more obstacle in the way that
can’t be easily reproduced.

I also like the fact that the OS doesn’t “fix” it when the system is
patched, it just bugchecks. Thus, the cost of doing it wrong, or
finding out that a new security patch changes the algorithm is that your
code will blue screen the system. Brutal feedback, but it discourages
anyone from code patching.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Friday, November 11, 2005 2:57 PM
To: ntfsd redirect
Subject: Re:[ntfsd] Re:Hooking and vista

“Daniel Terhell” wrote in message
news:xxxxx@ntfsd…
> Hooking system calls I think has been a fundamental part of operating
> systems since the beginning of operating systems.

I’ve only been around the OS world for 35 years, most of that time
hooking
was considered an extremely bad thing. A minicomputer company I worked
for
had that in their license that you would not hook, and sued out of
existance
a software firm that did.

Yes I said there are rare occasions when you need to hook, but they are
a
lot rarer than most people think, and most of them are for things like
IrpTracker. For a commercial product having to hook normally means you
did
a lousy design.

Note: I am not proposing anything new, just apply the hook checks that
Microsoft is doing when you go to 64-bit to the 32-bit world. I don’t
want
a registry setting it is too easy to override, just like the /noexecute
switch which can also break things this ought to be a command line
option.

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

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

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

20

On Nov 11, 2005, at 10:21 AM, Don Burn wrote:

With all the stuff about Sony’s DRM rootkit, it seems like a good
time to
ask Microsoft to reconsider their stance on no hook protection for
32-bit
systems. Yes I realize there are a number of products that hook,
but with
the capability being blocked on 64-bit system, hopefully these
products are
changing. Even if they are not, how about making it a boot option,
that the
customer can disable the hook checks if they have a product that
does this.

They took a similar approach with hardware-based DEP, adding an opt-
in/opt-out model to boot.ini and module loading. Would seem to make
sense here as well.

Steve Dispensa
MVP - Windows DDK
www.kernelmustard.com