Maybe parts of Comodo and OA?

[Atnodirlee]

I find all the security stuff to get way over my head, all the different types of attacks and how to know if what I have is full coverage or what.

So one thing I want to know is if I am going for free versions, at least to start, it looks like Comodo has more protections than OAfree.

What does Comodo (firewall and def+) and OAfree protect against that the other does not?

And I like the run safer idea in OA, so, would it be good to use some parts of OAfree and some of Comodo, and what stuff from each should I then turn off as no need to have 2 trying to do same thing.

And if the only thing oafree has extra is the run safer, is there something else better to use to do that (not "drop my rights" but a real program) that would work well with comodo?

Thanks.

(for info: i have a new Vista laptop and am also trying avast for the AV and trying returnil. of course I don't want too much resource use but just a good set-up that covers all bases like this).

[Stem]

{QUOTE-> so, would it be good to use some parts of OAfree and some of Comodo, and what stuff from each should I then turn off as no need to have 2 trying to do same thing. <-QUOTE}


Hello,

It is not advisable to install 2 3rd party firewalls, low level driver conflicts can take place. Caution is also required when thinking of installing 2 real time HIPS as if both those HIPS are hooking the system and attempting to intercept the same internal action, then problems can arise.



- Stem

[twl845]

From one who has used both Comodo and OA (not at the same time) I would recommend OA in your case following your comment "over my head". OA is engineered for the rest of us as well as the techies.You can run it in standard mode and be fine. After using it for over a year, I can vouch that it protects you as well as or better than the other firewalls. 8)

[Atnodirlee]

oh so not even installed with certain things turned off so no redundancy because you are saying the drivers can still conflict.

well, 1 reason I don't want to buy software at least before a good trial is because of all the times I have and they have done more harm than good (like mcafee and norton i learned to stay far away from the hard way.) It is like paying for a mess too often.

Yeah OA seems easier to understand than comodo for me, like the layout better, but it still has issues (like a service problem it had in version 3 on xp that I had tried and I see here that the color border won't stay on the run safer, so maybe it is not applying the limited rights? I don't know.) So I'm waiting for the next release anyway, but the free version has some protections disabled, so I figure Comodo is better (although wow these popups...) because I guess it covers any of the protections OAfree has disabled???


Question:

So with using Comodo, what can I add for an easy drop rights or any other specific things that Comodo doesn't cover to fill the gaps?

thanks.

[Kees1958]

OA does run the applications as run safer, only some (I guess) java/J2EE based applications (like Limewire and Chrome) are not shown with the coloured border.

Give OA a serious try, Comodo requires some more knowledge, although the freeware version offers more buttons to play with (than OA) and tune your setup.

[nomarjr3]

Do NOT use 2 or more firewalls at the same time. Software conflicts can arise and do permanent damage to your system's hard drive or registry keys.
It is advisable that you use only 1 firewall to run in realtime.

The difference between COMODO and OA to most other firewalls is they both have built-in HIPS. HIPS gives you control to allow or deny the programs from running/executing.

Yes, COMODO's D+ is more comprehensive than OA's built-in HIPS.
In fact, I believe it is THE most comprehensive HIPS available in the market right now.
It even has anti-keylogger capability, and protects from buffer overflow attacks.

But for newbies/non-techies, I suggest you use OA. Its HIPS may not be as comprehensive as COMODO's, but the protection is top-notch nonetheless ;D :thumb:

[alex_s]

{QUOTE->
Yes, COMODO's D+ is more comprehensive than OA's built-in HIPS. <-QUOTE}

This is hardly Comodo is more comprehensive, it is rather more settings-packed, but this is natural, cause OA's goal is to keep it as simple as possible. I'd say it is even opposite, for Comodo still do not show you commandline parameters and fails to intercept entry point infection, for example. Also it doesn't use parent-child rules. I mean if some dll is run let us say using rundll, Comodo applies the rules for rundll, while OA applies the rules depending on the dll that is launched.

[Iam_me]

{QUOTE-> This is hardly Comodo is more comprehensive, it is rather more settings-packed, but this is natural, cause OA's goal is to keep it as simple as possible. I'd say it is even opposite, for Comodo still do not show you commandline parameters and fails to intercept entry point infection, for example. <-QUOTE}


