Serious security flaws, please respond!

Hello, I have been digging into CIS and CMF for a month now and found out that I’m actually able to execute the standard C/C++ int system (const char *command) function from the heap, the stack and through ret2libc attacks. When i modify it to instead call ShellExecute, both CMF and CSI are detecting it so then why are CMF and CSI not detecting system-calls? ShellExecute and system can both be dangerous calls.



C run-time functions like “system” are commonly used in shellcodes for *nix operating systems. Current BO detector hooks only calls commonly used in the windows shellcodes.

However if you are aware of such an exploit “in the wild” and cant be detected by CIS/CMF BO detector, let me know and we will review those hooks.

Feel free to PM me if you have such samples.


Doesn’t matter, it’s a design fault, as I wrote in some other thread I also found a way around the execution detection which is probably similar to this. I have to say more AVs don’t detect this but some do (Avira).

People use defence+ to defend against unknown threats so should BO detection also do the same?

Then whats the point in antivirus engine and BO protection if everyone rely on D+ only? Makes no sense at all.

This has nothing to do with AV or execution control. You can NOT bypass execution control. Show me an example if you bypassed pls.

Are you saying that you won’t fix this obvious security flaw because i can’t give you an example of an exploit that uses “system”? Aren’t you guys supposed to prevent exploitation?

Then, what makes you so sure about the “system”-call? “system” is C/C++ ISO/IEC standard and is used across every operating system on earth, including Windows. Your BO detection is, and will be, totally useless until you fix the “system”-call. I’m not using it anymore and won’t be using it until the flaw is fixed.

Thank you for your time.

frustration got me to reply with anger

I think he’s saying it is not a flaw, unless you can prove otherwise.

al6, you are claiming it to be a flaw, but unless there is something to physically see, nothing can be done to correct this. Please provide the example asked for and your ‘issue’ will be resolved.

There are multiple ways to execute something. Even when Defense+ is on Paranoid.
I’ve done some retesting on the samples I made a long time ago and even though it’s improved a lot not everything was detected. If you load a dll into the exefile with valid pointers it works just fine, didn’t got a single popup from Comodo.

Ok first of all, if you want me to continue this discussion further, please try to be civilized while writing messages. Since english is not your native language, i can understand this might be difficult for you.

Now there are 34 other calls that you are probably not even AWARE of that can be used in a buffer overflow shellcode and we do NOT hook. All of them vary between compilers(for example. Visual C++ CRT libraries, Delphi CRT libraries, gcc CRT librariers) and depend on compiler linkage options. This introduces a significant incompatibility problem for us. However the attackers have the same problems and thats probably why they dont use these apis in the windows shellcodes. That means it is not IMPOSSIBLE to bypass BO protection offered by CIS.

However these apis are secondary APIs. Many of the BO attacks are detected before these apis are called. That reduces the risk further.

Then why dont we just add more hooks and make every single person on this planet happy? Because, adding hooks, although techically very simple, means additonal and unknown incompatibility problems. So we have to care for USER experience as well as security. A balanced approach has to be followed when you are a software vendor.

Now CIS BO protection is designed to combat with the types of exploits in the wild and provide enough defense against BO attacks.

We will deal with the problems when they are in the wild and the defense does not come in the expense of screwing up poor users’ other programs. When you have 90-100% coverage against BO attacks, thats fair enough.

FYI: I am going to delete this thread soon. In COMODO forums, although we allow anything to be discussed, it is not really preferable to let people with malicious intentions to learn how to bypass our products from me first hand. So l hope you will not mind this. However please fell free to send private messages to me to discuss the issue if you have more questions.


You mean loading a DLL into memory? CIS is not supposed to or even designed to detect if you load a DLL into the process space of an application normally(without hooking or memory injection) except for rundll32.exe(Even this is going to change in the future versions).

By setting image execution control to aggressive and adding *.dll to execution list, you can receive alerts for DLLs but this is not really recommended/intended to be used and we will discontinue this ability in the future versions.

However, if you have a way to execute a standalone executable and bypass the image execution control, that means a flaw and let me know.


Okay, this was the answer i wanted; “system” obviously is a way to bypass both CMF and CSI but you have made this by design in order to keep compatibility and effort at an acceptable level. I haven’t digged for more vulnerabilities in the API hook, but when I found that “system” wasn’t hooked i was surprised because C and C++ are the mort popular languages ever.

Sure. Feel free to send private messages to me as you progress with your research.


Reading through this thread, I must applaud all parties involved. The Comodo representatives know their stuff (even took me for a loop) and so does the person making the report.

I’m glad to see that Comodo does allow user discussion of potential flaws and does its best to address them rather then silencing their users.

As a Comodo user myself, I’d prefer that such discussion was done openly and not deleted. I highly doubt that most of the ‘script kiddies’ out there can even follow what was said. There’s always ways to bypass stuff, but very few malicious people have the knowledge to carry it out. Most of them don’t bother to code their own tools, and I doubt they even know this much.

I do like that Comodo at least acknowledged the flaw and the reasons behind it (compatibility).

Kudos to all!

I second the post above. I lack proper programing knowledge, but this thread is informative an interesting.

Nothing ever can be 100%!
Its all about Risk Management!


After some thinking (and a little conversation :)) I believe it’s a fair point to await possible exploits from the wild, instead of preventing something that doesn’t even exist (to the knowledge of Comodo). Still though, I’m inclined to prefer a slightly more proactive approach in this case. But in the end I trust Comodo’s judgement to be fair and reasonable.

You can use several programs to hook a dll file into an exe, replacing the file and executing it, doesn’t give any popup here, e.q. try to load a dll into Firefox, notepad or any other program and if you granted it permission it works fine.