View Full Version : Standard Windows dialog installs global mouse hooks
earth1
November 16th, 2004, 03:26 AM
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..
Gavin - DiamondCS
November 16th, 2004, 04:16 AM
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 ?
Jason_DiamondCS
November 16th, 2004, 04:31 AM
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.
earth1
November 16th, 2004, 05:00 AM
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.
gottadoit
November 16th, 2004, 11:25 AM
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
LuckMan212
November 22nd, 2004, 09:21 AM
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) [B]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...
Pilli
November 22nd, 2004, 10:01 AM
Hi LuckMan212, -{ Quote: "1) solution #1: be in learning mode" }-
-{ Quote: "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" }-
True
-{ Quote: "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?" }- 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.
-{ Quote: "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" }- 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
LuckMan212
November 22nd, 2004, 11:03 AM
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?
Pilli
November 22nd, 2004, 11:54 AM
Yep, Thanks LuckMan ;D
Pilli
LuckMan212
November 22nd, 2004, 01:04 PM
good, now we wait for Jason's comments... ;D
earth1
November 22nd, 2004, 09:52 PM
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.
LuckMan212
November 22nd, 2004, 10:24 PM
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.
LuckMan212
December 4th, 2004, 06:50 PM
I would love to hear Jason's comments on the above issue.... ::)
Peter2150
December 4th, 2004, 08:48 PM
Maybe I am missing something, but I am not sure this global hook thing is that big a deal. I have a fairly large number of apps that I run also. I trust each and everyone of them or they wouldn't be on my computer.
I don't care if they need hooks or whatever. If I allow them to do whatever they want, all I am doing is allowing what they already were doing before I ever heard of ProcessGuard.
What I want ProcessGuard for is that sneaky program that gets by me and onto my computer and then tries something nasty with hooks or whatever. That is what I want ProcessGuard for. Am I missing something??
newborni
December 4th, 2004, 09:12 PM
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.
nick s
December 4th, 2004, 09:36 PM
-{ Quote: "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
newbornii
December 4th, 2004, 11:04 PM
-{ Quote: "
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.
Pilli
December 5th, 2004, 05:17 AM
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
LuckMan212
December 5th, 2004, 09:03 AM
-{ Quote: "Maybe I am missing something, but I am not sure this global hook thing is that big a deal. [snip] Am I missing something??" }-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. :)
rickontheweb
December 5th, 2004, 01:10 PM
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.
Peter2150
December 5th, 2004, 01:35 PM
-{ Quote: "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. :)" }-
I tried duplicating what you said as best I can understand it, and I don't see anything like you are talking about. Note very few of my apps including notepad have permission to install GLobal hooks.
Just out of curiousity do you have global hooks allowed on explorer.exe. That is a diamondCS default, and I wonder if turned off it could cause what you are seeing.
Pete
earth1
December 5th, 2004, 03:28 PM
-{ Quote: "Maybe I am missing something, but I am not sure this global hook thing is that big a deal. I have a fairly large number of apps that I run also. I trust each and everyone of them or they wouldn't be on my computer.
I don't care if they need hooks or whatever. If I allow them to do whatever they want, all I am doing is allowing what they already were doing before I ever heard of ProcessGuard." }-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.
Peter2150
December 5th, 2004, 04:03 PM
Hi Mike
I don't remember where auto completetion stuff is but I know when ever I come across it I turn it off.
I totally share your concerns about future security. That is exactly why I ended up getting involved with DCS and beta testing. I do take a layered approach. I am totally confident that my machine is now clean. I trust all the software currently on my computer, so what I want to protect against is the unknown. That PG will do in it's current state, even if I let everything have default settings. That does however tie in with my approach to software. When I get an upgrade CD from Intuit's Quickbooks, I don't think twice, I just install it. But if I am not 100% sure, even with upgrades, I go into a secondary snapshot using FD-ISR and study it's effect. This way even if my security software is off it can't hurt me.
Pete
nick s
December 5th, 2004, 04:18 PM
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
earth1
December 5th, 2004, 08:09 PM
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.
LuckMan212
December 5th, 2004, 08:27 PM
While disabling the AutoComplete does seem to address part of the issue, you can still see this problem manifest itself by right-clicking on your desktop and selecting "New --> Shortcut" and then in the subsequent dialog box, begin typing. If there are any previous history entries in there, you will get a dropdown and at that point an alert from PG saying that rundll32.exe tried to install a global hook. :'( So even with AutoComplete disabled this still rears its head in various places.
Still waiting for Jason's thoughts on the latest postings in this thread since his Nov 16th reply. ::)
Jason_DiamondCS
December 5th, 2004, 10:10 PM
Allowing *ANY* hook by "default" will allow malware authors to inject their code on the system, so it isn't something you really want to be doing for untrusted programs. In a way I can see the usefulness of having options for the allow hooks for a program, so for the next version I will see if it is feasible to add it without adding a whole lot of complexity to the program.
However I wouldn't feel like ProcessGuard is useless in its current state against Global Hooks even if every legit application did them, it protects you fully from any possible attacks. For instance if you have global hook protection disabled and something runs it can inject into nearly every process on the system, hence nullifying all the other protection in place. I don't see why you would want this even if all your legit applications did have "allow global hook", the above attack would be blocked (if you have BLOCK GLOBAL HOOKS enabled aswell). In regards to the standard open/save as dialog, you can ignore the request without any ill effects, or even disable auto complete as some people have suggested.
LuckMan212
December 5th, 2004, 10:46 PM
Hi Jason thanks for poking your head in :) the problem is not that PG in ineffective in its current state, I think what earth1, rick and others (including myself) are saying is that the way it is set up, it is either very tedious to set up properly (i.e, having to add "allow global hooks" to every program on your protection list -- which causes the protection list to be immense and unnecessarily long or perhaps forces you to give hooks to a program that you really dont want to) or encourages the user to disable features that might leave their system in an unprotected state (i.e disabling block global hooks or suppressing the balloon alerts etc). YES I can enable learning mode and then proceed to launch each and every program on my hard drive and then attempt to get that program to pop up an open/save dialog and then PG will learn, but in the end that would take days, or weeks of time and would leave a huge mess in the PG config GUI. and YES AutoComplete can be disabled but as I mentioned 2 posts up that does not solve the problem in all cases...
I understand that adding features is annoying and hard work -- I am a db programmer myself and I hate when users ask for stupid features that I dont see the value of. But in the end I have to remember that when programming I am trying to find that "middle ground" that keeps users happy but also keeps my software from becoming overly bloated and too specialized for specific groups of users. Sometimes we dont see eye to eye but in the end they are using the software more than I do so usually after going through some revisions eventually the final result is a better piece of software -- even if initially I thought it was a bad idea. So I understand if you feel this feature would not be useful to you, but I believe that it would benefit your users, as evidenced by others comments and other threads in the PG forum.
so anyway I guess enough has been said about this but I sincerely hope that this granular control or some other solution makes it into the next major revision as I believe it would be a huge improvement.
earth1
December 6th, 2004, 02:57 AM
-{ Quote: "Allowing *ANY* hook by "default" will allow malware authors to inject their code on the system, so it isn't something you really want to be doing for untrusted programs." }- That's very good information to know. My mental image of injection was more related to memory/code modification.
-{ Quote: " In a way I can see the usefulness of having options for the allow hooks for a program, so for the next version I will see if it is feasible to add it without adding a whole lot of complexity to the program." }-Thank you for agreeing to the attempt, Jason, that's wonderful to hear. I hope it may also seem useful and feasible enough to evaluate a "Local Learning Mode" property for each program.
-{ Quote: "However I wouldn't feel like ProcessGuard is useless in its current state against Global Hooks ... " }-Far from it, Jason, ProcessGuard is the most essential security program I own. My primary concern over hooks is to optimize security. I'm feeling pretty good about the standard dialog glitch since Nick helped me disable auto-completion. Many thanks to everyone at DCS for what ProcessGuard is already, and for earnestly considering what others think it might become.
Mike
rickontheweb
December 6th, 2004, 12:27 PM
I tend to agree with Jason in some respects. Some things like this are very easy to simply ignore.
Even with turning off global hooks in IE, it took me a week to notice that the only ill effect I found was that menus didn't open when sliding over the menu sideways, they all had to be individually clicked open to drop down. So I turned on global hooks for IE to eliminate that annoyance, but I would definately prefer to limit IE to mouse hooks only.
Allowing global hooks can create some pretty dangerous scenarios. Anything that communicates out my LAN to the Net needs "global hook shackles" in my opinion or at least needs to be scrutinized as a security risk until proven innocent, with IE being a really "if" in my book these days. I've simply caught to many trust worthy apps doing things out my LAN without asking or even in defiance of privacy or communications settings or encountered strange goings on "if"y websites. It's just to easy to Google a hostile website on a legitimate search.
Of course I have since switched to FireFox. Security is multilayed thing after all, but I would like to have a little more versatility in global hook control....if possible.
vBulletin® Copyright ©2000-2012, Jelsoft Enterprises Ltd.
Copyright ©2002 - 2012, Wilders Security Forums