"Memory Firewall" Features- Good, Bad, Ugly

Hi All,

I'm curious to learn about your regard for and experience with software-based memory firewall functionality (e.g., Comodo Memory Firewall, Determina, CoreTrace, etc.). What does this mean to you?

What have you observed in various memory firewall implementations (no problems at all, false positives, software conflicts, effectiveness, reaction to attacks, etc.)?

With ASLR, DEP, 64 bit registers, and other mechanisms included with newer operating systems, what do you think of the value of memory firewall functionality?

What are you observing and reading about with respect to the quantity/trend of code injection attacks in the wild?

What do you consider the most notorious memory-based malware samples?

Considering what robust HIPS products can do regarding over-flow attacks that 'own' a process, or inter-process attacks, how would you characterize the state of the art? What approaches work, what does not?

I very much look forward to you insights, observations, and opinions. There are quite a few opinions within Blue Ridge. However, I view this thread like a mirror: we vendors need to look in them to see if our teeth have been stained by the company Kool Aid.

Cheers,

Eirik

P.S. I named a few vendors above to more easily communicate the issue. I wish to pick your brains on concepts and technology, not solicit negatives on other vendors.

 

I used to run Comodo Memory Firewall for what I remember being a couple years and although it never gave me any trouble, it also never detected anything (other than their BO Test application).

 

Eirik,

I do not think a memory firewall is an issue on the clienty side. Considering Windows7 has enough improvements to minimalise risk of it. What would be a much more logical extention of your products is browser hardening.

A simple application which sets the registry to maximise memory protection on Windows7 would be sufficient.

I have been playing with group policy and I am surprised how Internet Explorer can be hardened against malware (specifically spy- and adware), that providing a simple gui based application which sets these registry settings would be logical thing to provide on AppGuard client (solo) version.

Since most people do still use IE8 and most use Windows FW, same could be set for TCPIP settings and hardening (all Microsofts security advisories are an easy source for you).

When you are thinking of producing innovative lines of code, think along the lines of Trusteer Rapport and PrevX Safe Online, essential for me would be
a) protection of the browser process
b) keyscrambling
c) screencapture protection
d) browser in the middle/man in the middle variant
e) sensitive browser data protection (can be achieved through Group Policy, so make a smart/low code effort variant).

Think of it
a) providing limited user protection without the hassle
b) provide driveby protection
c) browser keylogger/modification protection
d) maximalising power of OS and browser by setting registry with a simple click (that is expert knowledge I am buying)
e) privacy setting option (because this is a per user setting and applies to all applications it is hardly useable)

Regards Kees

 

.
If memory serves the Comodo Memory Firewall was an app to prevent buffer overflows, which was integrated into CIS. More generally memory protection is improved in Vista/7 and can be further increased by turning on DEP for all applications (in XP too), so I don't know that there's any reason now to address this with third party apps. I've been known to be wrong though so perhaps others will weigh in

 

I recall that Windows XP DEP did not catch the BO techniques of the Comodo BO Tester.

 

Hi Kees,

Thanks for the feedback. We enable 'locking things down', such as web browsers, in the enterprise with our EdgeGuard software product line. We're reluctant to 'lock-down' consumer machines for a variety of reasons. Nonetheless, I printed your post for our chief software architect to read on the spot, fueling a pleasant conversation on what we ought to do to make the consumer web browsing experience safer, and what the browser vendors are doing for the same end. I guess one might summarize our conversation in that we intend to hit the hockey puck to where the browser vendors will be next year instead of where they are right now. The metaphor also applies to a prediction that inter-process memory injection attacks will trend upward.

Cheers,

Eirik

 

It's my understanding, however flawed, that DEP is limited by the extent that an application's programmers utilized the appropriate flags in their compiler to designate memory as explicitly data only.

I was just reading through the Microsoft Security Intelligence Report for 2H2009, something I do not recommend (much trivia, little actionable 'intel', in my humble opinion). The most interesting piece of information I found concerned 'browser-based exploits targeting Microsoft and third-party software' on Vista/7 computers versus XP computers. The 3rd party software on XP accounted for 40.8% of the exploits whereas on Vista/7 the 3rd party software accounted for 75.4% of the exploits (page 29). The balance of the others were exploits of Microsoft software, btw. I looked at this an wondered if it might be due to Microsoft more aggressively implementing DEP, ASLR, SEHxx, etc. than 3rd party software developers (e.g., Adobe---speculation on my part). Mind you, I could be way off here, but there it is...

Cheers,

Eirik

 

Eirik,,

Those stats are simple Win7 with all its memory/bufferoverflow mechanisms is responsible for a drop in vulnability. Third party vendors are not moving as fast, s they are still as vulnarable on Win7 as on XP, that is why 3rd party share has increased on Win7.

It would be very interesting to discover how BlueRidge engineers will deal with multi part (javascript) malware using omelet shellcode and library loading/bufferoverlflow vulnabilities of 3rd party software. Often their only goals is to use the elevated rights of those services to enforce some variant of a drive by infection.

