Sergey Nivens - Fotolia

News Stay informed about the latest enterprise technology news and product updates.

IBM yanks POC code in coordinated vulnerability disclosure

IBM asks, and researcher pulls proof of concept code from a coordinated vulnerability disclosure, internet explodes.

Playing by the rules of coordinated vulnerability disclosure doesn't always mean full disclosure, apparently, as IBM showed when it requested that a security researcher who found a serious vulnerability in IBM's WebSphere application server earlier this month remove proof of concept code from his original Full Disclosure mailing list advisory.

The vulnerability, according to the advisory by Italian security researcher Maurizio Agazzini, related to the way IBM's WebSphere application server deserializes untrusted data. The flaw could potentially enable an attacker to execute a denial-of-service attack through resource exhaustion, leading to the possibility of remote code execution.

The vulnerability was assigned to CVE-2016-5983, and it was given a CVSS base score of 7.5, signifying a high severity flaw.

Agazzini, security researcher at the Italian information security company @ S.r.l., based in Turin, Italy, followed the rules for responsible disclosure, reporting the flaw to IBM at the end of August. Agazzini was surprised by IBM's request: "During the communications with IBM about the vulnerability they never asked us to [not] publish information or delay the advisory."

"Partially we can understand that is a way to protect their customers, but all the information about the vulnerability was already published by [IBM], and a hacker will be able in any case to exploit this vulnerability without our code/advisory," Agazzini told SearchSecurity by email, adding that he does expect to republish the POC code at some point in the future.

As for removing the POC code, Agazzini said not publishing it would not improve customer security. "I don't think that [not] publish[ing] the POC will leave ... the customer more secure; [it's] quite the opposite. Personally, I think that a lot of ... the customer[s] will not update ... [their] systems because there is no working exploit on the net."

The original security advisory included proof of concept (POC) code in a separate file, as well as a brief description of an example attack session. IBM asked that the POC code and the section describing the example attack session both be removed from the advisory, so the POC code was removed from the file (named "websphere_payload") and was replaced with the text: "The archive has been temporarily removed on IBM's request." However, the section describing the example attack session remained.

When IBM's request was made public on Twitter, it generated some outrage from the infosec community.

Not everyone agreed.

"I think the public push-back was excessive and unwarranted. Lawyers weren't involved, there were no threats," John Bambenek, manager of threat systems at Fidelis Cybersecurity, based in Waltham, Mass., told SearchSecurity by email. "IBM's move seemed like a fair request, one that could have been rejected. The over-response to that request might make enterprises less open to researchers if anything else. There is a time and place to decry censorship; this was not it by a long shot."

According to a statement provided by a spokesperson, IBM created, tested and issued a patch for the vulnerability "in a timely fashion." However, "While the patch is now available, we understand many organizations can't always apply patches immediately. Because of that, we asked for specific exploit details to be redacted to protect vulnerable users and allow them time to patch."

"IBM seems to believe that the exploit details would be damaging because not everyone could patch immediately and there is some level of credence considering how WebSphere is used in enterprises," Bambenek said. "If both parties are working cooperatively, there is nothing wrong with IBM making their desires known."

Not all agreed that IBM's actions were consistent with coordinated vulnerability disclosure.

"I do not think it was reasonable," Iván Arce, program director of security in information communications technology at the Fundación Dr. Manuel Sadosky, a public-private research institution based in Buenos Aires, Argentina, told SearchSecurity by email. "They asked for editorial decisions on somebody else's research work. In my opinion, there is nothing that entitled them to do so."

While it has long been common for vendors to ask for researchers to edit their results to remove proof of concept exploit details, Arce said it was more common to companies "with less mature software security practices. In the case of IBM, it is kind of surprising because they are not new at all to the practices of vulnerability research and reporting."

"This is just another instance of the same old practice. It will certainly have a negative impact on the researcher that reported the bug and possibly on his employer," Arce said, but "further attempts to punish vulnerability researchers either by legal means or systematic public shaming will likely backfire as it had occurred in the past."

Next Steps

Find out more about the debate over responsible vulnerability disclosure.

Watch Katie Moussouris discuss Microsoft's approach to coordinated vulnerability disclosure.

Read about Microsoft's position on coordinated vulnerability disclosure.

Dig Deeper on Penetration testing, ethical hacking and vulnerability assessments