Prev: Help with CHTMLView and Session
Next: leak using Clipboard in Unicode with richedit
From: Daniel James on 11 Dec 2006 05:50
In article news:<seson21ntvhv7pi2gn2l811sv3it8felod(a)4ax.com>, Joseph M.
Newcomer wrote:
> I am reasonably convinced that Microsoft is totally clueless with respect
> to hooks and security.

I'd say that was about right, yes.

> The pre-Vista security was a joke,

There was so little of it that I was unable to find the punch-line!

> ... and the key APIs needed, such as EnumerateHooks (I once wrote a
> specification and sent it to the hook group), to allow security audits,
> were omitted "by design". Why shouldn't I be able to discover which
> processes have set system-wide hooks, or for that matter, all hooks?

An administration tool -- especially a security administration tool --
should certainly be able to do that. I agree.

Cheers,
Daniel.


From: David Ching on 11 Dec 2006 14:11
"Daniel James" <wastebasket(a)nospam.aaisp.org> wrote in message
news:VA.00000fc9.58aec01d(a)nospam.aaisp.org...
> My point was that there is a "Gotcha" here, because a lot of apps that use
> the journal hooks don't actually look at keystrokes to/from other apps --
> they only want to log their own input. Maintainers of these apps may not
> expect their macro facility to be broken by UAC, and will be in for a
> nasty
> surprise.
>

I haven't used a journal hook; it sounds like there is no local hook
available for this one, as there is for, say a keyboard hook which can be
installed locally (in one process) or systemwide.

Best of luck resolving this issue.

Thanks,
David

From: Daniel James on 12 Dec 2006 06:29
In article news:<762474EA-432F-45DF-9F98-278E6CD74BE2(a)microsoft.com>, David
Ching wrote:
> I haven't used a journal hook; it sounds like there is no local hook
> available for this one, as there is for, say a keyboard hook which can be
> installed locally (in one process) or systemwide.

One of the possible workarounds is to replace the WH_JOURNALRECORD hook with
a local keyboard hook ... but the beauty of the WH_JOURNALRECORD hook for a
macro recorder is that there is a matching WH_JOURNALPLAYBACK hook for
playing such a macro back. If we were to switch to using a WH_KEYBOARD hook
we would have to write all the code to simulate keyboard input for playback,
as well as having to interpret scancodes (and probably distinguish between
different keyboard layouts) ourselves.

It's a lot of work. I really don't think MS thought about what they were
doing when they decided how to apply to UAC to hooking.

Cheers,
Daniel.



From: Alexander Grigoriev on 12 Dec 2006 11:51
Systemwide (desktop-wide actually) hooks can only be set to processes to
which the hooking process have PROCESS_MEMORY_WRITE access. Thus, it cannot
be set to a process running with different credentials. So the security is
not breached by hooks.

"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
news:seson21ntvhv7pi2gn2l811sv3it8felod(a)4ax.com...
>I am reasonably convinced that Microsoft is totally clueless with respect
>to hooks and
> security. The pre-Vista security was a joke, and the key APIs needed,
> such as
> EnumerateHooks (I once wrote a specification and sent it to the hook
> group), to allow
> security audits, were omitted "by design". Why shouldn't I be able to
> discover which
> processes have set system-wide hooks, or for that matter, all hooks?
> joe
>
> On Sun, 10 Dec 2006 13:27:44 GMT, Daniel James
> <wastebasket(a)nospam.aaisp.org> wrote:
>
>>In article news:<eBAeh.242$yC5.98(a)newssvr27.news.prodigy.net>, David Ching
>>wrote:
>>> I was told at PDC 2003 (way early, I know) that SetWindowsHookEx would
>>> continue to work as long as the app doing the hooking had at least as
>>> much priviledge as the app being hooked.
>>
>>So it does for many hook types, AIUI, but the WH_JOURNALXXX hooks are
>>essentially system-wide hooks -- they don't just hook the current app,
>>they
>>hook everything -- so unless they are running at as high a privilege as
>>anything in the system they have to have a special privilege.
>>
>>My point was that there is a "Gotcha" here, because a lot of apps that use
>>the journal hooks don't actually look at keystrokes to/from other apps --
>>they only want to log their own input. Maintainers of these apps may not
>>expect their macro facility to be broken by UAC, and will be in for a
>>nasty
>>surprise.
>>
>>To implement an appropriate degree of security, here, UAC doesn't have to
>>block the SetWindowsHook call, it could just filter the hook callbacks so
>>that the app only saw its own keystrokes unless it had special permission
>>to see them all. IOW: MS *could* have made UAC less intrusive, here, than
>>they have.
>>
>><irony>
>>Thanks a bunch, guys.
>></irony>
>>
>>Cheers,
>> Daniel.
>>
> Joseph M. Newcomer [MVP]
> email: newcomer(a)flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm


From: Alexander Grigoriev on 12 Dec 2006 11:52
Well, if you don't run as Admin in XP, Vista is no better really in
security.

"Daniel James" <wastebasket(a)nospam.aaisp.org> wrote in message
news:VA.00000fcc.5d44b919(a)nospam.aaisp.org...
> In article news:<seson21ntvhv7pi2gn2l811sv3it8felod(a)4ax.com>, Joseph M.
> Newcomer wrote:
>> I am reasonably convinced that Microsoft is totally clueless with respect
>> to hooks and security.
>
> I'd say that was about right, yes.
>
>> The pre-Vista security was a joke,
>
> There was so little of it that I was unable to find the punch-line!
>
>> ... and the key APIs needed, such as EnumerateHooks (I once wrote a
>> specification and sent it to the hook group), to allow security audits,
>> were omitted "by design". Why shouldn't I be able to discover which
>> processes have set system-wide hooks, or for that matter, all hooks?
>
> An administration tool -- especially a security administration tool --
> should certainly be able to do that. I agree.
>
> Cheers,
> Daniel.
>
>


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Help with CHTMLView and Session
Next: leak using Clipboard in Unicode with richedit