Threatfire's near-fatal flaw

Sounds exactly like what ThreatFire does to me. So unless you think Prevx in ABC mode is not good for novices as well...

 

TF also has a lot of FP on this area. Protection for any browser is irrelevant when using a policy sandbox like GesWall or DefenseWall.

I am not using TF or Mamuto anymore (got both lisences of TF Pro and Mamuto), behind DefenseWall now using Comodo with a trimmed down D+
- removed general file protection based on suffix and directory, replaced with specific files
- removed Internet Explorer Registry Protecton, added others (the same static registry rules as I used to add in SSM, EQS, WinPooch and TF)
- D+ only looks at new arrivals (executables) on hard disk and fires a pop-up when intruding specificly at Memory/Process tampering, Driver installation, Protected COM-, File- and Registry-settings and low level Harddisk access.

Mind you this is on the stable PC, the gamer PC (Vista64) still has a behavior blocker( PRSC). Comodo was a pop-up generator on the gaming PC, on the stable home PC it is quiet. I never was a Comodo fan, but what I could not accomplish with SSM and EQS has been realised with Comodo and D+

Funny thing is that D+ talkativeness in this setup really is not bad at all. TrojDemo for instance (TF fails on Level 3, passes on Level 4), generates in this setting 4 oranje alerts. Told my wife, well you can allow one orange alert, two becomes suspicious - allow but never choose remember, three stinks and please choose block. Never allow red alerts. Because of its dumb character, D+ has to make some differentiation in categorising threats.

 

The original question was, I believe, how to set Mamutu to behave equivalently to ThreatFire level 3. You responded that Mamutu could provide level 4 protection with level 3 FPs by setting paranoid mode and turning off protection for IE. Unfortunately this sounds to me like zero protection for IE, and level 4 protection + FPs for everything else.

A policy sandbox for the browser may make behavioral protection for the browser irrelevant, but it sounds like you need them not because they're superior to behavioral protection for the browser, but because you have NO behavioral protection for the browser (by turning off IE protection in Mamutu because it'd produce too many FPs otherwise).

Good luck with Comodo. It's not my cup of tea, though. It seems the developers just focused on writing something that flags on as many actions as possible; they still have a long way to go before they catch up with the design elegance of, say, SSM and EQSecure.

 

Ah you are up for playing time, so let's play then:

ad Bold 1:
Yep it leaves IE7's registry unprotected. We are using Opera and a Policy sandbox, so yes it is true, but not relevant (IE's registry settings not being ptotected).

ad Bold 2:
I have not encountered much FP's, as said no more than TF. May be it is the limited test set I am using. Bellgamin once dared you to publish this large collection of tests you had performed. You more or less admitted that would be a great idea. I think that would be a great idea also, so I rest my case.



Regards Kees

 

Not quite true, considering existing applications as safe is a nice idea. Not for a first line of defense, but for a second line (after a policy sandbox) it will do fine on a stable PC. In this context it is more an IDS than a HIPS which only evaluates newly arrived executables. I also outlined that I reduced the attack vectors which D+ monitors. This inevitably reduces the number of pop-ups for NEW applications.

Compared to Online Armor, Comodo still has a way to go. A few things really do not work smoothly at the moment (at least the individual parts of Pending files, Security Policy and Image Execution control work okay, but they should be integrated, so in this context I agree with you in regard to design elegance). Still I think it is a great feat to be the first to provide a Vista64 bits HIPS like functionality.

I am still a long way from being a Comodo fan, but you can not (at least I) deny the facts. They did an astonishing job with V3 in facilitating all XP and Vista platforms,

 

What security is superior is still an open discussion. When browsing Wilders it seems there as many opinios as there are members.

In terms of risk management, the ranking order is:
1. Stay out of risky situations, you won't need a defense when you are not attacked (e.g. site advisor)

2. Reduce the vulnarable spot/attack surface (e.g. UAC and Policy sandbox)
Reason why a lot of old fortresses are build in the loop of a river/hill top with only one or two access roads.

3. Control the attack vectors (traditional HIPS monitoring hooks/SDT), so you won't get hit. Normally a talkative and more user intervention required solution. Prevention is better than to cure will all the SSM, EQS, NG etc fans argue. In this category the FW and Traditional HIPS will merge into one solution (Online Armor, Comodo, Look & Stop)

