ProcessGuard v3.xxx Suggestions / Wishlist

Rolling along with the suggestions....

During a boot I got the log entries below in the PG logfile, the issue I have here is that the logfile refers to a process id without telling what the process is

It would be good to make sure that a process was not logged by process id alone without having first given the process name (at some point earlier in the logfile)

I can guess as well as the next person, in this case the process is still running so there was no need to guess

C:\>tasklist /FI "PID eq 2728"
Image Name PID Session Name Session# Mem Usage
========================= ====== ================ ======== ============
HydraDM.exe 2728 0 2,144 K


The other oddity was the process logged as having been started by "Unknown Process", presumably this is because the parent wasn't there when the child actually started up
That could be solved by logging the process id when a process starts so that we could search backwards in the startup logfile if we really wanted to know

If nothing else it is quite interesting to see exactly what is being started up at boot time

Log Entries

Wed 17 - 00:53:18 [EXECUTION] "c:\program files\ati technologies\hydravision\hydradm.exe" was allowed to run
[EXECUTION] Started by "c:\windows\explorer.exe" [520]
[EXECUTION] Commandline - [ "c:\program files\ati technologies\hydravision\hydradm.exe" ]
Wed 17 - 00:53:19 [EXECUTION] "c:\windows\regedit.exe" was allowed to run
[EXECUTION] Started by "c:\program files\common files\symantec shared\ccpwdsvc.exe" [2680]
[EXECUTION] Commandline - [ regedit.exe /e "c:\program files\common files\symantec shared\ccreg.dat" "hkey_local_machine\software\symantec\ccreg" ]
Wed 17 - 00:53:22 [GLOBAL HOOK] [2728] was blocked from creating a global GetMessage hook
Wed 17 - 00:53:23 [GLOBAL HOOK] [2728] was blocked from creating a global CallWndProc hook
Wed 17 - 00:53:23 [GLOBAL HOOK] [2728] was blocked from creating a global Mouse hook
Wed 17 - 00:53:23 [GLOBAL HOOK] [2728] was blocked from creating a global CBT hook
Wed 17 - 00:53:23 [GLOBAL HOOK] [2728] was blocked from creating a global Call Wndproc Return hook


Also a bit further on I saw

Wed 17 - 01:03:00 [EXECUTION] "c:\program files\symantec\liveupdate\aupdate.exe" was allowed to run
[EXECUTION] Started by "Unknown Process" [3820]
[EXECUTION] Commandline - [ "c:\program files\symantec\liveupdate\aupdate.exe" ]

 

A SMH suggestion:

Enabling SMH for an application gives the confirmation prompt when any window belonging to that application is closed, including prompts. For applications that prompt frequently (e.g. some firewalls, System Safety Monitor) this makes SMH a painful experience since multiple prompts have to be answered (or cancelled) regularly.

To counter this, either add the ability to restrict SMH to "main" windows only (i.e. exclude any created after the first one) or allow protection to be restricted by window title (this is constant for almost all applications so should be more workable, though a wildcard facility should be available for programs which include variables like filenames in the title).

 

It looks like HYDRADM.EXE might have been blocking access to finding its processname.

The being started by unknown program is as you specified, the parent process is gone by the time the process name is being resolved.

 

Jason,
That would seem to be quite an achievement for a process with no special privileges, after all PG blocked all of its attempts to do anything tricky
And if that were the case why would I be able to list it using tasklisk ?

Either way my comments still stand, displaying the process id at startup solves both of the issues I just gave an example for, which is something that I'm sure you didn't overlook

Just so it doesn't seem like I am *just* criticising PG all the time, I do like it and the extra security it offers (and I did buy it after all).

I'd like to be able to recommend it for enterprise use (and I have already) but it could do with a few tweaks to have more of a chance at meeting justifications for adding to the mix with other competing enterprise level tools.

Centralised logging is a fairly key feature, and this can be achieved by putting things in the eventlog so that a plethora of other tools can take it out and centralise it or a variety of other methods (mentioned earlier)

 

Hi P2K,

Usually, after you have trained SMH, you should get an option to click "Ok to All" In the HID window, click that and your app and sub-windows should close down.
Clicking cancel can sometimes cause multiple HID windows and the App will close anyway, this has been explained in other threads and cannot be prevented in some programs.
For more information about SMH training please read the Help file.

Thanks. Pilli

 

Pilli,
He does have a point as I'm sure that you recognise, it might be a non-trivial one to solve but its still valid and sometimes can be a little annoying. Its not particularly hard to live with after all, just a minor annoyance

I'm sure it would be possible to find something in common with the various dialog boxes using something like Winspector (or whatever your tool of choice is for viewing information about windows and event messages)
It may be too much effort to solve a minor problem but it would enhance the overall "feel" of the product


