Do we need more than free Process guard if we do not indulge in high risk behaviour?

richrf · Aug 12, 2005

Re: Do we need more than free Process guard if we do not indulge in high risk behavio

SpikeyB said:

Thanks richrf, I had a quick search through the paper. I'm still not convinced that the change to the registry for the dll protection can be accomplished without something executing first (perhaps I missed the relevant bit, could you copy and paste the relevant bit or PM me thanks).
Click to expand...

Rich

Hi SpikeyB,

The issue that the paper is discussing is how processes can be initiated and doing work without the user ever knowing it. ProcessGuard warns of these occurrences: e.g. attempter dll injection, global hook acquisition, rootkit installation, etc. This is the part of the paper that discusses these issues.

Rich

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.
Now the trick is that, just like with TerminateProcess(), any program can call a function on another program that makes the other program load a dll of the 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 that 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 that are potentially allowed to send data out. Unfortunately, there are applications that are very common (like InternetExplorer or WindowsExplorer) that load really very many dlls even out-of-the-box (and even more with more software installed), and so that control is not only a venture into a territory which is 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. (Or, to have the infected machine act as a relay for spam mails where the trojan operator can send thousands of mails, and be paid by some crook for it, but never be traced back because the mails are originating on the poor infected user's machine.) Technically, that information retrieval 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 by the name rootkits: They mess with central system functions 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 intended, but on those core processes that even 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, data 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 deal with it by providing functions which put everything about a process into 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 latter question is of course, as anyone can easily guess: Nope.)
Click to expand...

SpikeyB · Aug 12, 2005

Thanks richrf.

I think that explains how PG will block things if you allow a program to run. It's not clear whether the nasties have to execute first, e.g. can program X call a function on another to load a dll or can program x take memory space without program x executing? I don't know the answer but I wish I did.

richrf · Aug 12, 2005

Re: Do we need more than free Process guard if we do not indulge in high risk behavio

SpikeyB said:

Thanks richrf.

I think that explains how PG will block things if you allow a program to run. It's not clear whether the nasties have to execute first, e.g. can program X call a function on another to load a dll or can program x take memory space without program x executing? I don't know the answer but I wish I did.
Click to expand...

ProcessGuard, together with other security products and/or techniques, seeks to cut off these tunnels at key junctures or "choke points" that are known to be exploited by malicious software. PG in particularly addresses some very important ones including the initial execution, installation of drivers and services, physical memory access . etc, which can cause havoc on a machine. TO what extent they are important to any individual's environment lies in the way an individual uses a system.

If new programs are not installed, or are only installed from trusted sources (assuming one trusts MS), then the free version may be all that is needed. In my own experiences, I have been pretty surprised by what some vendors are doing, and am glad that I was notified that the company was trying to isntall a driver/service, which I was able to stop. It is quite possible to avoid all of this stuff, by minimizing ones use of the Internet, and ultimately abstinence may be the best approach - from a security and life perspective.

Cya,
Rich

Palombaro · Aug 15, 2005

The thread is providing lots of useful info. It does reveal one problem though , i.e. to run the full version of Process Guard seems, to me at least, to require the user to make decisions which presuppose a relatively high level of knowledge on the part of the user. Most users , me included, just do not have this knowledge, neither do they have the time or inclination to acquire it.
I know that much of the threads in Wilders are in fact conversations between the expert or experienced and maybe this gives the impression that the full PG is more complex than it is . Is the average user really able to use it on the basis of 'look and click' or is the apparent complexity actually the case?

(I also know that when an 'innocent' like me asks questions in the forum they are answered generously and clearly)

Notok · Aug 15, 2005

Re: Do we need more than free Process guard if we do not indulge in high risk behavio

I know I've talked a bit about PG not being appropriate for all users, but I mainly reffer to the multitudes of users that have very little computer skills that are in the greatest need of security and come here when things get bad. It's all pretty subjective, really.. are you comfortable with the file system? That is, if you lost a shortcut to a program in the start menu, would you know how to go in through "My Computer" and start the program manually? More appropriately, if your antivirus detects something as a trojan, are you comfortable differentiating between an actual detection and a false positive? If you can manage that, then you might give PG a try, just read through the help file and you should be just fine.

Hard_Warrior · Aug 15, 2005

Palombaro said:

The thread is providing lots of useful info. It does reveal one problem though , i.e. to run the full version of Process Guard seems, to me at least, to require the user to make decisions which presuppose a relatively high level of knowledge on the part of the user. Most users , me included, just do not have this knowledge, neither do they have the time or inclination to acquire it.
I know that much of the threads in Wilders are in fact conversations between the expert or experienced and maybe this gives the impression that the full PG is more complex than it is . Is the average user really able to use it on the basis of 'look and click' or is the apparent complexity actually the case?

(I also know that when an 'innocent' like me asks questions in the forum they are answered generously and clearly)
Click to expand...

I felt very much like this when I initially installed PG. But I quickly found out that whoever writes helpfiles at DCS has a REAL touch for it. In the course of about 45-minutes I was able to familiarize myself with the ins and outs of PG, and was able to knowingly configure it for my circumstances. Don't worry, if I can master it you can too.

SpikeyB · Aug 18, 2005

SpikeyB said:

It's not clear whether the nasties have to execute first, e.g. can program X call a function on another to load a dll or can program x take memory space without program x executing? I don't know the answer but I wish I did.
Click to expand...

Does anyone know the answer to this?

Gavin - DiamondCS · Aug 20, 2005

Re: Do we need more than free Process guard if we do not indulge in high risk behavio

Originally Posted by SpikeyB
It's not clear whether the nasties have to execute first, e.g. can program X call a function on another to load a dll or can program x take memory space without program x executing? I don't know the answer but I wish I did.
Click to expand...

Without executing a trojan can't do anything. The only pure code attack seen is the SQL Slammer worm which was a small exploit of SQL servers. PG deals with executables, since thats where most threats are. Nearly all threats...

And no, there is NO way to execute a file without being hooked by PG and stopped from running. Learn the system with PG in a clean state then protect it and it will stay clean !

Dazed_and_Confused · Aug 20, 2005

Re: Do we need more than free Process guard if we do not indulge in high risk behavio

Gavin - DiamondCS said:

...Learn the system with PG in a clean state...
Click to expand...

A very important point.

SpikeyB · Aug 29, 2005

Re: Do we need more than free Process guard if we do not indulge in high risk behavio

Gavin - DiamondCS said:

Without executing a trojan can't do anything. The only pure ............
Click to expand...

Thank you.

Log in or Sign up

Do we need more than free Process guard if we do not indulge in high risk behaviour?

richrf Registered Member

SpikeyB Registered Member

richrf Registered Member

Palombaro Registered Member

Notok Registered Member

Hard_Warrior Registered Member

SpikeyB Registered Member

Gavin - DiamondCS Former DCS Moderator

Dazed_and_Confused Registered Member

SpikeyB Registered Member

Log in or Sign up

Do we need more than free Process guard if we do not indulge in high risk behaviour?

richrf Registered Member

SpikeyB Registered Member

richrf Registered Member

Palombaro Registered Member

Notok Registered Member

Hard_Warrior Registered Member

SpikeyB Registered Member

Gavin - DiamondCS Former DCS Moderator

Dazed_and_Confused Registered Member

SpikeyB Registered Member

Useful Searches