SAN JUAN, PUERTO RICO – Trying to identify a vulnerability and fixing it sounds unbelievably frustrating if the person who found it doesn’t offer any details. Adobe outlined some of the challenges vendors face with “partial disclosure” at a security conference that took place this week.
Shortly after Russian security company Group IB reported a critical security flaw in Adobe Reader which could bypass the sandbox and compromise the user computer, Adobe’s Product Security Incident Response Team began digging through the sandbox code to identify the issue, two security engineers from Adobe told attendees at the Kaspersky Lab Security Analyst Summit on Monday. Three months, 90 emails, and 60,000 words later, Adobe is still in the dark as it has not been able to reproduce the vulnerability, and still has no additional information, said David Lenoe, PSIRT’s group manager. Group-IB repeatedly promised to send a proof-of-concept code for the sandbox bypass, but to this day, still has not sent it, Lenoe said.
For Adobe, the possible sandbox bypass was bad news. The company had been touting the benefits of the sandbox technology in Reader and Acrobat ever since it was introduced in Adobe Reader X. The sandbox trapped several zero-day vulnerabilities over the past two years which compromised earlier versions of Reader and Acrobat, and prevented them from executing. If attackers had somehow found a flaw that allowed them to break out of the sandbox, it was something Adobe wanted to address immediately, Lenoe said.
“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.
The original report was a “partial disclosure,” in that the only available information came from a YouTube video demonstrating the attack and a release from Group-IB indicating an exploit had been added to a private version of Blackhole exploit kit being sold on underground markets for $30,000 to $50,000. The security team dug into the code and relied on their past experience with sandbox exploits to try to identify the issue. First of all, the team decided to operate on the assumption the exploit worked on Windows XP, which didn’t have defense mitigation technologies such as DEP and ASLR built into the operating system.
“We were hoping for a proof of concept, but we had a video,” said Lenoe. The team also scrutinized the video and found little clues, such as grabbing the exact version of Reader being used by looking at the splash screen in the clip. YouTube exploit proof-of-concepts are difficult for companies to work with because there’s only so much information available, and fake videos abound. Adobe had to glean whatever insights it could from the video clip.
The engineers weren’t sure whether the issue was related to process termination or a validation error, if it was a registry issue, or if it had something to do with a LogTransport2 utility, Karthik Raman, a security researcher with Adobe Secure Software Engineering Team, told attendees. “We really didn’t know,” he said. Group-IB told Adobe there were several examples of the PoC available, and credited independent researcher Kris Kasperski with the discovery. Kasperski apparently was the researcher who had originally posted the video demonstrating the exploit on YouTube, Lenoe said. Kasperski and
Group-IB told Adobe the issue was related to malformed data. Kasperski told Adobe it was a typical use-after-free flaw and it succeeded on XP because there was no DEP or ASLR, just as the company had guessed.
Based on the additional information, Adobe thought the vulnerability may be related to a PDF structural element, but it was unable to reproduce the issue without a proof-of-concept, Raman said. Adobe was in the process of fixing a race condition issue involving threads that seemed to be a similar situation, but it wasn’t sure if that internally-known issue was the same as the reported bug, he said. Adobe proceeded with the fix for the race condition flaw anyway. “We found the crash and had fixed it, but we still had to verify it with the proof of concept,” Lenoe said.
Kasperski eventually gave Adobe the name of the Metasploit module he used, but didn’t share the actual bypass flaw. The module can’t be used in isolation, so without the actual exploit, the company was still not sure what the problem was. Adobe eventually received a VM image, but the team couldn’t reproduce the reported issue, Lenoe said.
None of Adobe’s partners had any information about the exploit or vulnerability, which made it harder for Adobe to get any information, Lenoe said.
“When technical details are scarce, the approach to remediate can become more art than science,” Lenoe said. As far as Group-IB is concerned, the company cooperated fully with Adobe. “We provided them all we had, moreover, connected them with Kris Kaspersky, as well as provided a VM Ware image,” Andrey Komarov, head of international projects at Group-IB told SecurityWeek. “We are not the authors of exploits, we do threat intelligence only,” Komarov said.
“We still don’t know whether the bug we fixed is the same race condition Kris Kasperski was talking about,” Lenoe said.
Komarov noted that Reader and two other products had been patched. This suggests that Adobe did find the correct issue and fixed it successfully.
Lenoe said to this day, Adobe still has not seen any exploit successfully bypass the sandbox in Reader and Acrobat.