NB: For anyone interested Winspector can be found at http://www.windows-spy.com/
If you are bored you can use it to move scrollbars around in programs from left to right, turn them on and off etc...

 

Hi gottadoit, Jason has done much research into the problems concerning SMH & methods used by programs to close down.
Close Message Handling is highly complex and unfortunately there is no simple solution. HID's are not perfect but they are a very hard problem for Trojan writers to get around.
Having said that, I am sure that DCS will make improvements as these become apparent over time.

Cheers. Pilli

 

Wish List (where previously requested, count me +1)

#1) Specify which specific types of global hooks a program can install.
#2) Specify which drivers/services are installable by services.exe (svchost.exe?).

#3) Procguard.exe running from a "User" account -- Instead of runas/admin-name/password.
#4) New button (on Alert-tab): "Empty Log File" -- Instead of runas/admin-name/password. Better yet, see #5.

#5) New Option: "Minimal Logging" ----- Minimal logging could be as simple as, "Don't log successful hash-code checks". Without "[EXECUTION] XXX was allowed to run" entries, my logfile wouldn't need constant clearing. In fact, an ongoing log of important alerts would be a reference worth preserving. Moreover, minimal logging should also eliminate the need to manually "Remove All" Alerts (to recycle memory). Of course, a more flexible and comprehensive set of logging options would always be welcome, too.

Jason, thanks for describing the "safe area" you're hoping to implement. It really made my day!

 

hmmmmmm i still cant break process guard

i havnt spoted anything wrong am i doing something wrong?

it works perfect on my pc

maybe im not trying hard enough

 

hmmmmmmm, good point

 

Hi,
I seem to remember seeing some entries in the protection tab which were 'allowed to run once' without any popup dialogue, due to the fact the they were run prior to the GUI part of PG3 loading. (I cant remember the exact wording of the entry in the protection tab)
It would be nice is to have a baloon pop up as soon as the GUI loads to say that a process was allowed to run without authorisation, so the operator could check the logs and grant/deny future access.
Tom

 

Pilli, can you provide links to those threads, please.
-hojtsy-

 

Hi Hojsty , OK Here Goes:
https://www.wilderssecurity.com/showthread.php?t=54890&page=1&highlight=Secure Message Handling
https://www.wilderssecurity.com/showthread.php?t=54857&highlight=Secure Message Handling
https://www.wilderssecurity.com/showthread.php?t=54697&highlight=Secure Message Handling

And one today:
https://www.wilderssecurity.com/showthread.php?t=55309&highlight=Secure Message Handling

As mentioned in all these threads reading the help file is important regarding Secure Message Handling.

HTH Pilli

 

I have to echo earth1's suggestions, particularly #1 and #2.

 

This does not need to be done. Even though services.exe has "Allow Install Drivers" ProcessGuard now blocks applications from using services.exe in a way that you will get the REAL application asking for "install driver privileges" before it gets to services.exe . There is no need to remove "Install Driver" privileges from services.exe anymore, it should be left on by default otherwise you will get issues with ProcessGuard blocking driver installations in 2 places instead of one.

 

That's fantastic, Jason, your solution sounds much more elegant and transparent. I'll enable services.exe as suggested. Thanks a bunch.

 

Jason, Gavin & all who advised with my problem,

Jason, I was unable to locate the thread that was started with regards to my problems (I thought were) with Process Guard. That thread appears to have been deleted from the forum. As the thread was missing and there was not an appropriate place to put this post, I am just putting it here. You might direct it where you feel is appropriate.

I can not protest the action of removing the thread, but instead must complement that action. I must explain. I first would like to apologize for pointing to Process Guard, as the cause of my problems, when in fact it was not. I doubt seriously that it caused me to have to re-install my system, as one of the responders pointed out, that it was probably caused by my uninstalling my security applications, installing PG then re-installing those security programs. And probably, as he suggested. the re-installation of my system was likely unnecessary. At any rate I did re-install my system and the problems that I attributed to PG after that re-installation, it turns out, was not PG at all. I have discovered that my problems were not gone with the uninstall of PG. I got another blue screen startup after PG was removed. Which got me looking for the cause, which I still thought was PG and I had a bad uninstall. A friend suggested that I use Administrative Tools/ Component Services/ Event Viewer/ System (as it was a System Error I was getting). There I found that an Error was showing and its cause was my Ultra 160 SCSI controller card driver. During the installation of the OS that driver had not been installed. I suppose that Windows XP had SCSI drivers on board to just get me by, but at boot time the controller wanted the driver that was designed for it.

