Discussion in 'other firewalls' started by Mr. Y, Jan 15, 2007.
Or is it still user "unfriendly"?
Yes, what does it matter, that is the best firewall out there, if its maintenance is a horror.
Yes, but the concept is appealing though...
Just curious, for those of you who have used, or are using this program; what is the memory footprint?
i tried coreforce and the memory footprint for me is 30+mb...
I have been trying it out on one of my hard drives for last 2 hours. The learning curve is steep but much easier than the last time I looked at it- I think I'll keep it on one of my hard drives.
It has a lot of potential! Once I have figured it out I may put it on my other hard drives.
I use Core Force. It's not for newbies and it's not meant to be, and it will never be. So what? I'd rather spend time configuring Core Force than wasting money on some dumb so-called 'security' suite that only gives a false sense of security. If configured correctly, Core Force makes a machine almost a fortress.
It might not be the "ultimate" thing, but there's no better lockdown utility than Core Force, IMHO.
Indeed, that seems to be the case TNT. Not forbidden to newbies, but time-consuming?
It can adopt pre-built rules , or is this a drop in the ocean when configuring it? Besides the fact that you're not in control of these rules, of course.
Pre-built rules are more like a starting point, because you most likely won't find them for all the programs you SHOULD 'lock down'... but the learning wizard is very useful, especially for the filesystem and registry rules. Knowing at least the basics about TCP and firewalling is mandatory, though.
IMHO what Core Force is really lacking is a very good pdf (or online) documentation that goes through all the configuration steps and would make it 'easier' (though still time consuming) for "newbies" who wouldn't mind spend time learning and configuring. Because really, I can see many users being puzzled by it (because of how different it is from the "accept rule/deny rule" personal firewalls).
Yes, reading material would do wonders for Coreforce.
Another question for you TNT: this image suggests that we can answer pop-ups and set rules as we go ("add permanent rule"), like HIPS. But i have that feeling that it's not like that.
It's like that, but it has to be done per-application only (meaning that you need to have defined your set of rules and policies for the application that's "asking"), otherwise they fall into the 'system-wide' policies, and that's a bad idea (since any application then would be able to execute that action).
Basically, every application for which you enter a configuration set would then run with its own set of restrictions that are complementary to the regular filesystem/registry permissions (meaning that they do NOT replace them). The entry on wikipedia explains it pretty clearly: http://en.wikipedia.org/wiki/Core_force
Thank you TNT. Now i get it
A question for SSM users: have you tried this? This sounds fantastic for control. And it's free!
Are you also seeing 30+ MB memory utilization for this program?
Yes, it's pretty heavy on resources.
Yes, I tested it some months ago and found it promising at first glance. However I quickly found out it lacked one of the most important features of any HIPS: process protection. CF can't prevent a process from being terminated or modified by a malicious program. While features like file system protection or dll load control are nice to have all this is almost useless if malware can easily break out of its process boundaries and e.g. inject its code directly into the memory space of a trusted system process. Unfortunately this has not changed as per the tests I made with latest version. Therefore CF's HIPS or sandboxing features must be considered weak and CF far from being a "fortress". Another negative point in my opinion is that it slows down the machine a lot. Bottom line is CF has indeed potential and the right approach in many areas but is still incomplete and has long way to go until it arrives where Tiny Firewall was already 3 years ago.
You're missing the point here: a program protected by Core Force can't execute or write files and registry entries arbitrarily: if an exploit is run against, say, IE6, it won't be able to launch the payload, NOR to modify the registry and filesystem to deliver that payload, because its actions are limited in the first place: it can only write files in, say, the IE cache and the IE cookies folder, and write to the 'download' folder, and won't be able to execute any of these files. It won't be able to modify the system libraries it's using, because it can only execute them and not write to them. It won't be able to execute files in the temp directory, because it doesn't have the permissions to do so (execution in temp is only prompted). The ONLY way to by pass this protection would be to get kernel-level AND be able to bypass Core Force's kernel driver AND execute an arbitrary action, how do you accomplish that on a userland program if it can't even launch an arbitrary file (and yes, dll's and .sys files are executables as well).
So true, it doesn't protect files from being terminated, but prevents the files from being run in the first place. The termination process protection (if Core Force is configured properly) is therefore useless.
No, the one who is missing the point is you: There are ways to inject code into processes without writing something to file system or registry as I said. As long as there is a trusted process running in machine (and you will always have some like windows core processes csrss.exe, smss.exe, etc) it means malware can abuse this one to do everything on its behalf.
Oh yea, too bad that if there's a trusted process that executes at kernel level or uses global hooks, application protection against it is useless anyway. If there's an exploit against, say, the antivirus or anything that works at kernel level, there's no way to stop it. IceSword, for instance, can terminate any kind of 'kernel' process protection you have, and that includes Process Guard, Sandboxie, anything. You can't protect against against malicious action done by these.
Here's what ivan from their crew said about this:
So in short, yes, it's possible... to think this is easily doable is really far reaching.
The mentioned ones were just examples and they do not "execute at kernel level" more than any other process does (switching CPU to kernel mode btw is normal thing in the course of most Win32->ntdl.dll->... API calls). While they are so called "native processes" they still are normal userland processes. Anyway, they were just examples...
IceSword can do this only from its kernel mode driver, not the user mode part.
Right, but you can't bypass CF's kernel protection on 'user mode' only either. I think (I might be wrong, uh) that your attack example is really, really unlikely. You're talking about infecting a system by exploiting bugs in an 'untrusted' program, then injecting memory into a 'trusted' program that hooks kernel memory, and terminate CF from there, without actually writing anything on the filesystem... am I right?
Yes you can. Abuse trusted processes that have higher privileges.
That's not what I had in mind, but even that is not unlikely as it requires only one step more. My scenario was not mainly about exploits for browser vulnerabilities, but a program that user downloads from internet which is infected by unknown malware, maybe a new trojan. When run, this can inject its code into other processes which have privileges to do what it needs to do in order to carry out its evil business. Depending on what it is, it does not necessarily need to disable CF - it just bypasses it by doing its actions from other processes. In fact code injection is simple as source code is publicly available, not only on black hat hacker sites. Many trojans use such stuff and it is not far fetched at all. To make the same work in a exploit of vulnerability in some network enabled program is just one step more in the beginning.
I'm not sure exactly how exactly you intend to protect from this and how you think process protection does?
Right, this is possible, but that's far beyond the point of Core Force or any other similar utility.
Core Force is a lockdown system to prevent bugs in applications to deliver and execute the malware, not to prevent the malware that's already on the system to do damage when it's being run. In fact, it's unlikely that one would create "restrictions" configurations in CF for the malware itself in the first place, so the presence of Core Force would not make any difference (the malware would run with the "system" profile reserved for trusted applications).
I just installed CF current release on another Image and using between 14 and 23mb of memory.
As I understand version 0.95 has a generic sandbox for trusted and untrusted apps.
And has the ability to run a unknown app in the untrusted zone without writing or deleting anything on your computer.
Also it passes the ShieldsUp test and all the tests at PC Flank except the browser test on default (out of the box) settings. I did notice a little bit of a slowdown of loading pages while browsing compared to my favorite firewall Jetico 2.
I did uninstall Jetico before installing CF.
CF does have a steep learning curve.
Prevent writing to process memory or creating threads in other processes e.g. by blocking relevant API calls.
Almost every other sandbox/HIPS prevents from tampering with trusted processes - for good reason. Processes are also some kind of resource - just like file system or registry.
Again, to do the same in the context of an exploit for a known vulnerability is not more difficult than if user runs an infected program manually. It remains a big conceptual weakness if that is by design and not fixed sooner or later.