4. Limit the damage/damage containment. In this category are Antivirus (although AV's providing Network and HTTP scanning are really ahead of things), Policy Sandboxes (because they remember the untrusted status of a downloaded file) and yes Behavior Blockers.

Using this scheme it is obvious that Policy Sandboxes like GeSWall and DefenseWall reduce the attack surface and limit the damage, while behavior blockers only limit the damage. That said Policy Sandbox do not need user interaction, Behavior blockers do need user interaction. So in this context a policy sandbox is superior to a behavioral blocker.

Do you mean this with you need them (sandbox) not because they're superior to behavioral protection for the browser, otherwise I do not get where you are pointing at, but feel free to explain

 

It is relevant as long as you're trying to answer my question, since that's what I asked. But if what you're aiming to do is to ignore that and just rant on about your setup, no, I guess it's not.

Not really sure what you're talking about. FPs have nothing to do with how much malware one sees. I don't like the amount of FPs TF has on level 4, but if you're comfortable with that ("not encounted much FPs, no more than TF"), hey, whatever rocks your boat, I'm cool with that.

Don't really follow you again; what am I denying, exactly?

As for astonishing, that can be interpreted both ways. As far as the Defense+ module is concerned, I can safely tell you I'm not impressed by it in a positive way. It's one of the least well thought-out HIPS at the moment IMO, but again, to each his own.

Your listing doesn't quite make sense. These three solutions are essentially identical. #2 and #4 are the same as #3, except with hard-coded internal rules.

You mentioned using Mamutu to protect IE is redundant because you have a sandbox. I'm just pointing out that Mamutu would (presumably) have done sufficiently even in the absence of a sandbox. The reason you need a sandbox is because you turned off your already-existing protection; and then you turned around and claimed that it wasn't relevant.

 

What is your question then?

You are always claiming things based on tests, but you never publish these tests. Bellgamin asked you once to do so, you said that would be a great idea, so publish them

I am refering to my limited test set. A decent test set also contains at least all the 'good' paths, not only error situations. So I am not saying anything on FP's and malware.

Nothing, is in regard to appreciation of Comodo

Against what criteria is it least well thought-out?

a.) not my listing = general risk/contingency management
b.) a policy sandbox reduces the attack surface, a behavior blocker does not
How can I spell it out to you. When you are a limited user, you are not allowed to go into places. With a behavior blocker you are allowed to go into places. So the domain to be secured/protected is much larger. The hard coded/soft coded difference is really a non-argument. Hard coded to my knowledge means a fixed hard coded condition clause in the program. Soft coded could be an external file (like the XML files of EQS or the custom rules of TF)

This is true

I think you are putting the horse behind the wagen. Look at the early test of CyberHawk (1 fail) and PrevX (4 fails). Policy sandboxes like GeSWall and DefenseWall (zero fails) clearly scored better in an old AV comparatives test. The simple reason why policy management, wil always outperform attack vector control and attack vector control will always outperform behavior blocker is that either the domain to be protected/guarded is less or the intrusion response is more straight forward. When SSM finds out that a program is a danger by setting a global hook, and it is not in the allowed list it simply says NAH. A Behavior Blocker still has to find out whether this intrusion is serious enough, to trigger a pop-up. When it allows the program to go through the defense is much more complex (should also undo the previos actions of this program). Larger Domain (e.g. User versus Admin) or a larger flow of events (1 intrusion versus two or three intrusions by the same program) will ineventenly lead to more complex coding and to a higher chance of errors.

As a matter of fact you acknoledged this yourself when running into a lsas problem which TF could not handle (DefenseWall does), since then you are running LUA

See these outdated and arbitrary tests http://www.av-comparatives.org/seiten/ergebnisse/HIPS-BB-SB.pdf and http://www.techsupportalert.com/security_HIPS.htm

Regards

 

Refer to posts 29 and 31 in this thread.

In the context of this discussion with you I have not claimed anything based on my tests. You seem to be pulling my tests into this discussion for no discernable reason; might I ask why?

Also, some things happened by surprise, and I'm now an engineering intern who toils away with ANSYS and AutoCAD 8am-6pm on weekdays. Kind of a stressed schedule, to say the least, so I'll have to postpone any plans regarding my tests indefinitely.

Again, you've definitely lost me here. You said that you haven't run into "much" FPs, perhaps based on your limited test set. Since when does one test for FPs using malware?

The grouping and categorization of its alert types and their respective necessities, ease and flexibility of editing or adding new/existing rules, rule creation to globally monitor a single specific process.

Wrong. Just because a specific brand X of behavior blocker doesn't include inbuilt rules to restrict you to "go places", so to speak, doesn't mean other brands won't as well. Nor does it mean that they're incapable of doing so.

Just take the example of loading a driver. A limited user is not allowed to access the OS kernel. A behavior blocker can easily limit you from doing the same, even though some products may not. Or different products might have different criteria to selectively block kernel access.

Keep in mind that the products you have used do not define the product class they belong in; i.e. the way one or two products operate does not represent how all others will, nor the limitations of the capability of all others. A behavior blocker can just as easily block you from kernel access as a limited user account does, if its vendor so wishes to. And therefore, in essence, they're essentially identical in theory.

I don't think I'm the one guilty of that; after all, you're the one with both products installed. I'm just pointing out where I found your reasoning to be a little odd.

 

Just to answer a point you added into your edited post.

