How Comodo Memory Guardian exposed shoddy programming

Feedback/Comments/Announcements/News107
1

G’day,

At work, we have recently been having problems with an SSL based VPN solution from XYZ Inc. (names changed to protect the guilty). We were convinced their software was wigging out, and they were convinced it was something on our LAN/VPN hardware, our environment, our switches, our internet connection, our religion - anything but them.

I had installed CMG on one of our test boxes a couple of weeks ago and promptly forgot it was there. Today I decided to return to the VPN issue and tested it from the box with CMG on it. Lo and behold, CMG popped up as soon as the XYZ Inc. “ghost” VPN adaptor software attempted to initialise.

While it gave no indication other than something was futzing out, when I passed this snippet of info onto XYZ Inc., their response, in a nutshell, was “We’ll look into it.” 5 minutes later, they came back and said, in a nutshell, “DOH! Bad coding and worse code checking and validating.” They are correcting their code. They were amazed that we had been able to point them so definitively to the source of the problem and were gobsmacked when I pointed them towards the Comodo site and they found out that they were all free tools. I’ve got a sneaking suspicion that XYZ Inc. will use CMG as part of their code checking from now on. :wink:

Admittedly it is a fairly obscure environment we run it in, but CMG just paid for itself.

Congrats and can’t wait to see it rolled into CFP V3.

Kudos to Comodo (XYZ Inc also send their congrats!)

Ewen :slight_smile:

2

thats an amazing story Ewen :slight_smile: thanks for sharing it.

This is an interesting angle for CMG :slight_smile:

Melih

3

You might want to read this thread on Wilders Here

Starting around append 24. That’s an interesting angle too. :slight_smile:

Al

4

Thanks for bringing this to our attention Adric…

I am simply amazed at Stem! :slight_smile:

Stem, I don’t get your point?
Please help me understand what you are saying

-Are you saying that we created the Problem? (you are giving an example of an AV vendor creating a virus then providing a solution, this would mean that we created the BO problem… So are you claiming that we did?)

-Are you saying that: we should simply not alert users about testing whatever software they have, to this well exploited vulnerability, and let them live with false sense of security?

-Are you saying that: we should not give people an ability to test if our product work or not?

-Are you saying that: there are no other C code widely available on the net (yes ready to compile C code) that exploits Buffer Overflow vulnerabilities and that now we have a test application, the malware authors will reverse engineer to figure out how to test!!! Please go to google and just search for a keyword buffer overflow test or buffer overflow code (or many other keywords that will give you test code that will do exactly what we do in our tests)… there are tons of examples of codes available that anyone who cares can get. Test application is a VERY simple code as explained many times before and we clearly specifiy what it tests! There are tons of code out there for anyone to get, … again at a loss as to what your point is…

BO is one of the most sinister vulnerabilities, that is heavily exploited, we have today and all these users out there are totally vulnerable!!!

Please go ahead and do a search on Secunia website to see how many BO vulnerabilities are found

its one a day!!!

here are some examples!!

Oracle Database PITRIG_DROPMETADATA Buffer Overflow Vulnerability 2007-11-08
Link Grammar “separate_sentence()” Buffer Overflow 2007-11-07
AbiWord Link Grammar “separate_sentence()” Buffer Overflow 2007-11-07
SSReader Pdg2 Control ActiveX Control Buffer Overflow Vulnerability 2007-11-07
OpenBase SQL Command Injection and Buffer Overflow 2007-11-06
Perl Regular Expressions Unicode Data Buffer Overflow 2007-11-06
ACDSee Products Image and Archive Plug-ins Buffer Overflows 2007-11-02
Ourgame GLWorld GlobalLink Chat Control Buffer Overflows 2007-11-02
Novell BorderManager Client Trust Buffer Overflow Vulnerability 2007-11-01
McAfee E-Business Server Authentication Packet Handling Buffer Overflow 2007-10-31
NuFW “samp_send()” Buffer Overflow Vulnerability 2007-10-30
IPSwitch IMail Server IMail Client Buffer Overflow Vulnerability 2007-10-30
GOM Player GOM Manager ActiveX Control Buffer Overflow 2007-10-29
Sony CONNECT Player M3U Playlist Processing Buffer Overflow 2007-10-29
activePDF DocConverter File Parsing Buffer Overflows 2007-10-26
RealPlayer/RealOne/HelixPlayer Multiple Buffer Overflows 2007-10-26
Nagios Plugins “check_snmp” Buffer Overflow Vulnerability 2007-10-26
JustSystems Ichitaro Document Processing Multiple Buffer Overflows 2007-10-25
IBM Lotus Notes File Viewer Buffer Overflow Vulnerabilities 2007-10-23
MultiXTpm Application Server “DebugPrint()” Buffer Overflow 2007-10-23
RealPlayer Playlist Handling Buffer Overflow Vulnerability 2007-10-22
Nortel IP Softphone 2050 Buffer Overflow Vulnerability 2007-10-18
Miranda Multiple Buffer Overflow Vulnerabilities 2007-10-18
IrfanView Palette File Importing Buffer Overflow Vulnerability 2007-10-16
jetAudio M3U Playlist Processing Buffer Overflow 2007-10-15

