This page is part of a larger project focusing on securing MS Windows. Get to the other pages by here.
This is a detailed discussion of DiamondCS' ProcessGuard, a tool designed to generically
protect your sensitive and critical processes from being tampered with by all
sorts of malware. However, it is focusing on version 2.000 which, at the time
of writing, is being superseded by version 3.000 (which is currently in beta
stage).
Who wants to rather study the review of the more up-to-date version, should
skipt this page and go here.
I am keeping this page here around, though, for historical reasons and for
those who still have version 2.000 and want to learn more about it. But you
should know that it's strongly recommended to upgrade - which you can do
for free by going to ProcessGuard's homepage, member section and downloading
the new version and a new key along with it.
Actually I'm rather excited about this one: a few years ago, there surfaced trojans
(like BioNet or Optix) that were capable of shutting down security software. There
was much discussion about them in the anti-trojan software scene, in spite of the fact
that, as far as detection was concerned, these new breed wasn't much different from
the more traditional trojans. And in case the trojan wasn't detected, why should it
worry to kill the trojan scanner that doesn't detect it anyway? But killing other
programs like personal firewalls was of course of great interest for the trojan
authors, so they could have their malware bypass the generic blockage that these
programs meant for them.
Many different developers thought of many different approaches, but in the end they
all had to agree that there was no final solution possible because the trojans made
use of a bug-feature of the windows NT architecture: There is a function that these
OS's provide, called TerminateProcess(), and this function allows the calling process
to terminate any process it wants, regardless of privileges etc.
So, as long as MS wouldn't have the calling processes authenticate in one way or another
(to the OS, to the target process or even to the user), there couldn't be anything done
to prevent this function to be exploited by malware.
On a seemingly unrelated edge of the malware front have trojans a year or so ago started
to use another technique to bypass personal firewalls: It's called "dll
injection" and it means that the trojan injects (parts of) its code as a
dynamically loaded library (dll) into running processes that are likely to be allowed to
communicate through the firewall. While the firewall might alert or even block an
"attempt by Iamatrojan.exe to send data to 123.456.789.123
(www.homeofthetrojans.com)", it will probably already be so configured as to let,
say, InternetExplorer send data to any host's www port. So the trojans manage to have
their code being executed by Internet Explorer and the firewall lets the communications
pass.
Dlls are actually a good thing: If you're writing a routine, or a set of routines,
associable with a specific task (say, image rendering), maybe you don't have to have
these loaded into memory until your main application program (maybe a word processor)
wants to do something which corresponds to that task. Then you put them - in about
the executable form they would have if they were static parts of the main application
program - into an extra file which the application can load on demand. This has the
additional advantage that some other application that might want to perform similar
tasks (say, a webbrowser) can also load that extra file with your routines and doesn't
have to invent the wheel twice.
The trick is now, that, just like with TerminateProcess(), any program can call a
function on another program that makes the other program load a dll of the
function-caller's choice, and that makes the other program execute the instructions
therein. It needs a bit of tweaking so that the "host" program doesn't just
crash for executing this foreign code, but that's something the trojan authors now can
handle.
Initially, the personal firewalls made sure the communications belonged to a certain
application program in order to be permissible, but that wasn't sufficient anymore.
Consequently, many firewalls have started to also control what dlls are being loaded by
applications potentially allowed to send data out. Unfortunately, there are applications
that are very common (like InternetExplorer or WindowsExplorer) that load really very
many dlls out-of-the-box, and so that control is not only a venture into territory not
the proper ground of firewall software, but is also necessarily complex and means a
significant resource strain.
A final, also seemingly unrelated, tendency has emerged in even more recent times:
Strategically spoken, trojans are being used less to have fun with some unwitting
victim "l00ser" computer user, but to more or less professionally sniff
out bank account and password data. Technically, that is done a) by searching the
hard disc for sensitive information, but more importantly b) by logging all the
keystrokes of a user. To have this logging installed, and to have it hidden, trojans
are beginning to meddle with the internals of the windows operating system. They hook
onto the keyboard handler, and they inject themselves into the OS's central
processes.
Slowly but surely, they're also beginning to adapt a hiding technique known from unix
malware (rootkits): They mess with central system tools in such a way, that the user
or even other programs can not even see that they're there. For example, they have the
Task Manager behave normally and list all the running tasks - except one, the trojan
task. They are using techniques discussed above (dll injection and process
manipulation), but no longer on the programs that prevent them from working as the
author wants them to, but on those core processes that the scanners have to use to find
them. It's going to be interesting to see how the anti-virus, anti-trojan developers
counter that threat.
I hope it has become clear that all of these threats have a common root in Windows'
architecture. While the architecture is so designed as to keep the memory space and
command stack of all processes totally seperate from each other, the demands of
possibilites of process interaction seemed to require a way to bridge that gap, and
Microsoft decided to provide functions which puts everything about a process in the
hands of the one that calls the function.
The most natural, most common-sensical reaction, is of course:
Ah! Why didn't Microsoft design a proper way of inter-process transactions in the first
place?! Or: Wouldn't Microsoft just come up with a patch that has these transactions
happen in a more secure way?! (The answer to that question is of course, as anyone can
easily guess: Nope.)
Venerable anti-trojan developers DiamondCS have presented a security program, ProcessGuard, that I use to refer to as "runtime OS patch" - because it installs a kernel mode driver that changes the operating system's behaviour described above. (For this very reason, just as the problems described above apply to Windows NT and above, so does the cure: ProcessGuard is available only for NT, 2000, XP and 2003.) Now every attempt of any process to gain access to another process is filtered: processes can be either protected, in which case the admin can specify which modes of access attempts (read/write/terminate etc.) are prevented, or they can be explicitly allowed to perform these operations in case it's necessary and legitimate. Admittedly, this requires a bit of finetuning (although the default set of permissions leaves you at least with a system you can work on). But it is about the only program that I know of that prevents all of the three attacks described above.
Of course, ProcessGuard had and still has to take good care of itself not being ended or disabled by some malevolent program, and it does so in the most comprehensive way I've seen to date: It can prevent system drivers from being installed (thus also blocking rootkits), catches critical windows messages/events (and has the user confirm them in a clever way), blocks TaskManager's "EndTask" command (which is yet another way of killing things) and so on. Most of the things PG defends against have not yet been used by malware, not even in a proof-of-concept way. And those strategies that are used by malware "in the wild" are all covered. (When PG was launched, there was some discussion about it fulfilling the task it was designed to fulfill, but being too easy to shut down itself, and so some of the defenses were introduced as reactions to some small proof-of-concept programs that had been presented with great noise. This has calmed down, almost all of the bases, certainly all of the easy ones, are covered, and when a new (theoretical) vulnerability shows up, DCS quickly responds to it. Most of the time, however, they discover themselves new internal aspects of Windows that can use some strengthening and implement it into PG before there's an alert of any sort about it.)
Once in the kernel internals, DCS developers have also added many other tweaks like control of hooks (so ProcessGuard prevents keyloggers from working), and preventing Windows' own File Protection System from being disabled.
Almost as if to provide an example for what I've said above, the following had happened:
Consider what happens if the user configures PG so that a program is explicitly permitted
to terminate any of the protected programs (like, e.g. a taskmanager with which the user
wants to be able to kill any process if necessary, or a trojan scanner which is supposed to
be able to get information about a system's process's loaded modules, all in all it's not
so unlikely a scenario), but then some malicious program comes in and changes the privileged
program. Well, the malware will not be able to access or change it when it is running, for
then it is protected by ProcessGuard - but ProcessGuard does not monitor what happens on your
harddisk, so the malware could change or even replace the privileged program with a copy of
itself named like the original program. When launched from that location, the malware would
have all permissions granted to some security tool. We have discussed this scenario a while
in the beta and now imagine what the solution was:
DiamondCS have introduced a new feature that is an almost independent security appliance of
its own - PG now monitors every program launch and maintains a list of "signatures"
of programs that it knows about. Now ProcessGuard will alert you if the security tool that
you've endowed with so great privileges has changed on disk and ask you if you want to allow
it to launch or stop it right in its tracks. (When you let it launch, it will be granted the
privileges defined before.) I'm saying this is something independent, because actually it
monitors every launch of an executable program and builds a list of allowed applications.
Thus, you can have a list of all apps, define for each entry whether it should be allowed or
blocked (maybe you want to block Microsoft's "machine debug manager" mdm.exe) and be
alerted whenever a new program is launched or a known program has changed. You can even say
that you don't want to be alerted but block those modifications right away.
All this monitoring and checksumming is implemented very efficiently so you don't have a
perceptible delay introduced by it, which in itself is remarkable. (But along with this goes
another discussion that has surfaced among the betatesters and program developers: To
actually give this mechanism its full power, you'd have to monitor not only the file
signatures of the executable programs themselves, but also of the libraries they
dynamically load. It's DLL hell again. For to implement this monitoring, you'd not only
have to hack into yet another area of the Operating System, but the amount of monitorable
events, and the amount of items in your list would increase dramatically. It's very
unlikely this can be done without a more severe resource drain (CPU- and memory-wise).
We will see how this story continues. And keep in mind that this is all "theoretical
territory", no malware as of yet (to the best of my knowledge) replaces dlls on-disk.
DiamondCS offer a free version that is able to guard one process (other than
itself, that is) and a payware version for $25-30 which has no such
restriction. I would very urgently recommend that you seriously consider
testing PG with the freeware version before you decide to purchase it. For a
reason: Fixing things so intricately (and undocumentedly by MS) knit into the
windows core architecture produces an immensely high risk of incompatibilities.
Besides a few things that could be used to shut PG down and that have been
difficult to overcome (but that are overcome now - I am mainly referring to
windows messages handling, a really sophisticated feature introduced with PG
2.0), the most annoying problem was that there are so many different setups out
there. Not only W2k and XP, but different levels of Service Packs, single patches
applied or not, different languages, different other system drivers already
installed on some systems etc. It had been simply impossible for DiamondCS to test
PG on every possible setup, and with these things small differences can lead to
total collapse and BlueScreens. I have been present at many of the discussions at
the time and can but emphasize how much time and effort all people at DiamondCS
have spent to fix those incompatibilities wherever they occured. I had been beta
testing PG before as well, and while we had had a great number of different setups,
and DCS fixed everything we came up with, there were obviously serious
compatibility problems remaining even after beta phase that didn't surface
beforehand. All that in mind, I don't think it would be fair to blame DCS for
using end-users as testers - there had been thorough betatesting, the issues at
hand are more or less provoked by the matter we're dealing with here, and DCS
is not Microsoft after all with a betatester base of several thousand people
and corresponding budget/personnel. So, to make a long story short, try before
you buy. DCS are very generous when it comes to what they grant to their
customers (like free updates, rebates on other DCS software (see below)), but
when you run into a problem and they can maybe not even reproduce it with the
computers they have, I think it's understandable when they say 'you should have
tried beforehand' when you then want your money back. Perhaps it's not
extremely laudable, but IMHO it's understandable.
So DO TRY IT before you buy.
(And in case you want to buy it, consider going to DCS via
this
link, which tells them you come from my site ;).)
There are several options available from the menu, and three tabs: protected programs, registered programs, and the log. I will discuss the menu and the first two tabs, showing the results of our settings in the log tab.
Here you can maintain a list of programs that you want ProcessGuard to protect. You can
use the "Remove" and "Add Program to Protect" buttons to build the
list and when you select an entry, there will appear a dropdown selection box at the
bottom of the list, providing access to block, allow and misc options for that entry.
As has been (somewhat) explained above, what they are protected from is this:
Another process asking the Operating system to get a handle to the protected
program, which (the handle) is supposed to provide the possibility to read or write
to the program's process space, to get or set information about the process's working
environment (such as execution stack, registers etc.), or to suspend or even kill the
program. In this request PG interferes and you can specify what exact kinds of
requests will be blocked (and logged).
Since you want (some of your apps) to be able to still terminate a hung process - even
processes that are central parts of your security apparatus can crash and can need
to be killed and restarted, or maybe shut down to free resources when you're offline -,
you can also endow programs with "allowances" corresponding to the blocks
which overrule the protection settings. Usually I have one Task Manager and my virus
and trojan scanners with such permissions.
(Note that a block will of course come unexpected to the program that's making
the request. There is some difficulty coming from the fact that many programmers are
developing their programs to request more privileges than they actually need. Programs
that are actually only enumerating the running processes seem to request a handle with
"all" privileges, while it would actually needing at most "read"
and/or "setinfo" privileges. Very often they won't even make use of these
privileges, but still request them "just in case". While this is somewhat bad
programming, it normally doesn't hurt - but now it does. Well, to a certain extent that
is: If you block the privileges that the program doesn't need (and usually common sense
is quite sufficient to tell if a program needs to have the right to terminate programs
you want to have protected), that program usually will just continue to work as usual -
it won't notice that the request wasn't successful, because it really doesn't need it.
But it will generate lots of log entries. (Imagine that the program in question tries
to get such handles every 2 minutes on all active processes, 8 of which you have
protected. That will result in 120 lines in your log in only half an hour.) It will
soon become difficult to read your log to find out if there is really sensitive
information. The only way to prevent this (until DiamondCS include an option not to log
certain things) is to allow the program to get all the privileges it is requesting -
which then applies to all protected programs. In other words you trust it not to mess
in an improper way with any of those apps so dear to you that you have included them in
your list of protected processes. IMHO, which way you prefer depends on the program in
question: generally I wouldn't grant a program privileges it doesn't really need, but
there are programs - like my virus scanner - which I grant all the privileges to.)
Finally you have assorted other options that pertain to an entry in the protected
programs list: you can allow it to create global hooks (i.e. routines that are called
when certain events occur, no matter if the program actually has the focus or not. This
is mostly used for creating mouse and keyboard hooks, for example to set a keyboard
shortcut (that is supposed to work also when the program doesn't have the focus), but
also to install keyboard logging routines.
Similarly you can allow your program to install drivers, and thereby gaining access to
really really really central parts of your Operating system. Where Process Guard is.
The only place where ProcessGuard can be defeated. Only very few apps need this, but
some legitimately do.
These two options overrule the general protection options 3 and 4 for that specific
program, and thus only make sense if you have those general options enabled. They
can be accessed via the "Protection" menu entry and can be seen here:
Generally, if you don't know how to handle these things, start by disallowing
everything and see if your program still works as expected. In most cases it will. In
other cases, you know what's going on and can allow certain things without having to
worry much (i.e. you will most certainly allow your screenshot capture application to
create global hooks). Finally, if you find that your program obviously wants to do
something sensitive, but you don't understand why, then ask the developer what the
thing is trying to do - and actually this applies regardless of whether the app still
works when you block the attempt or not (but admittedly it's a bit more urgent to get
that information in the latter case).
You also have the option to add "Close Message Handling" to that specific
entry. This is again something very clever, but also very difficult, still providing
room for improvement. Again, a bit of theory first:
At a certain level, you call Windows an event-driven environment: programs (often) do
nothing until a certain event occurs. Frequently those events are not handled by the
program itself, but by the OS - timeouts, mouse clicks, clipboard pastes, window
resizings and whatnot. The program puts up a loop so that a queue of events is polled
regularly. When the event occurs, the OS sends a message to that queue and when the
queue is polled again, the program is made aware of that a certain event has occurred
and can react on it. Of course, what is of interest to us is the type of events that
makes the program exit by its own. A mouse click on the "x" button in the
titlebar of a windows program makes the OS send such a message to a program, and there
are others such "Close Messages".
Now, when the program receives a message from the queue, it hands over command to the
event handling routing that corresponds to the type of event. You'll notice that in
carefully crafted security applications, the close message handler will ask something
along the lines of "Do you really want to quit?", whereas the standard
behaviour is to ask "Do you want to save your changes?", but to just silently
quit if there isn't anything changed and/or needing to be saved. Unfortunately there are
also a few security apps which simply use that standard close message handling routine.
The problem is that there is no way for the program receiving a close message from the
message queue to determine whether or not this close message is legitimate - another
program can have sent the message just as well as the OS. So that other program can very
easily simulate the user clicking on the "x" button or pressing
"Alt-F4" etc. In theory (and, up to now, in proof-of-concept exploits), the
malevolent program can just as well simulate the user clicking on the "Yes"
button of a somewhat more clever close message handler's confirmation prompt "Do
you really want to quit?"...
This is where PG's CMH (Close Message Handling) steps in: It catches all types of close
messages and regardless of what close message handling routine the protected program
uses, pipes the message through its own human confirmation prompt:
In order to counter the malware just simulating the user confirming the prompt, that
confirmation has to be made not simply by clicking a button, but by typing in a randomly
generated character sequence that is presented as a picture (to prevent another program
just reading the box's text/caption) and obfuscated by some noise and moving around (to
prevent easy capture and OCR on it). Very sophisticated if you ask me. (Also remember
that on a properly configured system, the malware won't be allowed to read PG's memory
space, so it can't even extract the string relevant to the comparison from there.)
But there's nothing without a drawback: There are actually a lot of apps that use such
close messages to destroy many elements of their user interface when they really quit.
If you have such an app, and you have CMH enabled on it, and you really want that app
to close, there are generated lots of those messages in the process of it shutting down
and cleaning up (destroying preview windows, document tabs, systray icons, icon bars
etc. etc.) - and lots of human confirmation prompts. Some programs even use close
messages when they're not even exiting, but merely want to destroy their splash screen,
swith views etc. Then you'll get unexpected human confirmation prompts in the middle of
your normal work with the program. Finally it seems that for some programmes that use
lots of these messages in shutting down, when CMH messes with it, the messages somehow
get confused and you end up with a program that doesn't properly shut down anymore.
PG caters for some of the issues by having the human confirmation prompt optionally
confirm "all" close messages, but this doesn't work all the time and for all
the issues mentioned above. So the bottomline is:
Use it wisely and rarely. While it is a powerful protection method, don't count on it to
suit your apps. Use it only on very important security apps that don't do a proper CMH
on their own - and try how it works with those (esp. if you consider this feature to
be an important selling point and you haven't yet made your purchase decision).
As has been discussed above, the process protection part of ProcessGuard only
protects your security apps when they're running. When they're running, no malware
can come along and disable or tamper with a protected process in any way. That is
a bit different for the program files as they are saved on your harddisk (or
wherever): A malware can perfectly come along and modify the program file of your
virus scanner and the next time you run it, the "hacked" version is being
executed and will get all the privileges to scan and terminate that you have
specified in PG's Protection List. (Clever Virus Scanner do a self-check to prevent
this, so it's (again) an arms race between self-checks and malware patching that
very self-check routines when they're already at it.)
Again, ProcessGuard has something in store for you there: it keeps a list of
checksums so that it can determine if a program has changed since you've specified
how it should be dealt with "last time".
Two more upsides, and one downside:
As you can guess from the screenshot, this checksum protection applies not only to
protected programs (PG program protection tab protection, that is), but to any one.
Every time you launch a program that hasn't been launched before, you'll be asked
if this program should be a) allowed to launch just now, b) allowed to launch every
time, c) blocked just now or d) blocked every time it's being launched:
The same applies of course for programs that have changed in comparison to the
stored checksum:
Now the downside, tho: Actually it's not a downside but a missing feature - checksum protection as of now only applies to executable program files, not dlls, activeX controls etc. I have discussed this above (the "DLL hell" part), and I don't know whether or when DiamondCS will extend that protection on other files containing program code...
Let's start from the right for a change:
The options menu allows you to select a color scheme (the strange colors in my
screenschots result from the reduction to 256 colors, don't worry about that, the
schemes all look very nice), to enable/disable/view and clear the window log
(that's what you see in the log view/tab) and the log file - and to specify the
path to the logfile. You can also have PG's systray icon flash when there's
something going on - you'll see what has happened in the log window (if you've
enabled the window log).
Besides dis-/enabling all protection measures with a single click and saving your
list of protected programs (process protection entries, not (yet) checksum
protection entries), the protection menu provides access to general protection
options, i.e. those that do not pertain to a single program; and to tweaks that
let you handle the full power of PG's checksum protection.
I have discussed the items 3 and 4 above, here's what 1 and 2 do: (1) Interestingly,
windows' own TaskManager uses none of the mentioned methods to terminate a process
when you click on "End Task" ("Kill Process" uses the
TerminateProcess() call mentioned above), but a completely different approach, which,
apparently isn't used anywhere else. In order to prevent malware from some day using
this EndTask method, you can disable it, but only for your computer wholly and
completely, without an option to overrule this restriction for some occasions.
(2) There's a registry key that makes windows load what is specified there as a dll
into all newly launched programs. Since one of PG's main motivations is preventing
the more or less forcefull injection of dlls into protected processes, you have the
option to disallow new entries to be added to that key, and this to prevent new dlls
from being loaded into every single started program.
Besides dis-/enabling this cool feature, here's two things to make your secure life
with it easier: You can enable a "learning mode". When in that mode, every
program launch is allowed and registered as legitimate. This way you can build up a
list of allowed apps along with their checksums very quickly. "Learning
mode" thus is a nice thing to use right after installation of PG (provided
you've made sure that your system is clean beforehand), and it can be disabled either
manually or will be disabled when you log out.
(Note how learning mode only extends to learning apps/checksums that can legitimately be launched, not to granting them special allowances.)
When you have a good list of allowed apps together, you can also take the opposite
way: not allowing everything that's not explicitly blocked, but blocking everything
that is not explicitly on you list of allowed application. Then, new or changed
programs will not generate a prompt, but simply refuse to launch. You'll get an
error message by your OS:
and a log entry telling you more:
The file menu gives you a way to quit PG's user interface (just the user interface - protection remains the way you have configured it!), and to lock ProcessGuard with a password to prevent any change to the configuration:
Note how the user interface disabled anything but the log view and the unlock menu entry:
Here's the unlocking prompt, then:
Of course, the most interesting part of the review - besides the screenshots - is to see how to configure it well. So I will describe my approach to this here, too.
With this setup, nothing can mess with your vital system processes nor with your
security apps, nor with your firewall, nor with those apps that can communicate
through your firewall. No communication that you didn't authorize will leak, no
illegitimate or illegitimately changed apps will run.
But you still need a firewall to take this to its end, and you need a virus scanner.
Why? The problem are programs that are launched by mistake. Suppose you've
downloaded some program and want to launch it in good faith - you'll tell PG to at
least allow it this one time to launch. It will not be able to intrude into your
system internals because you didn't give it permission to access your central
processes, to install drivers or hooks etc. But it can read personal information
from your harddisk and send it out into the internet, if you don't have a firewall
that allows such communications only to a restricted set of programs (like your email
program and your webbrowser). It can delete or infect all sorts of files on your
harddisk (in the first case your system might become unusable, in the second case,
at least the infected files will be stopped from running when they're executable
files - which can in turn lead to an unusable system), if don't have a malware
scanner that can prevent this by recognizing the malware and correcting your mistake
of trusting that program.
Remember two things: my taking part in a partner program which might generate some
small reward if you decide to purchase PG via
this
link, and, more importantly that this my taking part is motivated to a very
large extent by the excellent support and the general friendliness of the people
at DiamondCS and on the BBoards. You should make a habit of visiting those boards
regularly and just posting there anything that comes to your mind - well pertaining
to DCS products and security in general at least. Here are the boards again:
PG forum at Wilderssecurity.com
DiamondCS-hosted Forums
More DCS forums at Wilders