As I mentioned above, ThreatFire and DefenseWall are single products and do not represent what their respective product classes can do. You seem to be implying that TF will never be able to stop this kind of attack even if its developers became interested in adding that functionality to it, while DefenseWall can; and these two single products and this one attack vector are evidence that sandboxes are superior to behavior blockers. Is that what you indeed intend to hint at?

 

Sorry to raise a bit OT, but what was this problem?

Thanks

 

Aigle,

I do not know what malware Solcroft has tested. Some malware is able to exclude/purge the admin by attacking lsass related files. GeSWall also protects against it. Running in Vista with LUA also does the trick.

Maybe Solcroft can PM you the details.

Regards Kees

 

By design a car will handle faster in slow speed corners, because a biker has to counter steer or weigh to the opposite of the corner, before the bike falls in. At a higher speed a two wheel design is superior, because of its reletavie slenderness (opposite of width) it can drive a more ideal curve at the same speed and the leaning angle compensates friction and wheel skid, then a car driving the same track. By design a car will always be able to reach higher speed on straights because 4 wheels will facilitate down force in a more stable way.

Conclusion
An average sandbox will always have the odds to be superior to an average behavior blocker, an excellent sandbox will have the better changes of being superior to an excellent behavior blocker.

It is dead simple a sandbox reduces the attack surface, so it will perform better. A hips reacts after one attack vector being violated, so it will have less trouble of stopping the malware to a halt. A a behavior blocker has to evaluate a sequence of actions, it will therefore will be harder to undo the things done by the malware.

You are dragging me into a discussion in which it seems whether I do not like or think highly of ThreatFire. Th eopposite is the question, that is why I posted the how to. The makers of TF have done an excellent job. Because it is so difficult to create a decent working behavior blocker. Ever wondered why the behavior blockers were the last guys on the block? Because it requires much more coding and knowledge to establish the same protection as for instance a classical vector based HIPS.

Come to think of it: I once posted custom rules for ThreatFire. TF will never be as good a vector control based HIPS as SSM or EQS or PS. Therefore they should abandon the development of custom rules and make it a install and forget HIPS. That would be the most clear and differentiating market position.

 

This is what attracted me to TF to begin with. I wanted decent quality behavior-based protection with minimal intervention on my part. I'm not against customization but I would never recommend or use it. If you want that, as you note, you're back to a more traditional HIPS. Which IMO, is not the same thing at all...

 

Unfortunately the difference between sandboxes and behavior blockers is not the difference between cars and motorcycles. More like the difference between automatic and manual transmission. I've already explained why this is the case.

Actually, no. I asked a question, which can be found if you refer to posts 29 and 31 in this thread (as I've mentioned).

Not really. Behavior blockers were the ONE OF THE FIRST guys on the block; this technology existed as early as back in DOS 6.0 as a TSR module in Microsoft Anti-Virus for DOS, and from what I've heard previous tools from before I knew anything about computers precede any known blacklist scanner. It was just that the malware landscape and techniques back then created selection requirements that favored simple blacklist scanners, which then became the mainstream.

 

Thanks Kees.

 

Your missing the point, what I told you that a car has relative advantage on some area's over a motor bike, on other area's the bike has an advantage to the car. Same applies to software set up from a different philosophy or architecture.

Sometimes approach A is better, other instance it is B. Have fun with your transmission.

 

You continue to ignore my arguments, and repeat that cars and motorbikes are different, as though it is somehow relevant to sandboxes and behavior blockers. I see no way to respond to that without stepping onto a wildly off-topic tangent.

So, er, have fun with your motorcycles?

 

Actually I do (occasionally race with a new one and am restoring a 25 year old motor bike). Are you enjoying the drawing/engineering? What is the company engineering if I may ask (transmissions )?

Regards Kees

 

It's always fun to be able to tell people someday later: "Hey, I was one of the guys who drew the site plans for that building." The work is enjoyable, the working hours not...

As for which company, it's just a local private company that does civil engineering work. The boss turned out to be the father of one of my high-school classmates, which I found out only one week into the job.

 

Can someone perhaps tell me what the discussion between Kees1958 and Solcroft was all about? I really don´t have a clue. Or is it something like Mamutu vs TF?

@Cerxes, can you perhaps give me a link to this Mephisto app, is it a new HIPS?

 

Rasheed,

Difference between security application which reduce
1) the attach surface (e.g. DefenseWall and GeSWall),
2) applications that control the attack vectors (e.g. SSM, D+, EQS) and
3) behavioral blockers (TF, PRSC, Mamuto).

Socroft and I had a different oponion on those three, my point of view
1) Attack surface reduction (less complex software, easy to use, very secure)
2) Attack vector control (average complex software - what to protect in the SDT, require user intervention, very secure)
3) Behavior blockers (very complex software - looks at a sequence of actions, easy to use, secure, but by nature less secure than the above)

Regards