TDS-3/PortExplorer As Examples?

Discussion in 'ProcessGuard' started by siliconman01, Nov 28, 2003.

Thread Status:
Not open for further replies.
  1. siliconman01

    siliconman01 Registered Member

    Joined:
    Mar 6, 2003
    Posts:
    780
    Location:
    West Virginia (USA)
    Okay, ProcessGuard 1.1 is installed and running. On my system I have TDS-3 and Port Explorer running all the time (automatically started on reboot). I have Execution Protection enabled on TDS-3. I want ProcessGuard 1.1 to protect them so I have them installed in ProcessGuard.

    What "Allowed" Flags should I have selected for TDS-3 and Port Explorer to permit these programs to properly do their thing to protect my system and do it when a BAD ITEM like a trojan hits my system?

    This probably sounds like a "dumb" question, but I don't want to find out after the fact that I should have set x, y, z "Allowed" flags. :doubt:
     
  2. siliconman01

    siliconman01 Registered Member

    Joined:
    Mar 6, 2003
    Posts:
    780
    Location:
    West Virginia (USA)
    As stated in the previous post, I have PE 1.80 and TDS-3 guarded with PG 1.1. I also set the close message handling option on both of them. Here's what happens:

    Port Explorer:
    1. When rightclicking on the systray icon and selecting exit, the 5 digit panel comes up and after typing in the code, it exits fine, no problem.

    2. With PE active and selecting HELP, CHECK FOR, it makes the version check or the Port database check okay. Then it throws up the 5 digit code panel and needs to have the code to close window 32770 (whatever that is). The code is entered and PE stays active...which it should. Why the code panel when checking for an update?

    TDS-3
    1. When right clicking on the systray icon and selecting exit, TDS-3 exits with NO 5-digital code panel display.

    2. HOWEVER, when you try to restart TDS-3 manually OR on a system reboot, the 5-digit code panel comes up and you have to enter the code for TDS-3 to start up.

    Am I missing something on this code message handling optiono_O

    Here is what happens with Lavasoft's AdAware memory resident module Ad-Watch with the Code message handling selected.

    1. Right click on Ad-Watch icon and select Terminate.
    2. Ad-Watch requests YES/NO to terminate.
    3. 5-Digit code panel comes up.
    4. If you type in the code, it will let Ad-Watch terminate okay.
    5. If you select Cancel, it goes through trying to get a code for TPUtilWindow and then TAWMon window. Selecting cancel on this 3-4 attempt code entry, Ad-Watch then gets a system error and access violation error and aborts.

    There are other programs that have similar problems with the Close Message Handling...will wait on response to this inquiry to see if I am doing something invalid or "stupid."
     
  3. gkweb

    gkweb Expert Firewall Tester

    Joined:
    Aug 29, 2003
    Posts:
    1,932
    Location:
    FRANCE, Rouen (76)
    PG is just installed/configured and working on my comp, i will report any pb i'll found :)

    But as of now, i can say i have the same problem than you with System Safety Monitor and the Close Windows protection.
    Indeed, each SSM "popup" is considered as a window by PG and i have to enter at each one a code! So of course i disable this protection for SSM.
    The problem you have with TDS3 update is that the update is a window too.

    The solution would be to be able to just protect the _main_ window only.
     
  4. spy1

    spy1 Registered Member

    Joined:
    Dec 29, 2002
    Posts:
    3,139
    Location:
    Clover, SC
    Not having anything but the exe protected still gets you a confirm window if you try to close out after checking for either PE version updates or an update to the Port and Domain databases if you have "Close message handling in effect on the exe only.

    It would require a program change for it to stop doing that? Pete
     
  5. siliconman01

    siliconman01 Registered Member

    Joined:
    Mar 6, 2003
    Posts:
    780
    Location:
    West Virginia (USA)
    Sounds like the Close Message Handler option is a security feature that the user pays a pretty high price for "user friendliness". o_O
     
  6. gkweb

    gkweb Expert Firewall Tester

    Joined:
    Aug 29, 2003
    Posts:
    1,932
    Location:
    FRANCE, Rouen (76)
    as i said the purpose is to protect the main program windows (of the protected software) but actually it protects all windows of it, which is quite anooying if your program always display popups on the screen :doubt:

    This is a great protection really needed, i use it for my firewall, but to be able
    to use it on any software, the "only main window" fixe has to done, if it's possible, i don't know.
     
  7. Gavin - DiamondCS

    Gavin - DiamondCS Former DCS Moderator

    Joined:
    Feb 10, 2002
    Posts:
    2,080
    Location:
    Perth, Western Australia
    Yes but you dont NEED Close Message Handling on those programs. Just have it ON for Process Guard only :)

    - Note that if you find a program closing unexpectedly you could always THEN turn on Close Message Handling, and start it.


    Allow flags ? Almost nothing needs allow flags. Allow the ones that were set automatically and only adjust them if you want to lessen the number of log entries you see.

    Something doesn't need access because that access is only needed to perform actions on PROTECTED processes. So why would you want to give TDS-3 terminate access on known GOOD things :) Dont worry it will become clear with usage. This is mentioned in the help file too, please let us know if that has enough info ;)
     
  8. Andreas1

    Andreas1 Security Expert

    Joined:
    Jan 29, 2003
    Posts:
    367
    Location:
    Mainz (Ger)
    Hi all,
    here's a quick rundown on how I understand that CMH (Close Message Handling) is working and why as of now it produces some problems like the ones you have described:

    In windows, programs can not only interact by one process asking the managing OS to get a handle on another process (which was the first issue where PG 1.0 was interfering), but also by sending certain "window messages" to any window on the desktop. The application that the target window belongs to then should handle that message. Since Windows is fundamentally event-driven, these messages are one of the mainstays of communicating certain events to an application, or rather to a window or to a control (the elements inside a window - buttons, listviews, textboxes etc - are called buttons, but in essence are just windows of a different kind) like "the right mouse button has been clicked on you", "The contents of the clipboard has been pasted to you", "you've lost focus" (e.g. when the user has clicked on a different app's window), "your requested timer interval has elapsed" (e.g. when the app has asked the OS to notify it after a certain time so that it refreshes its window), "your caption is supposed to be 'OK' now", "go away!" etc. Quite obviously, these messages are used a lot in an application communicating between its various modules, processes, windows etc. and in the communication between the OS and the application.

    Now the security issue is that when the windows message handling routine receives such a message, it has no way of telling by whom that message was sent - it could be a thread of its own application, the OS, the keyboard or mouse driver, or another application that simply wants to get rid of it, i.e. a malware/trojan.

    To complicate the issue, there are lots and lots of windows messages and probably lots and lots of windows receiving them.

    The issue taken with PG is to hook into those apps that the user wants to protect (yes, by dll injection) and, more specifically, into their windows message handling routine. If there arrives a message, and it fits the set of messages PG is coded to alert on, further message handling is delayed until the user has confirmed that this is an "okay" message and probably harmless. If the user cancels PG's Human Confirmation Dialogue, the message is dropped and the windows code never sees it at all.
    Of course, PG doesn't alert on every message (some are not exploitable at all, some may arrive 500 times a second), but just on a couple of messages used to close or destroy the receiving window (and its owning application along with it). You're still seeing a lot of alerts, which means that even those "close" messages are used rather frequently in everyday useage. (Quite often, when an application shuts down, it closes its own windows by sending them such a message and there's simply no way of knowing that it was the protected application itself that has sent the message. And often, it closes quite a few windows like this (splash screens, dialogues, hidden windows, tray controls, QuickInfo popups, ...) - which is what gets on all our nerves.
    Additionally, if the user doesn't either close all or cancel all those messages, the application will be left hanging in an undefined an unanticipated state which causes more trouble. (That's what the "OK to all" button is for.)

    The key to the problems then is that PG doesn't maintain a list of rules containing which windows to alert on, but simply filters the defined messages for all windows belonging to the protected apps. And when one consider the possible combinations of message type, window name (and often the mere windowname is not specific enough) and application, and the performance cost it would mean to compare messages to such a ruleset, that choice seems a reasonable one. (Maybe it is a revisable choice, we'll see what reasons and experiences will emerge...). Anyway, there's currently no way to pre-configure or save your preferences for handling the alerts you're receiving.

    For this reason, and for the reason that some - especially security-related - programs have a windows messages handling routine that is more difficult than usual and that doesn't go well along with PG. On the other hand, some - especially security-related, but not necessarily the same as mentioned in the previous sentence - programs have a "human confirmation" prompt of their own, so you maybe don't need PG's CMH on them. Examples are NOD32 Control Center, Look'n'Stop, RegRun in some respects. (And if they seem not as proof against manipulation attacks as PG's confirmation prompt, it would probably be better if you got their programmers to improve their protection instead of bugging DCS to get PG compatible to it.) In PG's helpfile, there's a short section "for programmers" where a windows messages handling routine is presented in C++, (M)ASM and VB - this is not as tamper-resistant as PG's prompt, but should be a fair starting point for any programmer of an app that should be defended against "windows messages attacks".


    Bottomline: While CMH provides rather good protection, it's strongly recommended to thoroughly check out if the programs you want to protect in fact works well along with it. Maybe it has a confirmation dialogue of its own and you don't need CMH on it as desperately. Maybe it works really well with it (like Proxomitron or PortExplorer, if I recall my own tests correctly).
    However, if you do encounter problems, it'd probably be best to note as exactly as possible the situation of the event (which app, which windowname in PG's prompt, what did you do that (or what do you think what) triggered PG's prompt have there been any preceding prompts, are you confirming or declining, how do you continue with succeeding prompts...?) and make DCS aware of it. But remember: you're not describing a bug (most probably), but adding to a database/(in)compatibility list that will help DCS in improving PG's CMH in later versions.



    I hope this has been helpful to some.
    Andreas
     
  9. Andreas1

    Andreas1 Security Expert

    Joined:
    Jan 29, 2003
    Posts:
    367
    Location:
    Mainz (Ger)
    I usually have one tool with allow flags - that i can use to kill programs that are protected but might hang somewhat.

    (Actually, right now I have more allowances, all AV/AT, a couple of Task-Man like tools, but Gavin has just convinced me that this is not necessary at all. :D )

    Cheers,
    Andreas
     
  10. siliconman01

    siliconman01 Registered Member

    Joined:
    Mar 6, 2003
    Posts:
    780
    Location:
    West Virginia (USA)
    As of this morning, I am of the opinion that using PG is definitely not for the novice or "weak at heart." :p

    First let me say that I understand Close Message Handling feature more. Not sure I understand why it is offered as an option on all programs if you only need/want it on PG.

    Here is some items I found causing concern on my system. Please note that when I installed PG 1.1, I let it protect the "first time" elements.

    1. I have Pest Patrol on my system. It's memory checking module is memory resident. Even though I have ppmemcheck.exe added to the PG list and have Allowed "Terminate", it still logs messages that ppmemcheck.exe tried to access "Terminate" on all the items in memory.

    2. Am using AOL 9.0 Optimized. When activating AOL, some of the features of AOL disappeared. An example is the Spam folder in AOL mail. On looking in PG logs, it shows that waol.exe is trying to access several modules that are protected by PG "first time" elements. In order to get AOL features back, you have to add waol.exe with allowed options selected. The AOL sign on module AOLacsd.exe has the same deliminea. I didn't go through all the various features of AOL 9.0 Optimized such as spyware protection, computer checkup, radio, video, etc.; however, I suspect that some of these modules will need set up in PG.

    3. I did a version update on a security program that I had in PG protection. The update went okay; however, when I restarted my system, I ended up with 2 entries for the pgm in PG, the older version and the newer version. I deleted them both and then re-added. I assume the resolution to this problem is to remove the pgm from PG prior to update, do the update, and then add the pgm back.

    To be very honest, it appears to me that PG is going to take a LOT of scrutiny by the user when installing/setting up/maintaining. I'm not complaining...just editorializing. Based on what I am seeing thus far, I am "concerned" about such things as going through a MS Windows update automatically and even a LiveUpdate of NIS 2004 and other LiveUpdate programs. Probably false concerns, but... I've decided to remove PG and rethink my need for it at this point.
     
  11. Andreas1

    Andreas1 Security Expert

    Joined:
    Jan 29, 2003
    Posts:
    367
    Location:
    Mainz (Ger)
    Hi again siliconman01,
    the first two issues you're reporting will have to be dealt with by DCS themselves (why is PPetrol "Terminate" allowance ignored (if it is)) and by users who have more experience with both PG and AOL.
    The third issue raises a rather important issue, tho:
    If you're doing updates of critical components of your system, possibly of programs that are in PG's list of protected programs, "Disable All Protection" for that operation. (Concerning AV/AT updates, you'd probably have to find out if just signatures and rules are being updated or the executable programs/engines themselves... Or disable it anyway "just in case".)

    As for the general concern you express, I think you are partly right. If a user has a system that isn't set up in an extraordinary way (and I am thus forced to consider AOL an extraordinary installation on any system), and he or she doesn't want to add very complicated things - or none at all, he or she will be served rather well with the default settings. For most complicated things it is indeed also complicated to get the right fine-tuning in PG to set up protection for them.
    However, only very few applications - as far as we have been able to test during the beta phase, where we have tested a lot of them - actually give real hard problems. Like the one you're describing with PPatrol.
    And in most (tho of course not all) of these cases (strange log entries, incompatibility with PG's CMH), it's the other program that behaves in a peculiar way, PG only makes you aware of it. (we had some problems similar to those you're describing with AOL with parts of the Office suite and IE/OE. They, among other stuff, have resulted in the default list of programs added by the "wizard". Merely mentioning that these problems have of course been related to how intransparently, counter-intuitively and complicatedly MS uses the interaction between these system processes should cast a bit of doubt on the idea of AOL here properly using the system - IMHO). However, I agree that this awareness often goes along with the inability to use your system in a normal manner and isn't something you'll want to have on your system for very long.
    But I am quite confident that with user feedback to DCS and to third-party developers, this will be worked out step by step.

    Sorry to hear of your unfortunate situation with both PPatrol and AOL, tho. I hope your input will give DCS a handle on how to improve PG or on how best to approach PPatrol/AOL developers...

    CU,
    Andreas
     
  12. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    17,043
    I also use AOL 9.0, and when I installed PG 1.1, I had no problem with AOL. I didn't put AOL or any components of AOL, in the PG database. My stumbling block with PG 1.1 was/is the log off/shutdown problem.
     
  13. siliconman01

    siliconman01 Registered Member

    Joined:
    Mar 6, 2003
    Posts:
    780
    Location:
    West Virginia (USA)
    Hey thanks for the replies/input. Do appreciate it.

    I retried PG 1.1 and AOL 9.0 Optimized. Same result. I am using the Tahiti version of Optimized which is a beta...true...maybe not fair to PG 1.1, but the problem is 100% reproducible on my system. As is the Pest Patrol ppmemcheck problem.
     
  14. Gavin - DiamondCS

    Gavin - DiamondCS Former DCS Moderator

    Joined:
    Feb 10, 2002
    Posts:
    2,080
    Location:
    Perth, Western Australia
    When you use Close Message Handling, you are allowing PG and its MSGProt service to control Window messaging on your machine. No thats not Windows Messenger, or MSN messenger ;). It relates to the window messages that the OS uses to tell windows to minimise, maximise, and yes to close.

    This is experimental, and highly complicated but as you see, does work for us :) The problem for you is, that Windows has many hundreds of windows that you never see. A single window program can have many many other windows created for its needs.

    While there are some problems which make using it difficult at times, we will address what we can and in time ultimately we should come up with fixes for most things :) Most importantly, it protects against future attacks - when trojans cant terminate your antivirus or firewall, cant forcibly write code to your processes (cant patch the system processes such as services.exe either) then these close window messages could be an attack. If your TDS for example ever shut down you could simply add this protection and restart it. If it works then you have a trojan running, isolate and kill it - it cant even stop you from doing that.
     
Thread Status:
Not open for further replies.