Back to list
Update: [TZO-06-2009] IBM Proventia - Generic bypass (Limited disclosure - see details)
Jul 15 2009 08:02PM
Thierry Zoller (Thierry zoller lu)
Re: Update: [TZO-06-2009] IBM Proventia - Generic bypass (Limited disclosure - see details)
Jul 16 2009 11:39AM
Vladimir '3APA3A' Dubrovin (3APA3A SECURITY NNOV RU)
I think inability of antivirus / intrusion detection to catch something
that is not malware/intrusion or malware in the form unused in-the-wild
is not vulnerability. Antivirus (generally) gives no preventive
protection. They can add signatures for your PoCs to their database -
and that's how it works.
--Thursday, July 16, 2009, 12:02:35 AM, you wrote to bugtraq (at) securityfocus (dot) com [email concealed]:
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> - 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
>> 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 !!!!
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> 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> 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> 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> "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> 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> 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> "[..] 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> "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> 24.04.2009 - IBM states that
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> 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> 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.
Ìàøèíà îêàçàëàñü ñïîñîáíîé ê åäèíñòâåííîìó äåéñòâèþ,
à èìåííî óìíîæåíèþ 2x2, äà è òî ïðè ýòîì îøèáàÿñü. (Ëåì)
[ reply ]
Copyright 2010, SecurityFocus