hehe? ********? What good would commandline parameters do? Don't claim it adds anything securitywise.. Comodo has so much others that OA lacks.. Eg Buffer overflow protection, "probably" better interception, its technically #1 at matusec, but has not paid for a retest as some others have..

{QUOTE->
Also it doesn't use parent-child rules. I mean if some dll is run let us say using rundll, Comodo applies the rules for rundll, while OA applies the rules depending on the dll that is launched <-QUOTE}

Regarding parent-child rules, comodo uses parent-child rules.. thats just pure crap argument..
geezz.. Let the man try CIS.. after all its free.. :thumb: ::) Try a little of both is my suggestion.. then make your pick.. Iam more than happy with CIS.

Also I think it is OA that still can be crashed easily by flooding. But not sure about that one.

[alex_s]

{QUOTE-> hehe? ********? What good would commandline parameters do? Don't claim it adds anything securitywise..

<-QUOTE}
Actually, this adds a lot. For example some program can start explorer exe just to browse some directory, and other can start it like "explorer.exe http://********.biz?your_encripted_credit_card_requsites
{QUOTE->

Comodo has so much others that OA lacks.. Eg Buffer overflow protection, "probably" better interception, its technically #1 at matusec, but has not paid for a retest as some others have..

<-QUOTE}

I still cannot find a proof this "buffer overflow" does something useful. The only POC to test it is stopped by OA when tries to infect another process. But if you can provide some proof it is welcomed.

{QUOTE->

Regarding parent-child rules, comodo uses parent-child rules.. thats just pure crap argument..

<-QUOTE}

Take a look here:
http://www.wilderssecurity.com/showthread.php?t=231106
to understand what I'm talking about


{QUOTE->

geezz.. Let the man try CIS.. after all its free.. :thumb: ::) Try a little of both is my suggestion.. then make your pick.. Iam more than happy with CIS.

Also I think it is OA that still can be crashed easily by flooding. But not sure about that one. <-QUOTE}

This is good you are not sure, for more than a year passed since Ailef did it with some of the old OA version.

BTW, I do not want you to change your software, I just hate when people make not grounded statements. CIS is good software and it is
"Free", this is what nobody denies. I'd only say to use CIS and to be secure you need to understand a lot about how system internals work. CIS has a lot of different modes and settings and not everybody understands the difference between them. I saw a lot of people failed Comodo own test with CIS due to misconfiguration and misunderstanding. The same may happen with real malware. From the other side OA has only two mode - standard and advanced, but the both are the same secure, the difference is only in the number of available settings for "fine tuning".

[Iam_me]

{QUOTE-> Take a look here:
http://www.wilderssecurity.com/showthread.php?t=231106
to understand what I'm talking about
<-QUOTE}

Iam sorry aigle is A nice guy.. but he made an allow rule to BYPASS CIS usual parent child rules..

Qoute from aigie of how he did the test (link lower down on page):

{QUOTE-> Being a classical HIPs with complex parent child relationship for executables, it,s too chatty. So I have tweaked rules( while keeping paranoid settings) to get the minimum of alerts. <-QUOTE}

He did not say that on wilders thou.. But he was proved wrong by internal testings at comodo..

It was in my mind not a proper way of testing.. HE ONLY TWEAKED D+ FOR LESS CHATTINESS, stil if that what he feels like testing then he should not say "I used CIS default interactive security mode".. Actually CIS popups MORE than 10 times if aigie had only used default CIS settings.. witch he did not.. D+ even says "MALWARE BEHAVIOR".. It probably passed that test the best.. and it shows that D+ handle complex parent child relationship Good also, without problems.

http://forums.comodo.com/leak_testingattacksvulnerability_research/downadup_conficker_worm_versus_defence_plus-t33410.0.html

read that from the comodo forum if you want.. Login to see all beautiful popups it really generated..

Also some more "tweeaking" stuff he did to prove that CIS only gives ONE popup for this..

