Date: Thu, 16 Jul 2009 14:58:49 +0200
From: Thierry Zoller <Thierry@zoller.lu.>
To: "Vladimir '3APA3A' Dubrovin" <3APA3A@SECURITY.NNOV.RU.>
Subject: Re[2]: Update: [TZO-06-2009] IBM Proventia - Generic bypass (Limited disclosure - see details)
In-Reply-To: <174644240.20090716153904@SECURITY.NNOV.RU.>
References: <763316982.20090715220235@Zoller.lu.> <174644240.20090716153904@SECURITY.NNOV.RU.>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: antivirus-gw at tyumen.ru
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 [email protected]:
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