Anyway I installed, the driver and used the computer enough to discover that system error had been eliminated. I next thought, should I give PG another try. I decided I would, as all of my problems that I had been attributing to PG may have been the missing driver all along after the re-install of the OS. So I finished installing all my programs on my system, then installed PG. And so far, (knock on wood) it is working great. I did as suggested Jason and ran all of my applications with PG in learning mode. When I switched off learning mode and rebooted I was most apprehensive. But that apprehension was in vain, as it has worked flawlessly since that reboot and I am not getting all of those, system files coming up asking me to allow or deny. I think that I have only had one of those since the re-install of PG, but it was obvious what it was for, so I allowed it, with no apparent problems resulting.

Like I say it is working great. There is one thing though that keeps coming up (not causing any problems though), it is a little balloon notice by the system tray, which says that a Global Hook to the Mouse and Keyboard has been blocked that msmsgr (Windows Instant Messenger I assume) is attempting to install. It gives me the same message for yhmsgr (guess Yahoo Instant Messenger). But both seem to work ok, so it is not a problem.

I was very (unnecessarily) upset with PG on my last post. And as it turns out without grounds. Just wanted to let you know that all turned out good, and let you know as well that I made a mistake by attributing my problems to PG.

Hoping You All the very Best,
And Thanks Again,
John

PS
Finally found the thread that was being used to aid me with my problem. (My inexperience with the forum prevented my finding it but I am gaining that experience solving problems such as this.) Anyway the thread is “Insight into how to make PG work”. I am going to re-post this post there. Sorry for placing it in the wrong place.

 

i haven't (yet) read through the thread here, so..

1. i think there should be a limit put on the size of the log file in pg..

2. i wish that there was an option so that when you are alerted to something by pg, you could set it so that pg would not alert you again to that same thing.. i have three apps that try to create global hooks where i am opting to not allow those since i don't seem to need them to still use the apps.. however, i get alerted about the apps trying to create global hooks each time i start them.. then i have to pull up pguard so that the icon will go back from red to "blue".. it is not a biggy..

incidentally, i liked the red icons that were used previously in the beta versions.. i liked that the pgauard icon in the systray was red when everything was kosher, and darkened, "x-ed", when there was an alert.. i can understand why you changed that; at first, i did not like the red icons, but they grew on me..

i am going to try to read through the thread.. some of the issues that others have mentioned, from what i have read so far, i do not have a problem with simply because i disable pg's protection when i am installing programs..

 

I would love to see this feature implemented as well

 

Me too, it helps address the issue with standard Windows dialogs that create mouse hooks.

 

The problem is not having multiple HID windows appearing when shutting down an application, the problem is having HID windows appearing when any window belong to that application is closed. To take an example, with Outpost firewall you can run it in Rules Wizard policy where it prompts you for undefined traffic giving you the option of allowing it, blocking it or creating a rule. Responding to any such prompt brings up the HID. SMH training does nothing for this (though it is useful, indeed necessary, to prevent the "Exit and Shutdown" option in Outpost from being used). Being able to restrict HID to the main window only would solve this.

As for the HID prompt itself, I'd like to suggest that it include more readable information. Rather than a window name (which is unlikely to mean much to most users) how about the window title? Also rather than just giving a message type, how about the action requested? (e.g. shutdown, disable, allow all network traffic, stop background filescans). This may require supplying an action name in SMH training (to take Outpost again, I have SMH capturing any attempt to change Outpost policy to Disabled or Allow Most modes via the system tray icon menu) but it would be nice to be able to see these reported in the HID.

 

Yes, the problem P2K just described is very anoying.

 

How about an inverse of the INSERT key, allow us to hold down the DELETE key to train SMH to ignore closing a dialog window

Easy to say I know, much harder to decide how to identify this particular dialog window and not other ones...

 

By unticking SMH for an application you remove all the SMH learning you have done for that application. I don't see the need to have something to do one at a time, especially when a malware could then mimmick that behaviour to get around the protection.

 

Jason,
As you probably already realise my objective is to stop the somewhat useless prompts that appear after some dialog boxes have already exited

I am now quite well trained to click cancel twice after responding to a Kerio dialog box asking me if it is ok to run a program....
The idea behind my suggestion would not be subvertable if you were to require some interaction to confirm it

My goal is not to remove SMH from my firewall... just to stop somewhat less than useful confirmation prompts from dialog boxes that have already closed. Dialog boxes have window titles (at least some of the time) that might be one way to distinguish between times we *want* HID windows and other times when it is somewhat less than productive...

One other method might be to have the HID dialog that you are displaying check to see if the related window (that it was triggered for) still exists, if it doesn't then there is nothing to prompt for... so you could give a different message and the option to not display the "got there too late" message for that app next time

Any suggestions on how to do this are of course welcome