Hi Vladimir, Please understand that I will not enter that discussion any longer. Please note that : V3D> is not malware/intrusion or malware in the form unused in-the-wild V3D> is not vulnerability. Is false. It is recognised malware, else the test woulnd't make sense - obviously. Regards, Thierry V3D> Thierry, V3D> I think inability of antivirus / intrusion detection to catch something V3D> that is not malware/intrusion or malware in the form unused in-the-wild V3D> is not vulnerability. Antivirus (generally) gives no preventive V3D> protection. They can add signatures for your PoCs to their database - V3D> and that's how it works. V3D> --Thursday, July 16, 2009, 12:02:35 AM, you wrote to bugtraq@xxxxxxxxxxxxxxxxx: TZ>> As I received a lot of feedback on this bug, I thought I'd update you. After not replying TZ>> to my notifications and subsequent forced partial disclosure, IBM stated TZ>> officially on their website that they where not affected and to my surprise TZ>> IBM got in contact immediately after disclosure to "coordinate" TZ>> If your read the Timeline till the end, the story has a nice swing.., Drama, insults, TZ>> everything. You could make a soap opera out of it. And you don't even have all the mails. TZ>> What happened during this "coordination" even surprised myself. I am used to discussions, TZ>> I am used to stupid answers. However what happened here bears no description. TZ>> Short Guerilla Version of the Timeline (complete timeline below): TZ>> ------------------------------------------------------------------- TZ>> - Hey Thierry sorry, we did not get your report, we'll keep you updated! TZ>> We have IBM written on the proventia boxes but don't send reports to IBM!! TZ>> - Post official statement to IBM website that IBM is NOT affected and TZ>> forgetting to inform Thierry TZ>> - Thierry, You cannot evade proventia, because we use special propretary TZ>> ingredients! >>> What are these ingredients? TZ>> - We won't tell !! and by the way you suck! your test methods suck! You aren't even TZ>> EAL2 ! A test team costs too much to tests your POCs! Your mails suck! Learn from TZ>> the big mighty IBM. >>> Sorry, the same poc evaded proventia last year! So you mus miss something!! TZ>> - Thierry, stop sending us POC files, YOU CANNOT EVADE PROVENTIA, IT is TZ>> IMPOSSIBLE, IRREVQUABLE, PERIOD !!!! >>>Silence TZ>> - Thierry here is our report, you DID evade all our proventia products, we will TZ>> credit you. TZ>> In the timeline below you find my summary TZ>> ----------------------------------------- TZ>> 02.04.2009 - Forced partial disclose TZ>> 02.04.2009 - An known contact at IBM asks for the POC TZ>> 02.04.2009 - POC is resend TZ>> 02.04.2009 - An third person is added to the coordination "list" TZ>> 04.04.2009 - Sending another POC file (RAR) TZ>> 06.04.2009 - POC is acknowledged and promise is made to get back TZ>> once the material has been analysed. TZ>> 10.04.2009 - Sending another POC file (ZIP) TZ>> 10.04.2009 - The third person ergo the "Cyber TZ>> Incident & Vulnerability Handling PM" is taking over coorindation TZ>> 14.04.2009 - A comment was made to my blog that indicated IBM did TZ>> answer the Bugtraq posting and negate my findings, having TZ>> received no response from them personaly I ask TZ>> "Dear Peter, I was refered to this url in a comment posted to my blog: TZ>> http://iss.custhelp.com/cgi-bin/iss.cfg/php/enduser/std_adp.php?p_faqid=5417 TZ>> can you confirm this ?" TZ>> 15.04.2009 - IBM responds: TZ>> "[..] we TZ>> apologize that the path of communicating the disclosure was somewhat TZ>> confusing. [..] The IBM contact address in the TZ>> OSVDB is typically used for software products that are in another division TZ>> of IBM, and thus, your report was not routed to us in a timely manner. In TZ>> the future, we'd prefer that you contact myself directly" TZ>> "We have now investigated the TZO-04-2009-IBM incident you reported and have TZ>> found that we are not susceptible to this evasion." TZ>> "[..]in this case, there are other components in our Proventia TZ>> products that prevent this evasion from occurring" TZ>> "Testing our production products, rather than testing this one TZ>> piece of our technology, then you would have been able to see the same TZ>> results" TZ>> 16.04.2009 - As my tests indicate otherwise I ask "Could you please TZ>> specify which >components< would prevent the evasion, as it is TZ>> hard to see how to prevent it when the unarchiver code cannot extract TZ>> the code itself" and TZ>> "I would be glad to do so [Red:test production products] : TZ>> Please send the respective appliances to <my adress>" TZ>> 16.04.2009 - IBM answers TZ>> [..] "We are not an open source company, so the internal workings of TZ>> our proprietary software is not something we publicly disclose. TZ>> We do not provide our products for free to all of the independent TZ>> testers that might be interested in our product lines--the number TZ>> of requests simply would not be scalable or manageable if TZ>> we did" TZ>> 17.04.2009 - As I have no way to reproduce and IBM gives no details TZ>> about their OH-SO Secret propretary software I state that TZ>> "I cannot verify nor reproduce your statements as such I will leave TZ>> this CVE entry as disputed." "Please provide tangible proof that TZ>> you detect the samples. Screenshots, logs, outputs." TZ>> AND TZ>> "My worktime is not open source either[..] Yet I TZ>> am currently working for your interests and customers, for free. I can TZ>> stop reporting responsibly if this is what you are trying to achieve." TZ>> 21.04.2009 - As their was no reply, I resend the previous mail TZ>> 22.04.2009 - IBM acks receipt and promises to reply soon. TZ>> == TZ>> In the mean time, as I thanked AV-TEST gmbh in my advisory, TZ>> somebody complains directly at AV-TEST Gmbh as force them to TZ>> no longer give me access to their test clusters. AV-TEST Gmbh TZ>> subsequently asks me to stop testing using their systems. TZ>> As a note: Anybody spots a paralel to the mob? TZ>> == TZ>> 23.04.2009 - I inform IBM that TZ>> "Interestingly instead of spending the time cooperating with me TZ>> some think it might be more usefull to complain at AVTest." [..] TZ>> "I perceive the complaints as a direct attack against myself" TZ>> 23.04.2009 - IBM informs me that it wasn't them that complained and TZ>> that TZ>> "[..] We processed your claim. You do NOT evade our products. TZ>> You are talking about a component that never deploys singularly. TZ>> Hence you cannot evade." TZ>> "As for testing our products, we have organizations that do that from TZ>> time-to-time. Those are contractual agreements. Since you published TZ>> incomplete data previously, I see no reason to engage for such a test." TZ>> "You ask for cooperation, but yet TZ>> you only have leveled insinuations and have attempted to turn what has TZ>> taken place into something else. Hardly following responsible disclosure TZ>> as you have listed it." TZ>> "I welcome your thoughts and your input as there is always something to TZ>> reflect upon and to learn about. But this is a two way street, and I ask TZ>> you to learn from us that how we deploy our products is not what you TZ>> tested/researched." TZ>> "Further, we are not going to loan a Proventia device for you to learn upon." TZ>> 23.04.2009 - I answer that TZ>> "[..] I asked for TZ>> screenshots or logs, something, if test have been done, should be TZ>> readily available anyways" "You seem not be be acustomed to handling TZ>> vulnerability reports, if negative finding is reported a vendor TZ>> usualy responds that the finding was negative he usualy attaches a TZ>> log, screenshot or similar." >>>You do NOT evade our products.You are talking about a component >>>that never deploys singularly. >>>Hence you cannot evade." TZ>> "Hmm, that might be the case, or might not - TZ>> I have an email from last year that states that a sample I provided TZ>> evaded proventia, using the very same methods of tests as this time." >>>Further, we are not going to loan a Proventia device for you to learn upon. TZ>> "I have not asked to be *loaned* a proventia device. You will TZ>> have to find the balance yourself. It's interesting to see that you TZ>> think I could somehow "learn" something from an appliance. TZ>> Anyways, if you don't provide me with guidance I can only sent in more TZ>> and more samples (that may be more and more false positives). Again TZ>> trying to help, but if you don't need help that's fine with me too." TZ>> 24.04.2009 - I inform IBM that TZ>> "Please note that I just made changes to my terms and policy to be able TZ>> to republish mails that happen during notification in full or TZ>> partially" TZ>> 24.04.2009 - IBM states that TZ>> "Thierry, TZ>> Changes you make should be effective for new issues going forward. Period." TZ>> "We have reported to you that your issues DO NOT EVADE PRODUCTS. That is TZ>> unequivocable. You have not proven an evasion of a product. " TZ>> "We TZ>> have conducted that research and the report is negative, your issues do not TZ>> evade the product. [..] Further, we do TZ>> not for obvious reasons ever provide architectural details except in cases TZ>> of NIAP review under Common Criteria for EAL 2 or Higher, then in only TZ>> certain aspects. Your research does not attain that benchmark." TZ>> 08.05.2009 - Sending a new POC evading proventia (CAB) TZ>> no reply TZ>> 11.05.2009 - Re-sending asking for an acknowledgement TZ>> 15.05.2009 - TZ>> "We are in the final stages of completing the write up on our review of all TZ>> your reports. It may take until early AM US EDT to complete or possibly TZ>> early AM Central European Time." TZ>> 22.05.2009 - IBM sends in the results, and *surprise* it DID evade proventia. TZ>> Quote:" TZ>> IBM Proventia Desktop Endpoint Security - susceptible TZ>> IBM Proventia Network Multi-Function Security (MFS) - susceptible TZ>> Multiple engines are susceptible to this evasion. We are working internally TZ>> and with third-party OEM vendors to create a fix for this evasion. For our TZ>> own engine, we have placed a fix on our long-term development roadmap, but TZ>> this is a low priority for us because this engine runs in a desktop TZ>> environment where malicious code in these archives will be detected upon TZ>> extraction or execution. If and when an update addressing this issue is TZ>> delivered for our engine, we will credit you." TZ>> Ignoring that the end-point argument doesn't hold true for the network TZ>> device, isn't this incredible? TZ>> 22.05.2009 - I respond that TZ>> "[..] The files TZ>> bypass your protection - to argue with client-side protection (if any) TZ>> is reserved for the clients that use your products. You should rate it TZ>> as what it is. A bypass of your AV detection" TZ>> Heard, nothing back since the 23th may. I trust IBM to disclose and fix, TZ>> and maybe credit, but I thought I let IBM customers know where your TZ>> millions license fees are spent on. -- http://blog.zoller.lu Thierry Zoller
