Adobe explains PDF patch delay

Emergency patch would have postponed Jan.'s enterprise-oriented update

Adobe chose to wait until mid-January to patch a critical PDF bug because issuing an emergency update would have disrupted its quarterly security update schedule, the company said today.

Unless users apply one of the workarounds that Adobe's suggested, the decision will leave systems open to attack until Jan. 12, when the patch is released. According to several security firms, the flaw has been in use by criminals since at least Nov. 20. Adobe only found out Monday that the vulnerability in its Reader and Acrobat applications was being actively exploited.

"We had two options," said Brad Arkin, Adobe's director for product security and privacy, describing the company's conundrum. "We could do an out-of-cycle update for this one vulnerability, and get out something as fast as we could, or try to work it into the Jan. 12 release."

The former, which would have gotten a fix for the current zero-day to users within "two or three weeks," said Arkin, had a down side. By pulling engineers into the Reader/Acrobat patch job, Adobe would have had to push back the already-scheduled Jan. 12 update into at least February.

"There really wasn't a third option," Arkin claimed, explaining that it would have been impossible for Adobe to do both -- rush an emergency patch to people by the end of December, then turn around and still meet the Jan. 12 deadline for updates already in progress.

"With a lot of work over the holidays, we decided we could get the patch into the code base for the Jan. 12 release, and still make that," Arkin said.

Helping to make Adobe's decision, Arkin argued, was the workaround it urged on users in a security advisory published late Monday. "We think we have an effective mitigation, the JavaScript Blacklist, which we included with the October security update."

JavaScript Blacklist Framework is a new feature that Adobe added to Reader and Acrobat that lets users and enterprise administrators lock down specific JavaScript functions, or APIs (application programming interfaces) to protect machines against known attacks without disabling all JavaScript functionality.

"This is the first time that we're using JavaScript Blacklist as a mitigation," said Arkin. Internal tests confirmed that by switching off the vulnerable API, users would be safe from the in-the-wild exploits making the rounds.

Adobe also talked with "lots of customers" to get their take on which path the company should take. "Having two updates, one this month for the vulnerability being exploited, then another roll-out, maybe in February, would be a lot more expensive for organizations than just one update [on Jan. 12]," Arkin said he concluded from those conversations.

Timing also played a part in Adobe's decision to delay the patch. The upcoming holidays, for example, were a concern to businesses, which weren't sure if they could test and deploy a rush patch before their workers returned to the job on Jan. 4. Also in play, said Arkin: The looming Jan. 12 deadline.

Last May, Adobe revamped the security process for its PDF viewing and editing applications, a move made after critics blasted the company for its slow patching process several months earlier. Adobe promised to speed up its patch work, go over old code to find flaws and release security updates for Reader and Acrobat every three months.

1 2 Page
Join the discussion
Be the first to comment on this article. Our Commenting Policies