Just tweaking you… I don’t actually find it surprising that at least
one company out there has invested the 100 man-years needed to do this
safely :-).
Moreira, Alberto wrote:
Actually we solved that problem too. All it takes is to add entries to a
table, and rebuild the system. It took some time for us to get there, but
most of that kind of updating is now as close to automatic as one can get.Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Ray Trent
Sent: Tuesday, June 15, 2004 3:57 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Notify when system time changesWell, until a service pack comes out :-).
Moreira, Alberto wrote:
>Yet we have used hooking extensively for all of our tools, and they work
>fine.
>
>Alberto.
>
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com]On Behalf Of Peter Wieland
>Sent: Tuesday, June 15, 2004 2:37 PM
>To: Windows System Software Devs Interest List
>Subject: RE: [ntdev] Notify when system time changes
>
>
>There’s an additional problem with hooks that we don’t talk about as
>much, and that has to do with extending an API.
>
>Say, for example, that you wanted to catch every read and write an
>applications perform. So you hook NtCreateFile (so you can figure out
>which handles are to files, NtReadFile and NtWriteFile (we’ll ignore the
>problem of memory-mapped I/O for now) and NtClose (so you can cleanup
>when the handle is closed). You’re now able to see every read & write
>and you’re happy.
>
>What happens to your scheme when we extend the IO NT APIs in the next
>release (or service pack - we do sometimes enable new features there),
>and provide something like Nt[Read|Write]FileScatterGather? Now there’s
>a read/write path that you aren’t hooking. If you were just doing
>logging that may be okay, but if you decided to provide data encryption
>with a sys-call hooker then your customers are now screwed until you can
>get an update together. Whereas if you were filtering above the file
>system you would have seen a READ irp come through and could have
>processed it.
>
>In order to enable filtering, it has to be done at a point in the system
>which will remain relatively stable over time. The IRP interface to
>drivers is one such interface, in contrast with the NT or Win32 APIs
>which tend to grow over time. The other reliable alternative is to
>provide callbacks where we can to notify some third-party component of
>changes in the kernel’s internal state - things like the process
>creation callbacks. We can then make sure that we invoke the callbacks
>where appropriate in the new system calls (or the code they call).
>
>I doubt this is a windows only thing, but it’s been a long time since
>I’ve looked at the source for any other OS so couldn’t really tell you
>today. I don’t see hooking an evolving API as a stable long-term
>solution to a problem.
>
>-p
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of Ray Trent
>Sent: Tuesday, June 15, 2004 11:12 AM
>To: Windows System Software Devs Interest List
>Subject: Re:[ntdev] Notify when system time changes
>
>The only way to solve problems like this is with hardware support, which
>is where NGSCB comes in.
>
>The problem with your scheme is that any facility that you have access
>to is also accessible by the hackers. So you end up in an arms race that
>reduces overall stability without providing any benefit.
>
>For example, if you install some hook that allows finding out whether
>there is a keyboard hook installed, what prevents someone from hooking
>after your hook? Aha, you say, I’ll just check at run time. What
>prevents them from hooking the function you use to check for hooks and
>not reporting themselves as being present?
>
>You can chase this down forever, but the fundamental problem is that the
>hacker only has to break existing detection schemes, which they can
>analyze at their leisure, whereas you have to somehow anticipate all
>possible hacks. It’s not a solvable problem unless you have true
>hardware support with software attestation done in the hardware and true
>process isolation.
>
>The more fundamental problem with system hooks is hook conflicts. Even
>if MS documents all that they do, they can’t possibly document
>everything that every hook out there might do, and so it’s impossible to
>have a stable interface by definition. This is why people say it’s only
>acceptable for a non-commercial environment. If you have complete
>control over all the hooks installed, you can ensure/test for their
>compatibility. If it’s a commercial product, there’s no way to do this.
>
>People that want system hooking typically are only thinking short term,
>and only of themselves/their application. I don’t see any reason to
>encourage them.
>
>Daniel Terhell wrote:
>
>
>
>>Thanks, I really should not have missed that one. However I think
>>there is still a long way to go before they really can say there is no
>
>
>>more need for system call hooking and scrap it. I really hope they do
>
>
>>it in the far future after AMD64 support and LongHorn.
>>
>>For example I think it should be possible to trap if applications are
>>setting user mode hooks. There is something like a WH_DEBUG hook to
>>monitor other hooks but it does not see the low level ones. I would
>>like to create an application for internet cafes that can guarantee
>>the visitors that no keyboard loggers are installed in any way. I can
>>check what devices are attached to the keyboard device but in order to
>
>
>>detect the user mode hooks I need to use the load image notify routine
>
>
>>to see what DLLs get injected in what processes which is very messy.
>>I think there should come a callback for when DLLs are injected into
>>running processes as well as one for user mode hooks. My best ideas so
>
>
>>far are hooking ZwLockVirtualMemory, ZwProtectVirtualMemory,
>
>ZwWriteVirtualMemory and ZwFlushInstructionCache.
>
>
>>For the low level hook functions, they do not inject anything but all
>>call some undocumented system call function with a high number which
>>is not exported by NTDLL.
>>
>>I would very much like to create a list of callbacks which would make
>>it possible to develop applications which are currently impossible to
>>write or without the need of undocumented funtions. Do you think it’s
>>a good idea to post them here or should I use the DDK feedback ?
>>
>>Regards, Daniel
>>
>>
>>
>>
>>“Don Burn” wrote in message news:xxxxx@ntdev…
>>>
>>>
>>>
>>>>Actually they do and it is documented, read the DDK on
>>>>ExCreateCallback
>>>
>>>and
>>>
>>>
>>>
>>>>in particular about “\Callback\SetSystemTime” which does what you
>>
>>want.
>>
>>
>>>>This has been available since Windows 2000, so you should have been
>>>>able
>>>
>>>to
>>>
>>>
>>>
>>>>find it.
>>>>
>>>>As far as system call hooking being a fundemental principle, I know a
>>>
>>>number
>>>
>>>
>>>
>>>>of systems that detected this and took action with a vengenance. At
>>>>least one minicomputer company disabled the product, then logged the
>>>>data on the product, their system support people would get the log,
>>>>and send a letter
>>>
>>>to
>>>
>>>
>>>
>>>>all customers saying you thirty days to remove all products from that
>>>>firm or have your warranty voided!
>>>>
>>>>Microsoft is providing mechanisms for ones they see needs for, and yes
>>>
>>>they
>>>
>>>
>>>
>>>>are sympathethic to requests for additional ones, so if you have more
>>>
>>>needs
>>>
>>>
>>>
>>>>tell them.
>>>>
>>>>
>>>>–
>>>>Don Burn (MVP, Windows DDK)
>>>>Windows 2k/XP/2k3 Filesystem and Driver Consulting
>>>>
>>>
>>>
>>>
>>>
>>–
>>…/ray..
>>
>>Please remove “.spamblock” from my email address if you need to contact
>>me outside the newsgroup.
>>
>>—
>>Questions? First check the Kernel Driver FAQ at
>>http://www.osronline.com/article.cfm?id=256
>>
>>You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
>>To unsubscribe send a blank email to xxxxx@lists.osr.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@compuware.com
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>>The contents of this e-mail are intended for the named addressee only. It
>>contains information that may be confidential. Unless you are the named
>>addressee or an authorized designee, you may not copy or use it, or
>
> disclose
>
>>it to anyone else. If you received it in error please notify us
>
> immediately
>
>>and then destroy it.
>>
>>
>
>
–
…/ray..
Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.