Standard Windows dialog installs global mouse hooks

I've just noticed an odd little nit in both PG v3.0 (final) and PG v3.05 (using Win2000-sp4). When a program invokes a standard Windows file-handling dialog (open or save), the Windows dialog may attempt to create a global mouse hook. This happens when you start entering a filename and the first character matches one of the dialog's auto-completion suggestions. To see an example, make sure that ProcessGuard does not authorize global hooks for Notepad (or that it's completely unprotected). Now, start Notepad and select File->Open. With your cursor in the (empty) "File name" field of the dialog, type the first letter of any name that appears in the list above the cursor (a filename or a directory). After typing one character, the drop-down list of "names that match so far" should appear. Simultaneously, PG pops up a balloon saying, "notepad.exe was blocked from creating a global mouse hook". What really happened is that the code in the "open file dialog" tried to create a global mouse hook. Since the dialog is considered a standard part of Windows, most applications with user selectable files could be cited for trying to create a global mouse hook.

The good news is that the file-handling dialogs work (more or less) correctly without installing a global mouse hook. The bad news is that some users may become accustomed to enabling global hooks without much thought. For those who don't become enablers, there's a danger that some of PG's popup balloons could become a routine annoyance. Tired of clicking on false-positive alerts, you start to ignore the RED PG-icon for brief periods. You look away for a few seconds, and that's when a second balloon pops up. The RED icon is unchanged and an ominous warning may have just slipped by unnoticed.

A more personal annoyance with this nit is a result of auto-hiding my taskbar. For instance, when Notepad's open file dialog triggers a PG balloon and the taskbar devours the western quarter of my screen, it usually hides the new filename I've just started typing. Now I must either feign composure and try to finish typing the invisible filename, or instead, grab the mouse, click the balloon, click the PG icon back to blue, <ALT-TAB> back to the dialog, then mentally prepare, because my next keystroke could restart the cycle.

If it's possible for PG to reliably identify these "dialog alerts", then perhaps they can be handled in a more transparent way. If they cannot be distinguished from "an application's own hook requests", then this may be additional reason to consider providing separate options for each specific type of hook a program could install. In the long run, fine grained control may be a good idea, anyway.

These "dialog alerts" aren't a huge issue, but I don't want anything to start eroding the sense of stability and security that ProcessGuard should inspire in all its users..

 

Hi,

You haven't used learning mode enough ! If you are getting a block when using a trusted program, just enable learning mode. Do whatever you did again, and PG will allow it, learning from it. Couldn't be much simpler, problem solved in a few seconds ?

 

Some granularity involving hooks might be worthwhile, because for a mouse hook DLL to get injected you basically need to perform mouse operations over each program. I can't really see malicious software wanting to do things this way as it isn't reliable at all.

However I don't really find the standard Save As/Open dialog "blocks" as that annoying.

 

Gavin,
If I use learning mode to anticipate and automatically allow this behavior, isn't that effectively the same as if I manually authorized the program to install global hooks. My main reservation is that I don't want every program that uses a file dialog to be able to install keyboard hooks, debugging hooks or whatever else it wants. If that would not be the same thing, could you please summarize the difference between what learning mode would allow and what would happen if I authorized global hooks.

My secondary reservation was about unfortunate user tendencies that might be promoted. Thirdly, I expected only very minimal sympathy for the way my taskbar configuration complicates the pointing and clicking of my days.. I think Jason confirmed that expectation.

Jason,
I agree it's not a huge issue, but hoped there might be a reasonably simple way to deal with this "small problem in a thousand places" at a much higher level of abstraction.. Don't worry, if it isn't fixable, it's certainly no deal-breaker for me.

Keep up the great work.

 

Jason,
I would certainly appreciate finer granularity over hooks, as earth1 says we might allow a mouse hook but why would we then want to open ourselves up to keyboard hooks.

I'm sure I've made this request in the improvements thread already... how about some feedback on some of the suggestions that the various people have made. Nobody with any sense is going to ask you for timeframes it would just be good to get an idea of your opinions of what is being suggested

Thanks

 

[bump] I just got hit with this myself. Not sure how I didn't notice it before... but I consider it a fairly major annoyance. Since a large percentage of the apps I run will need to throw up an Open/Save dialog, I find the current solutions unacceptable (as I understand them):

1) solution #1: be in learning mode
well obviously this is OK in the beginning but most of us left learning mode a long time ago since it is not a secure mode to be in.

