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.
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.
"We’re not establishing a guaranteed policy here," Arkin said, referring to the decision to delay the patch of the exploited vulnerability, "but where this happened to fall on the calendar played a part. If we’re early in the quarter, and if it’s urgent, we can release an out-of-cycle update, but as you get later, and closer to the quarterly patch, you have to weigh how [an out-of-cycle update] impacts that."
Arkin denied that Adobe lacked the resources necessary to handle out-of-cycle updates while still making its quarterly update schedule, but acknowledged that the company can’t afford to have a team of engineers "waiting just in case" an emergency occurs.
He also dismissed comparisons to Microsoft, whose security teams have frequently been faced with the same problem — rush out a patch or wait until the next cycle — and succeeded in meeting both simultaneously. "There’s a lot of differences between us and them," Arkin said. "You don’t really know when they queue things up, for example. They might have started working on a patch long before because the vulnerability had been responsibly disclosed."
Overall, Arkin said, the quarterly patch schedule is a positive, primarily because it appeals to enterprises using Adobe’s software. "It’s been really well received by all the customers I’ve talked with," he said. "They really appreciate the ability to plan for it, to know when it’s coming."
However, he deflected questions about whether the quarterly schedule may leave consumers at risk longer than if Adobe released security updates as soon as they’re ready. Instead, he touted Adobe’s revised updating tool, which was provided to users via the October Reader/Acrobat security release, but switched on only for a small group of beta testers.
"For home and consumer users, we have the new updater that we shipped in October," said Arkin. "It allows a couple of different options, including downloading and installing in the background, without any user interaction. Reminding people that there’s an update when they’re using the product is usually the worst time," Arkin continued. Instead, the new updater will process patches, download and install them — with no effort on users’ parts. "We’re hoping this will keep people updated with patches," he said.
Adobe will use the new updater for the first time next month to deliver the Jan. 12 patches to the beta testers, get feedback from the group, and then perhaps switch it on for all users.
Arkin admitted that, even with the new focus on security, Adobe can do better. One way would be to get information about active attacks sooner. While Adobe only learned of the current vulnerability and exploit last Monday when several security vendors reported their findings, evidence in filtering logs show that the attack code was being e-mailed to targeted victims as early as Nov. 20.
Adobe will try to get intelligence from its security partners earlier in the attack timeline, said Arkin. "We’re working hard to get information as early as possible in the awareness cycle," he said. "Maybe we would have made a different decision if we had known about the vulnerability in November."
The Jan. 12 security update for Reader and Acrobat will include patches for other bugs that have been privately reported to Adobe by researchers. Arkin declined to get specific about what will be patched then, or even how many flaws will be fixed. "But we’re looking for something more modest in size than the one we shipped in October," he said.
Adobe patched 29 bugs in Reader and Acrobat in its last regularly-scheduled security update, which was released Oct. 13.
Emergency patch would have postponed Jan.’s enterprise-oriented update