{QUOTE->

1- I allowed svchost.exe to creat any file anywhere otherwise I get too many alerts about it creating/ modifying file that was legit but bothersome for me.

Now here the malicious dll( vmx) and autorun files are created in USB devices via svchost.exe so during my testing it was a puzzle for me that which process is actually creating these files. I did not know until after many tries I found it out.

2- Similarly a dll in system32 is created by svchost.exe that my custom rules allowed silently.

3- I allow creation of tmp files globally without any pop up in my rules, so i never got an alert about creation of tmp file( ?driver) in this case.

4- More worse, just think of it. CFP intercept any dll execution by any process by default but it gives literally dozens of pop ups while executing legit applications, so i made a custom rule to allow any dll to be executed by any parent from anywhere.

EDIT: LINK: http://forums.comodo.com/leak_testingattacksvulnerability_research/downadup_conficker_worm_versus_defence_plus-t33410.0.html;msg240110#msg240110
<-QUOTE}

Still think he proved CIS can't handle parent child relationships? :argh: :)
This guy even says on the forum CIS has this...

"Being a classical HIPs with complex parent child relationship for executables, it,s too chatty"

Aigie says IT GOT complex parent child relationship for executables.. The guy you are referring to as a proof that CIS don't have this.. =S
Iam sorry.. But CIS do handle these stuff very well, and uses parent child relationship.. I know. If still in doubt, please try it out, I know that it uses this since I do a lot of testing.

{QUOTE-> Actually, this adds a lot. For example some program can
I still cannot find a proof this "buffer overflow" does something useful. The only POC to test it is stopped by OA when tries to infect another process. But if you can provide some proof it is welcomed. <-QUOTE}

I don't feel the need to pump arguments for this one.. but if its nthing to worry about then why would M$ brag of added protection against it..
Many drive by downloads is acctually using BO attacks..
And usually when a software such as firefox, ie, apache, whatever experience a vulnerability, it can be linked down to a BO-flaw..

Bo attacks can be lunched REMOTE and used to take over a computer without the need for them to manually installing something..

Here are 2 links that seems to take BOattacks serious..::)
I say its better to be protected than to not be..

http://www.networkworld.com/newsletters/sec/1115sec2.html
http://articles.techrepublic.com.com/5100-10878_11-5031882.html


{QUOTE->
I just hate when people make not grounded statements
<-QUOTE}

Do you still consider my stateements ungrounded? I don't consider yours to be.. I usually base my saying on facts, and has something to back it up with.. And I can see that you have also.. Still sometimes facts are wrong.. Like the one about child parent accusation.. :dry:

[alex_s]

{QUOTE->
Here are 2 links that seems to take BOattacks serious..::)
I say its better to be protected than to not be..metimes facts are wrong.. Like the one about child parent accusation.. :dry: <-QUOTE}

But what does make you think you are really protected from this ? :)

[3xist]

{QUOTE->
I still cannot find a proof this "buffer overflow" does something useful. The only POC to test it is stopped by OA when tries to infect another process. But if you can provide some proof it is welcomed.
<-QUOTE}

Just some simple advice... Go ahead and search for "Buffer Overflow" in ANY AV Vendor's site/forum.

Few examples -
Buffer Overflow Vulnerabilities: :

