IBM has admitted to successfully censoring a researcher who released a proof-of-concept (PoC) exploit code with the public disclosure of an IBM product vulnerability.
Researcher Maurizio Agazzini worked with IBM to coordinate the responsible disclosure of a vulnerability affecting the tech giant’s products but has been pressured into censoring part of his work — after patches to fix the flaw were released to customers.
The vulnerability is caused by the application server which deserializes untrusted data when the WASPostParam cookie is present, potentially leading to both denial-of-service (DoS) issues due to resources being plundered and the remote execution of code by attackers.
Last week, the researcher originally included working links to an exploit package as part of the disclosure, released after two months of working with IBM to resolve the security flaw.
However, Big Blue was not best pleased with the idea and requested that Agazzini self-censor the release by removing details of the exploit.
One of the researcher’s colleagues revealed IBM’s request on Twitter by posting a copy of the email sent to Agazzini:
This may not be a case of calling in the lawyer cavalry, but it does seem rather heavy-handed considering IBM was working with the researcher to patch the problem and the vulnerability was disclosed after a solution was deployed to customers.
Due to IBM’s request, section five, the packaged exploit code, has been removed. Section two remains, which reads:
The attack can be reproduced as follows:
- Create an application with custom form authentication
- After user login, the LtpaToken2 is set by the application server
- Make an HTTP GET request that contains the WASPostParam cookie.
However, the advisory still contains enough information for those interested enough to write their own PoC codes. In a statement to The Register, IBM said:
“Though the patch is now available, we understand many organizations can’t always apply patches immediately.
While not the normal IBM practice, in this specific case, we asked for some of the exploit details to be redacted to protect vulnerable users and allow them time to patch.”
PoC codes are important to provide as they give researchers the insight and resources required to further probe vendor software for problems — and how such exploits might affect business networks and environments.
Such concern for customers is one thing and admirable, but if PR has a bad day, this can turn off researchers from revealing software security flaws to the vendor in the future.