So on seconds thoughts I can understand why you raised the question (adding a memory access filter to the existing file access/registry filter of AppGuard)

By sticking to the core competence of AppGuard (enforcing LUA and preventing Drive by), you would just have to expand this protection to 3rd party services.

 

Hmm,

Until the recent flash-pdf exploit I though BO were something of the past, since vista/windows7 have OS build in protection. Did some dark side browsing, see pic. I allways thought Xp victimes were people with unptached systems.

13 exploits prevented after 2 hours chasing illegal software and hitting porn sites

mhh still more relevant than I thought?

 

i read somewhere here on wilders,that this program is really buggy,and not in development anymore. if you want protection from BO,im still using Comodo memory firewall really light,easy to use,not noticable on system at all,and it gives me better feeling about my protection

 

I met with some folk in the US federal government for a couple of hours today. We discussed AppGuard: past, present, and future. I told one of them that I felt that memory based attacks (e.g., inter-process ones) are relatively rare. He then told me: 'that may be true in the general consumer market, but I see these every day'. He then went on to say, the 'higher value the target, the more sophisticated the attacks'. BTW, if we get samples from them, I'm CERTAIN we would not be permitted to share them with others.

The 'public data' on the prevalence/frequency of memory attacks in the wild seems quite sparse. I've found some relevant malware descriptions at vendor sites but little in the way of quantification of the malware in the wild. So, if you all have seen any 'quantification' of what's in the wild, particularly process hopping / code injections, I'd really like to look at it. We're seriously thinking about letting what we call 'MemoryGuard' out of the lab and into the real world. If so, I'd like to better characterize the risk/threat.

Cheers,

Eirik

 

Was there something in the GUI of this product that helped give you the 'better feeling about your protection'?

Eirik

 

no really. what make you think 13 exploit prevent. where is log. Show proof ok?

 

Yes comodo memory firewall seem nice. But it not develop any more or mean it inside CIS.

 

it is included in the whole package now

 

This sounds cool!

 

Erik like a firewall like for appguard?it will be cool

 

You right. I seen many buffer exploit out there. Surprise no program can block well except CIS it seem. the malware people test against their program are most not buffer exploit. That why their program pass. buffer exploit is out there not hard to find. need know how to programming to use though. And most program fail.

 

. . . where is log. Show proof ok?

 

Yes that is right, until recently the home user version of Wehnus did not work on
properly on service pack3. Now I seem to have the commercial version, which does work on XP SP3.

Whenus = ASLR plus CMF. So it does a lot more than CMF

I also thought BO was something of the past, because they are so difficult to cook up. So i do not know whether the 13 exploits are real?

 

There is ok? But if I post site I will be ban. May be I PM if you no more smart man ok.

 

As I say buffer exploit very common. One of most common way of infect. And by way if Wehnus does what CMF does then why it fail Comodo BO test ok?
http://forums.comodo.com/comodo-mem...ow-testing-application-t12541.0.html;msg88339

 

Conditional communication

Conditional communication settings may be defined by a user of a communications device to be transmitted with a communication to a receiving device, where the receiving device may be restricted from performing a user-specified type of communication operations with a user-specified contact until the conditional communication settings are satisfied.

Could you eloborate on the settings a bit more, I googled for smart men, but the results just confuse me

-http://www.youtube.com/watch?v=Y_SwKqCyX5o-

Regards Kees

 

I no know what you talk sorry. By way we can have poll to see how people block buffer attack? I search Wilder before and read Blue zanaetti post many year ago where he say he dont protect from buffer attack. Why?

 

Timestand,

I was just kidding. You told me that you would PM me when I was not being smart (wiseguy) any more. So you determine the conditions under which you want to communicate with me. I like open communication, also with people I do not agree with per se.

Why Blue problably does not care (I am inclined to agree with him).

On x32 systems with XP we allready have DEP protection. Vista/WIn7 have DEP + ASLR + SEH protection. With the latter it is nearly impossible to guess the offset of the code any malware has planted the malicious code (the 'egg'). So succesfully overwriting a return address does not imply a succesfull intrusion also.

Also these types of problems are only posisble when programming language does not provide build-in protection. Since the rise of buffer overflow attacks libraries have become available to in most used languages and programming standards have been adapted to prevent these vulnabilities. Since Vista forced code overhauls due to LUA/UAc concept, most respectable companies have rewritten their code on this aspect for Win7 now. The rise of x64 OS systems increases the problem for the attacker since a much larger address space is available (on x32 bits only 16 bits can be randomised, do the math how this increases the correct offset guessing problem)

Therefore for consumers the chances of being hit by a buffer overflow problem is very rare (IMO). Sanity on security sort of should match daily life. Flying has risks, yet I use airplanes without carrying a parachute as personal luggage. I just tried CMF and Wehntrust becasue Eirik thinks there will be a rise in memory/BO attacks. I was very surprised with 13 exploits prevented. Dont knwo whether it was real or a FP's due to program bugs.

Regards Kees