Symantec site (http://searchg.symantec.com/search?q=buffer+overflow+2009&hitsceil=100&entqr=0&output=xml_no_dtd&sort=date%3AD%3AL%3Ad1&client=symc_en_US&charset=utf-8&ud=1&context=gbh&oe=UTF-8&ie=UTF-8&proxystylesheet=symc_en_US&site=symc_en_US)

Security Focus (http://search.securityfocus.com/swsearch?query=buffer+overflow&sbm=%2F&submit=Search%21&metaname=alldoc&sort=swishlastmodified)

Secunia (http://secunia.com/advisories/search/?search=buffer+overflow&sort_by=date)

Secunia Research 2 (http://secunia.com/secunia_research/)

{QUOTE-> But what does make you think you are really protected from this ? :) <-QUOTE}

Here is a huge list of BO:
http://www.milw0rm.org/

Another example: winamp BO exploited 5th of March (ages ago but still a relevant comparison)... And CIS protects below (As you asked for proof).

Wimamp did fix this btw:
http://www.filehippo.com/download_winamp/changelog/
{QUOTE->
Fixed: [libsndfile] CAF Processing Integer Overflow Vulnerability
<-QUOTE}

Cheers,
Josh

[alex_s]

{QUOTE-> Just some simple advice... Go ahead and search for "Buffer Overflow" in ANY AV Vendor's site/forum. <-QUOTE}

So I did. The first POC that exploits buffer overflow in FF crashed FF without any warning from CMF: http://milw0rm.com/sploits/2009-ffox-poc.tar.gz

It may be, though, CMF protects you from "some" known attacks, but buffer overflow is by its nature a thing it's impossible to protect from generally, so I'd not rely too much on CMF. As for me I rely more on RunSafer feature in OA for the web applications which strips all the potentially dangerous rights and priviledges and turns BO attack ineffective. This approach is more safe, cause it protects not only from known BO attacks, but from all of them.

I went further trying to find exploit that CMF could stop. Next sample was:
http://blacksecurity.org/download/66/Adobe_JBIG2_Universal_Reader_Acrobat_Exploit
and CMF failed to help here too.

More later.

[firzen771]

{QUOTE-> So I did. The first POC that exploits buffer overflow in FF crashed FF without any warning from CMF: http://milw0rm.com/sploits/2009-ffox-poc.tar.gz

It may be, though, CMF protects you from "some" known attacks, but buffer overflow is by its nature a thing it's impossible to protect from generally, so I'd not rely too much on CMF. As for me I rely more on RunSafer feature in OA for the web applications which strips all the potentially dangerous rights and priviledges and turns BO attack ineffective. This approach is more safe, cause it protects not only from known BO attacks, but from all of them.

I went further trying to find exploit that CMF could stop. Next sample was:
http://blacksecurity.org/download/66/Adobe_JBIG2_Universal_Reader_Acrobat_Exploit
and CMF failed to help here too.

More later. <-QUOTE}

god dam, the Avira beep freaked me out when i tried to visit that second link lol, well at least i know Avira detects that as shellcode exploit now :P even though that wasnt my initial intention... lol

[BJStone]

;D It's loud isn't it? First time I heard it (from the new AV Premium 9) I was almost deaf for a minute or two and it squared the heck out of me. Blood pressure up to 200. And that was only the test button I used. Got to test this out in the middle of the night, let's see how the wife reacts...:argh:

[3xist]

{QUOTE-> So I did. The first POC that exploits buffer overflow in FF crashed FF without any warning from CMF: http://milw0rm.com/sploits/2009-ffox-poc.tar.gz

It may be, though, CMF protects you from "some" known attacks, but buffer overflow is by its nature a thing it's impossible to protect from generally, so I'd not rely too much on CMF. As for me I rely more on RunSafer feature in OA for the web applications which strips all the potentially dangerous rights and priviledges and turns BO attack ineffective. This approach is more safe, cause it protects not only from known BO attacks, but from all of them.

I went further trying to find exploit that CMF could stop. Next sample was:
http://blacksecurity.org/download/66/Adobe_JBIG2_Universal_Reader_Acrobat_Exploit
and CMF failed to help here too.

More later. <-QUOTE}

Did you test CIS or the actual stand a lone CMF?

Cheers,
Josh

[BJStone]

Good question, just to be sure.

[alex_s]

{QUOTE-> Did you test CIS or the actual stand a lone CMF?

Cheers,
Josh <-QUOTE}

It was CMF. From what I see it doesn't do much. I have imitated several BO attacks and CMF did nothing. The only profit I see from CMF is it doesn't take too much resources :)

[andyman35]

{QUOTE-> god dam, the Avira beep freaked me out when i tried to visit that second link lol, well at least i know Avira detects that as shellcode exploit now :P even though that wasnt my initial intention... lol <-QUOTE}
Haha I've long since given up on visiting any of those exploit sites with Avira enabled,it always goes positively ballistic and spoils the party.

[firzen771]

{QUOTE-> Haha I've long since given up on visiting any of those exploit sites with Avira enabled,it always goes positively ballistic and spoils the party. <-QUOTE}

lol yes it does, and can scare the sht outta u in the middle of the night when ur not expecting it lol ;D

[alex_s]

{QUOTE-> Comodo has so much others that OA lacks.. <-QUOTE}

It really has "so much". But what makes me think this "so much" is not too useful is the fact with this "so much" it performes not that "much" on the independent tests. How can it happen ? Why this "so much" doesn't help ?

[Einsturzende]

{QUOTE->
I still cannot find a proof this "buffer overflow" does something useful... <-QUOTE}

here is one... ;)

207456

[alex_s]

{QUOTE-> here is one... ;)

207456 <-QUOTE}

This is a kind of "attack" any HIPS can stop without much trouble when this process will try to tamper other process. Most likely this is even not an attack, but just a bug in a code which often results in execution go to a stack or heap. In any case inside itself a process can do whatever it wishes, even overflowing its own buffers.

[Einsturzende]

{QUOTE-> This is a kind of "attack" any HIPS can stop without much trouble when this process will try to tamper other process. Most likely this is even not an attack, but just a bug in a code which often results in execution go to a stack or heap. In any case inside itself a process can do whatever it wishes, even overflowing its own buffers. <-QUOTE}

so this is not useful?

[alex_s]

{QUOTE-> so this is not useful? <-QUOTE}
If you gimme this example I'll tell you what this program actually does and how useful CMF was in this case :)

BTW, what does happen with this sample without CMF ?

From my experience with CMF it jumped a pair of times catching BO, but actually they were just mistakes in a code that would lead to a program crash otherwise. And they were only the programs coded with VC. CMF failed to catch the BO in a programs compiled with the different compilers.

I think the whole approach trying to protect from BO is wrong. For one every particular compiler can use stack and heap how it wishes working with RTL. And to protect from BO using API you need to duplicate a lot of things OS does. But where is a guarantee this "protection" which should "fix" mistakes in other programs will not add its own bugs and in the end decrease security insted of increasing it ?

[Einsturzende]

{QUOTE-> If you gimme this example I'll tell you what this program actually does and how useful CMF was in this case :)

BTW, what does happen with this sample without CMF ?

From my experience with CMF it jumped a pair of times catching BO, but actually they were just mistakes in a code that would lead to a program crash otherwise. And they were only the programs coded with VC. CMF failed to catch the BO in a programs compiled with the different compilers. <-QUOTE}
sample is at your PM :)
Virus does its action, you will see harmful modifications I hope...

[alex_s]

{QUOTE-> sample is at your PM :)
Virus does its action, you will see harmful modifications I hope... <-QUOTE}

