Thanks for bringing this to our attention Adric...
I am simply amazed at Stem!
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 http://secunia.com/search/?search=buffer+overflow
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?
) 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 betweenA New Vulnerability(unexploited)
andAn Exploited VulnerabilityBO is an Exploited Vulnerability!!!!!!
(Well exploited!!!! like Drive-by-download attacks etc)
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.