Maybe parts of Comodo and OA?

Discussion in 'other firewalls' started by Atnodirlee, Mar 23, 2009.

Thread Status:
Not open for further replies.
  1. Einsturzende

    Einsturzende Registered Member

    Joined:
    Apr 14, 2008
    Posts:
    390
    Location:
    neubauten
    sample is at your PM :)
    Virus does its action, you will see harmful modifications I hope...
     
  2. alex_s

    alex_s Registered Member

    Joined:
    Aug 13, 2007
    Posts:
    1,251
    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 ?
     
  3. Einsturzende

    Einsturzende Registered Member

    Joined:
    Apr 14, 2008
    Posts:
    390
    Location:
    neubauten
    It does what it does... here are warnings from CIS after shellcode injection one...

    1.png 2.png 3.png
     
  4. alex_s

    alex_s Registered Member

    Joined:
    Aug 13, 2007
    Posts:
    1,251
    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.
     
  5. Einsturzende

    Einsturzende Registered Member

    Joined:
    Apr 14, 2008
    Posts:
    390
    Location:
    neubauten
    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...
     
  6. alex_s

    alex_s Registered Member

    Joined:
    Aug 13, 2007
    Posts:
    1,251
    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.
     
  7. Iam_me

    Iam_me Registered Member

    Joined:
    Feb 6, 2009
    Posts:
    89
    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.. :rolleyes: :)

    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:
     
  8. alex_s

    alex_s Registered Member

    Joined:
    Aug 13, 2007
    Posts:
    1,251
    FF is not a program that should crash displaying html. Neither Adobe is a program that should crash displaying pdf.
     
  9. Iam_me

    Iam_me Registered Member

    Joined:
    Feb 6, 2009
    Posts:
    89
    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.
     
  10. alex_s

    alex_s Registered Member

    Joined:
    Aug 13, 2007
    Posts:
    1,251
    ===
    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.
     
    Last edited: Apr 4, 2009
  11. Iam_me

    Iam_me Registered Member

    Joined:
    Feb 6, 2009
    Posts:
    89
    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



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

    Not all "flaws" are BO's..
     
  12. alex_s

    alex_s Registered Member

    Joined:
    Aug 13, 2007
    Posts:
    1,251
    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.
    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.

    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".
     
    Last edited: Apr 5, 2009
  13. Iam_me

    Iam_me Registered Member

    Joined:
    Feb 6, 2009
    Posts:
    89
    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..
    As I said, software bug.. Don't mess togheter Software bugs with BO's..
    :cautious: 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..

    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..

    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..

    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..
    o_O
     
  14. alex_s

    alex_s Registered Member

    Joined:
    Aug 13, 2007
    Posts:
    1,251
    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.
     
  15. Iam_me

    Iam_me Registered Member

    Joined:
    Feb 6, 2009
    Posts:
    89
    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..
     
  16. alex_s

    alex_s Registered Member

    Joined:
    Aug 13, 2007
    Posts:
    1,251
    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.
     
  17. Tyler Durden

    Tyler Durden Registered Member

    Joined:
    Apr 9, 2009
    Posts:
    1
    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 ?)
     
  18. alex_s

    alex_s Registered Member

    Joined:
    Aug 13, 2007
    Posts:
    1,251
    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" :)
     
    Last edited: Apr 9, 2009
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.