For now all I can say it just crashes with access violation on my Vista.
This is a sign of a bad coding in any case. What it does on XP I'll only be able to say when I get to my office. I believe it does something harmful, but the main question, is HIPS enough to stop it or to stop you you need BO protection. My bet is HIPS is enough, but Monday will show. If HIPS is enough then BO protection is useless, right ?

[Einsturzende]

{QUOTE-> For now all I can say it just crashes with access violation on my Vista.
This is a sign of a bad coding in any case. What it does on XP I'll only be able to say when I get to my office. I believe it does something harmful, but the main question, is HIPS enough to stop it or to stop you you need BO protection. My bet is HIPS is enough, but Monday will show. If HIPS is enough then BO protection is useless, right ? <-QUOTE}
It does what it does... here are warnings from CIS after shellcode injection one...

207457 207458 207459

[alex_s]

{QUOTE-> It does what it does... here are warnings from CIS after shellcode injection one... <-QUOTE}

Shellcode injection into what ?

The main BO protection goal (as I see it) is to protect TRUSTED programs like IE, Adobe etc from being tampered using BO. Unknown program has no chances to do anything harmful shellcoding itself. For HIPS it just doesn't matter in what crazy way it tries to tamper OTHER processes, with or w/o oveflowing itself. And even your pictures show very clear that HIPS is enough and which is important, HIPS is more meaningful, while CMF popup does not tell much.

In the link I posted there is a html code that causes BO in FF and FF crashes (it crashes because it is just a POC, but it could be exploit as well). Unfortunately CMF doesn't help there, where it is intended to.

[Einsturzende]

{QUOTE-> Shellcode injection into what ?

The main BO protection goal (as I see it) is to protect TRUSTED programs like IE, Adobe etc from being tampered using BO. Unknown program has no chances to do anything harmful shellcoding itself. For HIPS it just doesn't matter in what crazy way it tries to tamper OTHER processes, with or w/o oveflowing itself. And even your pictures show very clear that HIPS is enough and which is important, HIPS is more meaningful, while CMF popup does not tell much.

In the link I posted there is a html code that causes BO in FF and FF crashes (it crashes because it is just a POC, but it could be exploit as well). Unfortunately CMF doesn't help there, where it is intended to. <-QUOTE}

It uses "technique" which is forbidden to use, poor coding or targeted for... i don't care , what happens later, I don't care also, I see it as another layer of protection and press on terminate, always...

[alex_s]

{QUOTE-> It uses "technique" which is forbidden to use, poor coding or targeted for... i don't care , what happens later, I don't care also, I see it as another layer of protection and press on terminate, always... <-QUOTE}

It's OK. But do not fool yourself thinking you are more secure with this approach. CMF is nice, but useless toy for now. Real proof of CMF doing something useful would be a flash or "bad" html that exploits BO in a browser or viewer where CMF would stop it.

[Iam_me]

Even if this BO protection is not functioning totally off the hook CIS still got all the HIPS protection that is well in class with all others.. ::) :)