So I am at a loss as to why Stem would NOT want people to test their systems to see if they suffer from BO or not? (and those users will have access to a free (totally free) solution to protect themselves as well anyway!)

We did NOT invent the BO vulnerability
We did NOT write the exploits for BO vulnerabilities
we are THE ONLY vendor providing FREE PROTECTION for BO!
we are THE ONLY vendor trying to educate users about this vulnerability that is actively causing harm to end users!

Stem, BO is such a huge issue (exploited issue) even CPU manufacturers like Intel and AMD have come up with h/w based solutions (DEP sounds familiar?:wink: ) which is still not enough against all the BO exploits out there.

Instead, Stem you should be educating everyone about BO issues and helping them protect themselves! In real world when there is a vulnerability (lets say a new virus/bacteria, like Bird flu etc) that is killing people, the government does not say, hey lets keep it quite… they make sure everyone is aware of it and teach them how to help themselves!

I think Stem is confusing the difference between:

A new vulnerability that has no exploits for (eg: somoene finds a new vulnerability and there are no exploits/malware out there utilising this new vulnerability). (Of course you keep that vulnerability quite and get it fixed before it can be exploited.)

with

A widely known vulnerability (eg: BO) that has too many exploits. Naturally, for a widely known and exploited vulnerability like BO, you want to educate users and give them tools to test their current security and protect themselves with.

Again, there is a big difference between

A New Vulnerability(unexploited)
and
An Exploited Vulnerability

BO is an Exploited Vulnerability!!!
(Well exploited!!! like Drive-by-download attacks etc)

Melih

PS: A user called Perman made the following statement "A selfish act re Commodo’s part ". Of course I am assuming he based his statement on Stem’s misunderstanding of what BO is (a new unexploited vulnerability vs old and exploited vulnerability). If not, I would love to find out which selfish act by Comodo he is referring to so that we could correct it. thanks.

5

Hm… Mates, again, CMG is not like AntiVirus or something, it’s not based on signatures scan, and not supposed to detect only known vulnerabilities. CMG protects you from BO as a class of attack, it doesn’t care about the vulnerability itself, is it new or old. And the test program doesn’t use any known vulnerability to test your PC, it JUST ACTS LIKE A BO, it executes shellcode from the stack/heap and in ret2libc manner. There’s no code/vulnerability hackers can get from it and use at all.

6

Stem seems to need this explanation…

/LA

7

I read that thread. It’s quite clear that Stem posts are Off topic. Stem’s arguments are better suited for a Exploit Disclosure Ethics Thread.
Since he is a Firewall Expert maybe he has only an overall knowledge about other security fields. No one knows everithing.

If stem reread his posts he can really see that those are OT because the example he gives cannot really fit to a software protecting
from exploits so widespread that they got Wikipedia articles.

Anyway Buffer Overflows are an old type of programming error. There are plenty of tools to help programmers and catch these errors before they release their product.
But BO are there, so a user-friendly tool to catch those is a good thing.

There is no harm in Comodo BO Tester too as is very different from an exploit. An explot is a program or a code that leveraging a certain software programming error is able to bypass security or run unauthorized code. if Comodo BO Tester is an exploit, it only exploit itself. But as there is no way to submit input to CBOT there would be no way for an haker to use it.

CBOT is a Proof of Concept and to a degree only show common programming errors.
Hackers use such errors to force some software to run unauthorized code but if there is no way for a software to accept 3rdparty submitted input (this can be exploit code or not)
these errors are not exploitable and usually cause a crash.

8
Anyway Buffer Overflows are an old type of programming error
That's not true, check any security web-site and you'll see that there're a lot of such errors in even new "0day" software. To make the long story short all such "help"and "tools" by Microsoft etc. are stucked into definin' _CRT_SECURE_NO_DEPRECATE aka "They will never exploit my product !".
9

Yep that’s why I said old type. Exploits can be new BO are an old thing. Anyway I’m not a programmer so I cannot really comment on your post.

Anyway there is a 2004 paper I’m currently reading to better understand this issue.

10

Stem

I read this with interest from your post:

[i]My question was simple,
Quote:
Did Comodo release the code for the last “overflow” problem to all vendors before releasing the code to all?

which could of been answered with a “yes” or “no”. Instead, there is a “Melih overflow”

I am finished with this thread.[/i]

Respectfully, you seem to understand Melih Overflow, but sadly you do NOT understand the Buffer overflow and BO test! :slight_smile: (cos if you did, then you wouldn’t say, hey comodo share this BO test, cos its meaningless plus anyone can get these codes on the web)

I would strongly urge you to first understand what BO and BO vulnerabilities are, then do try to understand what a BO test is and what it does! You totally miss the mark on this one I am afraid. I mean no disrespect Stem (and I do mean it), people think you know this stuff and listen to you (which is a good thing), don’t let them down! It is very important for all of us to educate everyone about this sinister weakness that everyone suffers from!

Melih Overflow… end… :slight_smile:

thanks

Melih