DEP vs. Comodo Memory Firewall

View previous topic View next topic Go down

DEP vs. Comodo Memory Firewall

Post by Binky on 12/11/2010, 19:02

DEP and the Comodo Memory Firewall (CMF) protect against (some) buffer overflow attacks. See
http://en.wikipedia.org/wiki/Buffer_overflow

The separate CMF application has been discontinued, as it is now part of the Defense+ component of Comodo Internet Security (CIS). Download CMF here:
http://www.snapfiles.com/get/memoryfirewall.html

You can test your PC's buffer overflow protection with this application:
http://forums.comodo.com/comodo_memory_firewall_beta_corner/buffer_overflow_testing_application-t12541.0.html

From the good old days when Comodo developers posted in their forum...
From http://forums.comodo.com/frequently-asked-questions-comodo-memory-firewall/cmg-dep-t12237.0.html
Tyler Durden wrote:I've allready answered that question in other topic mate Smile Ok here we go again:
1. Software DEP is nothing but SEH chain validator (means it's not a DEP but some way to prevent one rare type of shellcode's injection)
2. Hardware DEP is very incompatible thing, that's why:
a) DEP mode by default is OptIn = all system services are protected, user apps aren't protected
b) DEP is _VERY_ incompatible thing so we 've got one more "layer" over DEP-mode - windows disables DEP for app which is know to be incompatible with DEP (this includes many checks, like exe-packers check and so on)
3. DEP-protection is vulnerable to ret2libc kind of attack (so you're not protected at all)

So we 've got CMG [CMF] Smile A fast and compatible way to be protected. It protects all apps against ret2libc and common BO attacks, and it doesn't treminate your favorite apps as well Smile

For the past couple of years, I have been using CIS without any exclusions (I haven't yet seen in the Comodo forum any user saying they needed an exclusion). When I used CMF with WinXP x86, this was my exclusion list to prevent incompatibilities manifesting as extremely high CPU:
c:\windows\microsoft.net\framework\v2.0.50727\cvtres.exe
c:\windows\microsoft.net\framework\v1.1.4322\cvtres.exe
c:\program files\java\jre6\bin\java.exe
c:\windows\system32\java.exe
c:\program files\exact audio copy 0.99pb4\dcrao\cdrao.exe

Hopefully, the latest Java doesn't need this exclusion. I configured CMF to automatically start with Windows. When a buffer overflow attack is detected, I configured CMF to "Terminate the application" and execute my custom file "C:\Program Files\COMODO\Memory Firewall\Notify.bat" containing:
Code:
@echo COMODO Memory Firewall closed a program with a buffer overflow.
@echo This could be an attempted attack or a program bug.
@pause
Here is how to configure Defense+ in CIS to just provide buffer overflow protection, which avoids pop-ups, restrictions or resource usage for other Defense+ features:
In the Defense+ Settings menu, set the Defense+ Security Level slider to Training Mode.
In the Defense+ Settings menu, Monitor Settings tab, uncheck all boxes.
In the Image Execution Control Settings menu, set the Image Execution Control Level slider to Disabled.
In the Image Execution Control Settings menu, check the option "Detect shellcode injections (i.e. Buffer overflow protection)".

For older hardware PCs without hardware-enforced DEP, clearly CMF or CIS provides better protection than DEP. For PCs supporting hardware-enforced DEP, CMF or CIS provides additional protection against ret2libc attacks and better compatibility compared to DEP. CIS supports WinXP, Vista and Windows 7. I don't know if CMF works on non-beta versions of Windows 7. See
http://forums.comodo.com/comodo-memory-firewall-beta-corner/windows-7-cmf-t33737.0.html

I am considering replacing the full CIS suite with Sandboxie and one of the Comodo buffer overflow protections. Historically, many users experience compatibility problems with certain versions of CIS' Defense+ and Sandboxie. For example, some Windows XP users find incompatibility with Defense+ in CIS v5.0 and Sandboxie v3.50. After searching for user feedback on the Sandboxie and Comodo forums, I don't see any complaints about compatibility for the latest of the 3.14 and 4.1 versions of CIS. For the last month, I have seen no incompatibility for CIS 3.14 on Windows XP or for CIS 4.1 on Windows 7 x64. Note that I configured Defense+ as above to provide only buffer overflow protection. Archive versions of CIS are available at http://www.filehippo.com/download_comodo/

Please post your testing results with Comodo buffer overflow protection on up-to-date PCs, especially Windows 7.

Edit 1: added CIS config settings
Edits 2-3: added my last month's experience with compatibility


Last edited by Binky on 24/12/2010, 19:33; edited 3 times in total

Binky
Member
Member

Posts : 35
Join date : 2010-11-10

View user profile

Back to top Go down

Re: DEP vs. Comodo Memory Firewall

Post by ssj100 on 12/11/2010, 20:54


_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: DEP vs. Comodo Memory Firewall

Post by Binky on 12/11/2010, 23:01

Thanks for the links. I had seen one, but not the other.

I am interested in discussing your statement from http://ssj100.fullsubject.com/security-f7/buffer-overflow-bo-tests-t47.htm
ssj100 wrote:Finally, my own personal security setup/approach easily blocks/contains these types of attacks.
Based on what I see at http://ssj100.fullsubject.com/free-for-all-f4/ssj100-s-security-setup-t4.htm
you have the following layers of protection against a ret2libc-type buffer overflow attack:
1. Latest version of some browser
2. 32-bit Sandboxie
3. LUA+SRP
4. Drive snapshot

Since your documented setup does not include Firefox+NoScript, the ret2libc attack could come through a script (such as Flash) to penetrate your first layer. But even with Firefox+NoScript, trusted sites can be hacked and human operators make mistakes in trust, so the ret2libc attack can penetrate layer 1 anyway.

The reason you have layer 3 is because you don't have complete confidence in layer 2 (Sandboxie). With the start/run restrictions, Sandboxie will block running a new attack executable. But why would the ret2libc-using attacker go to the trouble and risk of spawning a new executable? Couldn't the ret2libc attack initiate a privilege escalation or other that bypasses your 2nd and 3rd layers? Once it gains kernel access, it owns you. Only your 4th layer provides some protection.

The main problem I see with your layers is that you allow ret2libc attack to execute completely. I propose that the following layers provide better protection against ret2libc attacks:
1. Latest version of Firefox+NoScript
2. Comodo Memory Firewall (CMF)
3. 32-bit Sandboxie
4. LUA+SRP
5. Drive snapshot

CMF terminates the browser or plugin process as soon as the ret2libc buffer overflow occurs, before it executes completely.

Thanks for creating this website and putting so much effort into documenting your investigations and conclusions. I look forward to further discussion on this topic.

Binky
Member
Member

Posts : 35
Join date : 2010-11-10

View user profile

Back to top Go down

Re: DEP vs. Comodo Memory Firewall

Post by ssj100 on 13/11/2010, 12:27

Binky wrote:Since your documented setup does not include Firefox+NoScript, the ret2libc attack could come through a script (such as Flash) to penetrate your first layer. But even with Firefox+NoScript, trusted sites can be hacked and human operators make mistakes in trust, so the ret2libc attack can penetrate layer 1 anyway.
I have used Firefox NoScript for at least 3 years, and never surf with Firefox without it - it's just a habit of mine. I use it mostly because it speeds up web browsing slightly by blocking "junk" scripts. I didn't mention it in my security setup/approach because I don't feel it's really necessary. However, I suppose it does give an added layer of security as a bonus. With regards to ret2libc attacks in the form of a script or whatever, read below.

Binky wrote:The reason you have layer 3 is because you don't have complete confidence in layer 2 (Sandboxie).
No, that's completely wrong. Clearly you have not read all my posts on this forum and across various forums (I don't blame you...I've posted a lot in my time haha). I have complete confidence in layer 2 (Sandboxie) and I have written many times that I could easily run as full blown Administrator with just Sandboxie as my only real-time security. To be honest, I only use LUA+SRP out of habit (just like with NoScript I suppose).

Binky wrote:With the start/run restrictions, Sandboxie will block running a new attack executable. But why would the ret2libc-using attacker go to the trouble and risk of spawning a new executable? Couldn't the ret2libc attack initiate a privilege escalation or other that bypasses your 2nd and 3rd layers? Once it gains kernel access, it owns you. Only your 4th layer provides some protection.
As you may be aware (you come across as someone who should), pretty much every single exploit that has been found "in-the-wild" or in the "real-world" involves the spawning of a new executable. Regardless, Sandboxie would still contain any exploit even if it didn't spawn a new executable. Give me a link that shows the latest version of Sandboxie being bypassed in any way - you won't find any, period. With regards to direct kernel level exploits, tzuk suggests that nothing can be done about those anyway (thus having regular image back-ups is always important in this "worse case" scenario).

Do keep in mind that this is all purely theoretical discussion too - show me a current kernel level exploit that bypasses Sandboxie + LUA + SRP + Hardware DEP. I emphasise "current" because it would be very difficult to test/reproduce "past" kernel level exploits against the relevant version of Sandboxie and Windows updates.

Binky wrote:The main problem I see with your layers is that you allow ret2libc attack to execute completely. I propose that the following layers provide better protection against ret2libc attacks:
1. Latest version of Firefox+NoScript
2. Comodo Memory Firewall (CMF)
3. 32-bit Sandboxie
4. LUA+SRP
5. Drive snapshot

CMF terminates the browser or plugin process as soon as the ret2libc buffer overflow occurs, before it executes completely.

Thanks for creating this website and putting so much effort into documenting your investigations and conclusions. I look forward to further discussion on this topic.
As you probably read in the links I provided in the previous post, I did ask the question of whether I should add Comodo Memory Firewall into my security setup. I clearly decided not to, as I don't see any significant benefits of doing so. Furthermore, there potentially could be harm in using another real-time security software with the risk of hidden conflicts etc.

Again, ret2libc exploits would be contained within Sandboxie anyway, even if a new executable wasn't spawned. However, I don't quite understand your reasoning of a new executable not being needed to be spawned - how would the malware do anything without some form of executable being spawned? As I understand it, the actual buffer overflow exploit simply allows new code to run. This new code must therefore be surely in the form of "execution". - eg. via remote code execution - Sandboxie would contain all this. Even if a privilege escalation exploit was used, this wouldn't affect Sandboxie (since it is third party software and applies itself equally well at Admin level).

To summarise and simplify, Sandboxie is all one really needs for Windows security if they follow a good security approach.

EDIT: by the way, welcome to the forums! I forgot to mention that before haha. I think it's very healthy to constructively scrutinise one's security setup/approach from time to time. My own setup/approach has manifested over the course of about a year (most of 2009) where I pretty much tried every single software out there. I've been running like this for over a year now and will probably never look back - I think for the "above average" user, it provides "100%" security in the "real-world" (and probably even in the world of "POC's") without sacrificing significant usability/convenience. I suppose this is why I keep using it!

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: DEP vs. Comodo Memory Firewall

Post by Binky on 15/11/2010, 09:05

ssj100 wrote:by the way, welcome to the forums!
Thanks! And thanks for the quick reply.

ssj100 wrote:I don't quite understand your reasoning of a new executable not being needed to be spawned - how would the malware do anything without some form of executable being spawned? As I understand it, the actual buffer overflow exploit simply allows new code to run. This new code must therefore be surely in the form of "execution". - eg. via remote code execution
Detail about ret2libc is at http://en.wikipedia.org/wiki/Return-to-libc_attack
The hacked browser or plugin can call a function that is already in memory or a function linked to a process already in memory (in a DLL for example). This does not involve spawning a new .EXE file.

ssj100 wrote:Give me a link that shows the latest version of Sandboxie being bypassed in any way - you won't find any, period.
Since I am not a hacker, I don't follow forums that discuss exploits not yet patched. I am new to Sandboxie, so I don't have a historical perspective about how often vulnerabilities are found and the delay until a patch is issued. Perhaps you could comment on this.

For several years, I have been reading the release notes of each update of Firefox, Flash Player and QuickTime. The publishers are responsive when vulnerabilities are found, but the number vulnerabilities found and the frequency of updates is shockingly high. Buffer overflow is the most common vulnerability found. So without any specific links on current vulnerabilities, my historical perspective prevents me from being over-confident in any internet-facing application (I am not including Sandboxie as internet-facing). My historical perspective also predicts buffer overflow as being the most likely vector for vulnerabilities to be discovered in the future.

If we assume for the moment that Sandboxie cannot be bypassed, ret2libc attacks can cause much harm while contained inside the sandbox. This harm is in the form of privacy leaks instead of what some people consider security breaches. Here is a scenario:
1. You visit a trusted site that has been hacked with a script containing a ret2libc attack.
2. The ret2libc attack silently modifies the Firefox profile such it monitors all user input and internet traffic from other sites.
3. Before you clear the sandbox, you visit your banking site, and you (or your password manager) enter your password.
4. Your personal banking info is sent to the attacker (in Russia).
5. The attacker accesses your account, transfers money to a "money mule" in your country, who transfers it (less commission) to the attacker.

Another scenario involves the ret2libc attacker reading every personal data file to find info to steal your identity.

A defense against these attacks is run CMF or CIS' Defense+, which terminates the process attacked by ret2libc before it does harm. My guiding principles are to block attacks before they fully execute and to inform the user that there is a problem. If Sandboxie is my first line of defense, I get no indication about an attack site, so I don't know that I should empty the sandbox, restart the browser and avoid viewing the site in the future.

I have 32-bit Windows XP now, and I will soon purchase a new PC with 32-bit Windows 7. Since CIS users complain about compatibility with Sandboxie, I am hoping to use CMF with Sandboxie instead. I already have experience with CMF working well with Windows XP. I would greatly appreciate feedback from Windows 7 users about CMF compatibility.

Binky
Member
Member

Posts : 35
Join date : 2010-11-10

View user profile

Back to top Go down

Re: DEP vs. Comodo Memory Firewall

Post by ssj100 on 15/11/2010, 09:25

Binky wrote:Detail about ret2libc is at http://en.wikipedia.org/wiki/Return-to-libc_attack
The hacked browser or plugin can call a function that is already in memory or a function linked to a process already in memory (in a DLL for example). This does not involve spawning a new .EXE file.
"Executable" code doesn't have to be in the form of a .EXE file. Sandboxie should still contain any "executable" code, including DLL's etc.

Binky wrote:If we assume for the moment that Sandboxie cannot be bypassed, ret2libc attacks can cause much harm while contained inside the sandbox. This harm is in the form of privacy leaks instead of what some people consider security breaches. Here is a scenario:
1. You visit a trusted site that has been hacked with a script containing a ret2libc attack.
2. The ret2libc attack silently modifies the Firefox profile such it monitors all user input and internet traffic from other sites.
3. Before you clear the sandbox, you visit your banking site, and you (or your password manager) enter your password.
4. Your personal banking info is sent to the attacker (in Russia).
5. The attacker accesses your account, transfers money to a "money mule" in your country, who transfers it (less commission) to the attacker.
Yes, I've thought of this too, and that's why I am an advocate of using 2 separate browsers - one for "normal" browsing, and another for "sensitive" browsing like online banking. If you read my security setup/approach post carefully, you'll note this in steps 7-9 under "Sandboxie":
http://ssj100.fullsubject.com/free-for-all-f4/ssj100-s-security-setup-t4.htm#16

I personally use Firefox for "normal" browsing, and IE 8 for "sensitive" browsing. Every time I exit IE 8, the "IE 8 sandbox" automatically deletes itself. In this way, every time I run IE 8, it will always be as if I'm using a freshly installed version of it. If you're paranoid enough, you can make sure you close down (or delete) your "Firefox sandbox" (and all other internet-facing sandboxes) prior to launching the "IE 8 sandbox" to carry out eg. online banking. In this way, any malicious code running would be terminated and you can safely do your eg. online banking.

Binky wrote:Another scenario involves the ret2libc attacker reading every personal data file to find info to steal your identity.
Yes, I've thought of this one too. And that's why you would block all internet facing (and CD/DVD/USB-facing) sandboxed applications from accessing your sensitive files/folders. This is noted in step 3 under "Sandboxie":
http://ssj100.fullsubject.com/free-for-all-f4/ssj100-s-security-setup-t4.htm#16
Here's more information about it (under "File Access > Blocked Access"):
http://www.sandboxie.com/index.php?ResourceAccessSettings#file
In this way, any malicious code will be unable to read those files/folders and therefore identity theft would be impossible.

Hopefully you're probably starting to realise how powerful Sandboxie is, and why I like it so much haha.

Binky wrote:A defense against these attacks is run CMF or CIS' Defense+, which terminates the process attacked by ret2libc before it does harm. My guiding principles are to block attacks before they fully execute and to inform the user that there is a problem. If Sandboxie is my first line of defense, I get no indication about an attack site, so I don't know that I should empty the sandbox, restart the browser and avoid viewing the site in the future.
Well, now that you know a bit more about Sandboxie, perhaps you won't feel the need to use Comodo Memory Firewall.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: DEP vs. Comodo Memory Firewall

Post by ssj100 on 15/11/2010, 09:39

Binky wrote:I am new to Sandboxie, so I don't have a historical perspective about how often vulnerabilities are found and the delay until a patch is issued. Perhaps you could comment on this.
I've used Sandboxie since around April 2009. Since then (about 18 months), there has been one genuine and reproducible vulnerability - this vulnerability specifically involved the Print Spooler Service and required a very specific sequence of events (I can't recall exactly what they were). Regardless, this was patched very swiftly. From memory, there may have been another vulnerability that "Buster" discovered, but that's about it. It is incredibly rare to come across a genuine Sandboxie bypass. As far as I'm aware, historically, there have only been a handful of genuine bypasses in total. And as far as I know, if Sandboxie is configured with start/run restrictions in place, nothing has been shown to bypass it.

In my experience, Sandboxie's developer ("tzuk") provides some of the best (and fastest) computer software support out there. You can ask any Sandboxie user - he/she will most likely tell you the same thing. It really makes a difference when you can get direct support from the developer himself, and it's extremely easy to access this support.

I would recommend getting to "know" Sandboxie better - it took me several hours and some guidance from a fairly advanced user ("demoneye") to fully understand how it worked and how best to take advantage of all its configurations. But after some time, I was even teaching "demoneye" a thing or two haha. The beauty of it is that once it's configured, it's pretty much all "set and forget" (unlike eg. Classical HIPS).

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: DEP vs. Comodo Memory Firewall

Post by Binky on 22/11/2010, 03:08

To the first post, I added CIS config settings and a note about exclusions in CIS.

Binky
Member
Member

Posts : 35
Join date : 2010-11-10

View user profile

Back to top Go down

Re: DEP vs. Comodo Memory Firewall

Post by ssj100 on 22/11/2010, 09:06

Binky wrote:To the first post, I added CIS config settings and a note about exclusions in CIS.
I will probably be forever skeptical at using "exclusions" in a piece of security software in order to reduce chances of conflict with another piece of security software. The reason is that I remember a conflict I discovered (and many others) in 2009 where simply having CIS installed would cause Sandboxie to be "bypassed". Even if you "only" installed the Firewall component, Sandboxie would still be bypassed. The only way to get rid of the conflict was to completely uninstall CIS.

Anyway, do keep us up to date about what you decide to do with regards to DEP protection.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: DEP vs. Comodo Memory Firewall

Post by Binky on 23/11/2010, 23:59

I just installed Sandboxie, and I am learning how to use it.
ssj100 wrote:I remember a conflict I discovered (and many others) in 2009 where simply having CIS installed would cause Sandboxie to be "bypassed".
1) What are the other applications you found that conflicted with Sandboxie?
2) How did you test for Sandboxie being bypassed?