Are you sure those attacks you listed are actual BO attacks?
Crashes don't have to be BO attacks..

It can be a inbuilt action the program should do in case of something.. Eg you can code a program that should terminate if a specific action occurs.

Eg, you could have a program that terminate it self if file is larger than 300 MB.. Just to avoid long loading times.. This is not a BO, but rather a expected result.. And usually something that applications has.. Some checks and terminate if something is wrong..

If a hacker however found some terminating function then they can exploit it..

If you look at the Firefox example you put out.. It was a Exploit, but Buffer overflow attack? http://milw0rm.com/sploits/2009-ffox-poc.tar.gz

I cant find any of that in the code.. Maby Iam missing something..

Also Mozilla don't lable this as a buffer overflow.. http://www.mozilla.org/security/announce/2009/mfsa2009-12.html

So far I have seen CMF catch stuff.. that it is supposed to catch.
You don't expect a antivirus to catch packets either..

A exploit don't necessary mean "buffer overflow".. And if those are not BO actions then this is not something CMF will catch..

As for the acrobat exploit I did not care to explore..
But are you absolute shure those are really using BO to attack? :doubt:

I don't know if its okay.. but.. There are many of reports of it working also. If it fails on some occasions then thats good of you for pointing out. :thumb:

[alex_s]

{QUOTE-> Even if this BO protection is not functioning totally off the hook CIS still got all the HIPS protection that is well in class with all others.. ::) :)

Are you sure those attacks you listed are actual BO attacks?
Crashes don't have to be BO attacks..

It can be a inbuilt action the program should do in case of something.. Eg you can code a program that should terminate if a specific action occurs. <-QUOTE}

FF is not a program that should crash displaying html. Neither Adobe is a program that should crash displaying pdf.

[Iam_me]

{QUOTE-> FF is not a program that should crash displaying html. Neither Adobe is a program that should crash displaying pdf. <-QUOTE}
kk? But that don't mean the attacks you presented are acctual Buffer overflows.. And therefore it dosn't show that CIS buffer overflow protection is flawed.. The BO protection component was designed to catch BO attacks..

Not software bugs, software can crash due to unexpected behaivior, but unless the software are getting BufferOverflowed on some place than its not up to CIS BO protection to catch it. It could as well be a inbuilt code in FF that made this crash possible eg code that simply says "CLOSE FF if (this) occurs, leave (this) error.."

BO occurs when a file is writing to parts of the memory that it was not designed to do..

If its a closing condition in FF then FF would most likely not write over any memory it wasn't designed too.. And hence not Course a BO alert by CIS.

[alex_s]

