Partial Disclosure Leaves Adobe Reader Zero-Day Story in Limbo

SAN JUAN, Puerto Rico – It’s the vulnerability that never was. Or was it?

SAN JUAN, Puerto Rico – It’s the vulnerability that never was. Or was it?

In a saga that has spanned close to three months, 90 emails and a short novel’s worth of back and forth between Adobe and Russian security company Group-IB over a reported zero-day sandbox-bypass exploit, there has been little in the way of a concrete resolution. Two members of Adobe’s Product Security Incident Response Team (PSIRT) said today at the Kaspersky Lab Security Analyst Summit that the software vendor has been unable to reproduce the vulnerability, and has yet to receive proof of concept code for a sandbox bypass from Group-IB, despite numerous promises to do so.

“We were hoping for a proof of concept, but we had a video [of the exploit] only,” said David Lenoe, Adobe PSIRT group manager. “We did as much analysis, but without a proof of concept, we had to deal with what we had.”

Group-IB did not reply to request for comments.

The sandbox bypass was reported Nov. 7 by Group-IB; the company added that exploit was being sold in a private version of the Blackhole Exploit Kit for anywhere between $30,000 and $50,000. This was an urgent situation for Adobe PSIRT since an exploit bypassing the sandbox had not been seen in the wild before.

“The Reader sandbox is a key part of our security story. It’s been a really successful way for us to prevent exploits,” Lenoe said. “If there was a bypass, we would want to fix it immediately.” Adobe reached out to Group-IB and quickly learned the company was launching a U.S.-based office. “This may have contributed to the release to get attention for their new operation,” Leone said.

Nonetheless, Adobe was undeterred over the partial disclosure of the vulnerability. Going to work with what few details they had, primarily the video of the exploit and some prior knowledge of previous sandbox vulnerabilities, Adobe began with the premise that the vulnerability might be limited to Windows XP because of the lack of DEP and ASLR protection on the operating system.

“Was it related to a process termination, or maybe it was registry related, or related to a LogTransport2 utility, or a validation error, or none of the above,” said Karthik Raman, security researcher with the Adobe Secure Software Engineering Team (ASSET). “We really didn’t know.”

In the meantime, Group-IB had emailed Adobe and copied independent researcher Kris Kasperski who had originally posted the exploit video privately to YouTube, which was then reposted by Group-IB giving Kasperski credit for the work. They added that the vulnerability was caused by some malformed data, Raman said.

Backed by this additional guidance, Adobe deduced the vulnerability might be related to a PDF structural element. Kasperski reference a Metasploit module, and told Adobe the bug was a typical use-after-free scenario and that it worked on XP because of the lack of malware execution protections, as Adobe had deduced. Yet still, Group-IB would not give up a proof of concept.

Raman said Adobe again rethought the situation and worked on the theory that there was a race condition involving threads at work, that could map to some bug fix efforts happening already internally at Adobe. But they couldn’t be certain if it was the same bug, or whether there was a second bug at play. In the meantime, Adobe reached out to its partners, none of whom had seen the exploit or vulnerability.

“The best information we had was that the structural element was the culprit, and we continued with the fix,” Lenoe said. “We found the crash and had fixed it, but we still had to verify it with the proof of concept.”

Kasperski eventually shared the name of the Metasploit module he had referred to less than a week earlier, but would not share the bypass. In the interim, Adobe partners such as Kaspersky Labs reached out to Group-IB with questions that were never answered. Lenoe said things got quiet until Jan. 9 when apparently the relationship between Kris Kasperski and Group-IB soured. Kris Kasperski shared a sample of the exploit. The patch Adobe had prepared prevented a crash in Reader X but that vulnerability demonstrated in the proof of concept on the VM did not bypass the sandbox.

“We were wondering again, what’s going on,” he said. The PSIRT team is still in the dark, close to a month after its last exchange with either party.

“We still don’t know whether the bug we fixed is the same race condition Kris Kasperski was talking about,” Lenoe said. “All we got in the end was the name of the Metasploit module, and this module cannot be used in isolation to bypass the sandbox. We don’t know if a second bug is being used because the vulnerability has not been shared.”

One positive, however, that came out of this is that Adobe’s engineers were forced to take a deeper dive into the sandbox.

“Our engineers found some areas they wanted to spend more time on,” Lenoe said.

This article was updated Feb. 5 with clarifications from Adobe.

David Lenoe’s image via Eugene Kaspersky’s Flickr photostream.

 

Suggested articles

Discussion

  • Anonymous on

    Thanks for posting this very interesting story. Zero day flaws are always of interest to me but I never expected it to unfold like this.

    I would be interested to know if the most recent update 11.0.01 for Adobe Reader XI includes the fix for the race condition mentioned.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.