Binky
Member
Member

Posts : 35
Join date : 2010-11-10

View user profile

Back to top Go down

Re: DEP vs. Comodo Memory Firewall

Post by ssj100 on 24/11/2010, 09:15

To be honest, the conflict with CIS was while running a Sandboxie Beta version, so perhaps that shouldn't count? From memory, the conflict existed with not just CIS, but also Malware Defender, Online Armor, and pretty much every single Antivirus product out there (Avira, NOD32, Avast etc), even if you only installed them "on-demand".

The "bypass" was with regards to some POC/malware called "stop.exe", "stop2.exe" etc. When these were executed sandboxed, the computer would freeze, the mouse would freeze, and any running processes like explorer.exe would be terminated - the user would need to reset his computer in order to use it again. It was more of an annoyance POC/malware than anything, but tzuk eventually protected against it. However, this protection failed if CIS etc was also installed on the system.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: DEP vs. Comodo Memory Firewall

Post by Binky on 24/12/2010, 04:57

To the first post, I added my last month's experience with compatibility.

Binky
Member
Member

Posts : 35
Join date : 2010-11-10

View user profile

Back to top Go down

Re: DEP vs. Comodo Memory Firewall

Post by ssj100 on 4/1/2011, 11:05

Some interesting reading here.

From memory, wj32 is a programmer of some sort and from past exchanges with him, he seems to know what he's talking about.

What do people think of this comment?:
There's no way Comodo's ret-to-libc protection can cover enough functions to make it useful.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: DEP vs. Comodo Memory Firewall

Post by p2u on 4/1/2011, 12:13

ssj100 wrote:What do people think of this comment?:
There's no way Comodo's ret-to-libc protection can cover enough functions to make it useful.
He's right, of course, especially for x32 systems. You may mark certain areas of memory as non-executable, but it's just too easy to work around those mechanisms in a DefaultPermit environment. Although most discussions are highly technical, a Google search ret-to-libc protection may shed some light on this problem. There's nothing as safe as not running untrusted code on your computer.

Paul

p2u
Valued Member
Valued Member

Posts : 211
Join date : 2010-12-14

View user profile

Back to top Go down

Re: DEP vs. Comodo Memory Firewall

Post by Sponsored content


Sponsored content


Back to top Go down

View previous topic View next topic Back to top

- Similar topics

 
Permissions in this forum:
You cannot reply to topics in this forum