{QUOTE->
Also Mozilla don't lable this as a buffer overflow.. http://www.mozilla.org/security/announce/2009/mfsa2009-12.html <-QUOTE}

===
Title:
XSL Transformation vulnerability
Impact:
Critical

Security researcher Guido Landi discovered that a XSL stylesheet could be used to crash the browser during a XSL transformation. An attacker could potentially use this crash to run arbitrary code on a victim's computer.
===

Can you explain me how is it possible to run arbitrary code without moving data where they should not be moved (which is BO) ?

What I do not like about Comodo is their ambitions go much ahead of their real abilities. CMF is one of these cases. They do domething without explaining what they really do, they push out some useless example and everybody believes it really does what it is declared to. But actually it does almost nothing useful. All the examples I saw did nothing that could not be stoped/prevented by traditional means.

[Iam_me]

{QUOTE-> ===
Can you explain me how is it possible to run arbitrary code without moving data where they should not be moved (which is BO) ?
<-QUOTE}
What you basically are saying is that the ONLY way to "remote" crash an application is to do a Bufferoverflow some place in a application..

Not true.. And FF loading a XSL stylesheet is nothing weirder than GTA loads a saved file.. Or Office loads a text document.. they can all crash and there is no need for the crash to be coursed by a BO even if BO's happens to be common. Crashes and even Privilege escalations or exploits don't need to use the BO technique if there is a coding or logical error within the program..

Feel free to read what Bufferoverflows actually are.

http://en.wikipedia.org/wiki/Buffer_overflow



{QUOTE->
What I do not like about Comodo is their ambitions go much ahead of their real abilities. CMF is one of these cases. They do domething without explaining what they really do, they push out some useless example and everybody believes it really does what it is declared to. But actually it does almost nothing useful. All the examples I saw did nothing that could not be stoped/prevented by traditional means. <-QUOTE}

You have yet to prove that CMF fails to prevent BO's.
Don't mix up BO's with BUGs in general.. :wacko: :wacko:

Not all "flaws" are BO's..

[alex_s]

{QUOTE-> What you basically are saying is that the ONLY way to "remote" crash an application is to do a Bufferoverflow some place in a application..
<-QUOTE}
Yep, in this or other way this is buffer overflow, if it was something else there would not be said "arbitrary code execution". For the only way to get "arbitrary code execution" is rewriting existing code, which was done by specially prepared xml style file. For you know, compiler do not generates a code that can pass execution to arbitrary code.
{QUOTE->
Not true.. And FF loading a XSL stylesheet is nothing weirder than GTA loads a saved file.. Or Office loads a text document.. they can all crash and there is no need for the crash to be coursed by a BO even if BO's happens to be common. Crashes and even Privilege escalations or exploits don't need to use the BO technique if there is a coding or logical error within the program..

Feel free to read what Bufferoverflows actually are.

http://en.wikipedia.org/wiki/Buffer_overflow

<-QUOTE}

I can even write the articles myself. Your "not true" is groundless. Just a crash is not buffer overflow, but a crash that can result in "arbitrary code execution" definitely is buffer overflow.

{QUOTE->

You have yet to prove that CMF fails to prevent BO's.
Don't mix up BO's with BUGs in general.. :wacko: :wacko:

Not all "flaws" are BO's.. <-QUOTE}

Nope, I have not. This is you who have to prove a lot of things, starting from providing working example where buffer overflow occures in LEGITIMATE apllication and CMF helps to prevent it, ending with this particular FF case. For me the words "arbitrary code execution" is quite enough to understand we deal with BO. This is not "just a crash" for "just a crash" doesn't result in "arbitrary code execution".

[Iam_me]

{QUOTE-> Yep, in this or other way this is buffer overflow, if it was something else there would not be said "arbitrary code execution". For the only way to get "arbitrary code execution" is rewriting existing code, which was done by specially prepared xml style file. For you know, compiler do not generates a code that can pass execution to arbitrary code. <-QUOTE}

Ehh wrong again.. http://en.wikipedia.org/wiki/Arbitrary_code_execution
And if you don't find Wikipedia as a reliable source then I could link to something else.. But thats not the point..
{QUOTE->
It is commonly used in arbitrary code execution vulnerability to describe a software bug that gives an attacker a way to execute arbitrary code <-QUOTE}

As I said, software bug.. Don't mess togheter Software bugs with BO's..
:dry: But some Arbitary code executions will be lunched after a BO..

BUT IT DON*t HAVE TO BE THAT WAY.. AND ITS NOT THAT WAY IN YOUR FIREFOX EXAMPLE..

{QUOTE->
I can even write the articles myself. Your "not true" is groundless. Just a crash is not buffer overflow, but a crash that can result in "arbitrary code execution" definitely is buffer overflow. <-QUOTE}
Your accusation are groundless.. And all the stuff points that this is not a BO attack. Noone except you labels it that way. and you acctually says it best yourself: can result in "arbitrary code execution"

Lets say you are correct, arbitrary code is the same as BO.
Lets just play with the thought..

Then this sample you provided still fails.. Since the word you use is "can result in arbitrary code execution" Basically you are saying this CAN result in a BO attack.. but in this sample it wasn't.. Since this is a friendly crash, for homeusege.. And unless this sample are modified and really makes a BO then CMF should not and will not catch it..

{QUOTE->
Nope, I have not. This is you who have to prove a lot of things, starting from providing working example where buffer overflow occures in LEGITIMATE apllication and CMF helps to prevent it, ending with this particular FF case. <-QUOTE}
Lol I think the post by 3xist where he showed how it catches a winamp BO should be sufficient, also running CMF against Comodo BO tester will show that it catches BO's and those are real as Windows own DEP reacts to 2 of them.. the third DEP misses completely!

Also you can check the CMF part of comodo forum.. A lot of posts in there of catched BO's..

{QUOTE->
For me the words "arbitrary code execution" is quite enough to understand we deal with BO. This is not "just a crash" for "just a crash" doesn't result in "arbitrary code execution". <-QUOTE}

Again this is not what arbitrary code execution is.. Its not the same as BufferOverflow, it just says that the code is bad, its lunched from remote and does nasty things..
:wacko:

[alex_s]

{QUOTE-> As I said, software bug.. Don't mess togheter Software bugs with BO's.. <-QUOTE}

Do you realize that BO attack can only be successful due to the bugs in software ? If the buffers were properly verified by software no BO attack could be possible.

[Iam_me]

{QUOTE-> Do you realize that BO attack can only be successful due to the bugs in software ? If the buffers were properly verified by software no BO attack could be possible. <-QUOTE}

Agreed completely.. "bugs" as you describes them are needed to do a BO..
But there is still flaws aka Bugs that can be used without BufferOverflowing anything..
This FF crash was such an example I think.:thumb: :)

But maby this thread has been going on for a bit too long now? I think the dude that posted first has already stoped reading it! ;D ;) Ofc you should respond if you disagree.. But I might stop responding after your next response.. just to let you know..

[alex_s]

{QUOTE-> Agreed completely.. "bugs" as you describes them are needed to do a BO..
But there is still flaws aka Bugs that can be used without BufferOverflowing anything..
This FF crash was such an example I think.:thumb: :)

But maby this thread has been going on for a bit too long now? I think the dude that posted first has already stoped reading it! ;D ;) Ofc you should respond if you disagree.. But I might stop responding after your next response.. just to let you know.. <-QUOTE}