2) solution #2: authorize each and every app that needs it to install the hook
again this is annoying for anyone who has several hundred programs on their computer, and I guess why even have the option to block the hooks if nearly every app is going to need access to them?

3) solution #3: turn off the "block global hooks" option on the Main tab
well this is the solution I have chosen, for now. It is insecure and defeats one of the best features of PG3, but until a granular solution is available I'm afraid it's the best tradeoff between safety and too much time spent interacting with PG. I will just do more frequent trojan scans with TDS to make sure I have no keyloggers on my system

Hopefully this situation can be made better by the brilliant DCS team...

 

Hi LuckMan212,

True

Why would you want 100s of programs on your protection list?
I only add programs that access the internet, security programs anf the basic system files.

Your chouce of course, but as far as I can see this is only a problem if you have a large protected list.
I let Execution protection ie. the security list look after all the other programs. This way you do not have to worry about setting unnecessary allows on many low risk programs.

I personally would not switch off a General block that can stop malware before looking very carefully at what I really want to protect and what the "real" risks are

I get very few alerts for global hooks most of which I ignore with not detrimental effects so far.

Still I suppose everyone has a different approach as to how they wish to utilise a powerful program like ProcessGuard.

I am also sure that DCS is listening and maybe furure builds will allow those that feel they need it the granuality they desire.

Pilli

 

Pilli thanks for the reply, and I totally agree with everything you said. I do not want 100s of programs on my protected list, in fact I keep it trimmed as much as possible.

the problem is that many apps seem to require this global mouse hook for their open/save dialogs (as stated by earth1 in the first post of the thread). So you either have to allow these apps individually to have the hook, via the protection tab, or turn off the blocking of global hooks altogether. Neither of these is ideal.

What we really need is on the "main" tab, to split the "allow global hooks" into 2 separate options:

[ ] Allow Global Mouse Hooks
[ ] Allow Global Keyboard Hooks

that would solve this issue easily, I think. As Jason has said, allowing the global mouse hooks is a very low security risk. However the keyboard hook is not something you want to give out unless you really trust a program and know it to be clean.

does this help clarify?

 

Yep, Thanks LuckMan

Pilli

 

good, now we wait for Jason's comments...

 

I think Microsoft is now up to 15 different kinds of hooks, and arguably, a keyboard hook is not even the most dangerous kind. Perhaps some hooks can be grouped, combined into a catchall, or ignored. Some may be fairly innocuous, but quite a few seem potentially serious.

I'm not a security expert or a Windows expert, but as a purely hypothetical example I'd provide checkboxes under "Authorized Hooks" by category as follows:
-- Debug -- Keyboard -- WndProc -- MsgFilter -- Shell -- Other
I would be inclined to relegate mouse hooks to "Other". Perhaps WndProc and MsgFilter should be combined, perhaps shell is not dangerous, perhaps something else is more dangerous. Just an idea about how to try to group hooks.

One thought for handling all of these possibilities is to.allow (global) Learning Mode as it exists now, but to add the abliity to apply a "local" Learning Mode to an individual program from the Protection-tab. Along with the per-program protection data currently displayed, would be a "Program Learning Mode" checkbox, and a group of "Authorized Hooks" checkboxes (the examples above). This would allow the ProcessGuard to capture the necessary hooks that a "trusted" program wants to set, without risking any unnoticed side-effects from putting the whole system into learining mode. It also allows the user to verify or reconsider these specific settings at any time.

On the Main tab, near the existing "Learning Mode" could be a new button to "Clear Learning Mode for all programs".

Unfortunately, unless you have the source code, you can never be 100% sure that a prgram should be trusted. This kind of approach allows much greater flexibility to extend a reasonable amount of trust, without having to worry whether a program may someday abuse its overly broad mandate.

Since ProcessGuard is quickly becoming known as the gold standard for security, it may be time to anticipate that malware will start focusing on how best to thwart it. To me, this seems like a definite step out of harm's way.

 

Hmm... earth I like your ideas a lot, I didn't even think about all the other types of hooks that exist. Sounds like it would be a lot to manage but the flexibility would surely be welcomed by most PG users -- who are most likely "advanced" users anyway. I wonder how much "under the hood" work would have to be done on the PG engine in order to implement this type of control. If it is a significant rewrite then it probably won't appear until PG 4.0 but I guess we can cross our fingers and hope.... I think there are some valid points in this thread indeed.

 