Well, just a little examle

{
char buffer1[128];
char buffer2[256];

memcpy(&buffer1, &buffer2, 256);

and the same in OP

var
buffer1: array[0..127] of char;
buffer2: array[0..255] of char;
begin
move(buffer2, buffer1, 256);

are these examples just the bugs or buffer overflows ? CMF doesn't catch the both cases and they are kinda classic.

[Tyler Durden]

CMF detects shellcode execution (API calls from stack/heap), so only real exploits with real shellcode and only if they really have exploited your OS version/language/SP/etc (but do you need anything else ?)

[alex_s]

{QUOTE-> CMF detects shellcode execution (API calls from stack/heap), so only real exploits with real shellcode and only if they really have exploited your OS version/language/SP/etc (but do you need anything else ?) <-QUOTE}

The only one detection I got was not a real exploit, but FP. There was crappy code that decrypted itself in a heap and then passed execution there, but CMF regarded it BO, though it was normal execution path for this program. What I actually need is good BO protection. Real exploit will hardly call API from a shell code. First of all it will move itself to legitimate memory. But in any case this "protection" is outdated, because DEP works better and lighter to prevent execution in heap and stack. Now, when I finally understand what CMF actually does I decided to remove it, for my CPU supports DEP and CMF is just an unnesesary overhead to my system. But I agree, theoretically it can be useful for old computers, though I would not rely too much on this kind of protection, because I predict that most detections will be just due to the bugs in the programs, while real exploit can easily avoid CMF.

From Comodo site:
===
Comodo Memory Firewall is a buffer overflow detection and prevention tool which provides the ultimate defence against one of the most serious and common attack types on the Internet - the buffer overflow attack.
===

I love their marketing. "Ultimate defence". LOL. How they should disregard their users to write such BS ? "Ultimate" must be replaced with "Some" or "Partial" to be fair. I saw some people who believed CMF is better than DEP, and the only reason for this faith was they were fooled by this advertising. This is what they call "Creating trust online". If translated from Comodo language "Creating trust online" == "Fooling people online" :)