I would love to hear Jason's comments on the above issue....

 

Sorry for jumping in.
On my win2k/xp box with PG3/PG3.05, I have seen some sort of such relates to windows-file-browsing dialog. When tried adding a program to the protection list, when typed in the first letter in to filename field, PG GUI terminated and gone; it persisted until a reboot.
Hope to have some help on this. Thx.

 

Hi newborni,

Does procguard.exe have permission to "Install Global Hooks" in your Protection List under "Other options...". If I disable permission, the PG GUI will also terminate when I try to add an application. I believe procguard.exe is given "Install Global Hooks" permission by default in learning mode.

Nick

 

Yes. I keep default settings for PG programs as they are. I am not sure what caused this and not kept track of the situations when it occured.
thx all.

 

Hi newbornii, Interesting problem, if it happens agian, please keep an eye on it and report back what actions caused the problem and if it is repeatable.

Thanks. Pilli

 

Hi Peter... yes, you are missing something. The problem is, EVERY program needs "install global hooks" if, at any time it pops up a standard windows file open/save dialog. You can see this for yourself by opening notepad.exe, type a few characters, and then go to save it. While the dialog is open, navigate to a directory with some other text files in it, and then begin typing a name in the "file name" box that matches an already-existing file. (just the first couple of letters). Wait a second or so, and you will get a PG alert that notepad tried to install global hooks.

You can reproduce this in any app. So therefore the global hooks option is essentially useless unless you feel like giving that permission to EVERY single app on your hard drive, which: (A) defeats the purpose of having it, mostly and (B) is a large hassle to do, even in learning mode.

That's my take on it. So for now I have disabled the global hooks protection -- but that's not an ideal or hopefully a permanent solution. I hope DCS will provide a workaround to this either by distinguishing between the different types of hooks as suggested by earth1 above or some other ingenious trickery.

 

Personally, I disallow anything to install global hooks unless I see some actual functionality loss or whatever's asking just plain don't work without this option enabled.

In the case of installing global mouse hooks on a file>save standard dialog I can certainly ignore it for now.

It would be nice as earth1 suggested to be able to have some sort of sub listing of the most common and generically harmless global hook options to assign for each app or at a global level. Global mouse hooks seems to be pretty harmless.

 

Hi Peter,

I'm concerned not only with what I understand of the threat we face now, but also by the rate at which that threat grows. Thousands (millions?) of talented people are trying to steal our computers and even our own identities. It has become very profitable, so their methods improve every day. I think we've only seen the tip of the iceberg. Microsoft, in turn, refuses to address security in any meaningful way because that might calm our panic and make it harder to stampede us into the Longhorn corral. In the current climate of declining business ethics and diminished respect for privacy, I'm very concerned about enabling keyloggers, abuse of "debugging hooks" and all other security issues. It feels foolhardy to trust any program more than I absolutely have to.

A geeky list of "Hook Authorizations" may sound like power toys for paranoids, but I believe they can benefit everyone. "Learning Mode" would remain as easy as ever, but would authorize only what is truly necessary. "Program Level Learning Mode" would allow the ongoing ability to let "LM" do automated fine-tuning for one or more programs without incurring the gigantic risk of repeatedly throwing the entire system back into "Global Learning Mode".

As DCS starts compiling a database of "application configuration opinion/consensus" for PG, the more precise and detailed a reference that emerges, the more valuable it will be. I think we all know it's just a matter of time before the next "previously unimaginable threat" catches everyone by surprise. When day-zero arrives, a fully hardened ProcessGuard might make all the difference.

Best Regards to all,
Mike

PS: Peter, I think Windows has a setting that disables auto-completion suggestions for all programs in all dialogs, but I don't know where it is. Perhaps your system has blocked that feature everywhere.

 

The easy way to turn off autocomplete is by using Tweak UI. It can also be turned off manually by changing the value "AutoComplete In File Dialog" to 0 here:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\AutoComplete

Either way, disabling autocomplete stops the PG alerts. (note if the "AutoComplete In File Dialog" value is not there, you will have to create it).

Nick

 

Thanks Nick, turning off auto-completion is a welcome improvement.

On another note, I earlier proposed folding mouse hooks into an "other hooks" category of granular hook authorizations. Upon reflection, it might be helpful to have a separate category for mouse hooks because it is used so often. Perhaps mouse hooks (only) should be enabled by default.