Adobe echoed Microsoft's advice , saying the Enhanced Migration Experience Toolkit (EMET) would stymie attacks targeting Reader and Acrobat.
Called "scary" and "clever," the in-the-wild exploit went public last week when security researcher Mila Parkour reported it to Adobe after analyzing a rogue PDF document attached to spam. Adobe first warned users Wednesday of the threat, but at the time gave users no advice on how to protect themselves until a patch was ready.
Microsoft stepped in last Friday.
"The good news is that if you have EMET enabled ... it blocks this exploit," said Fermin Serna and Andrew Roths, two engineers with the Microsoft Security Response Center (MSRC) in an entry on the group's blog.
EMET, which Microsoft upgraded to version 2.0 earlier this month, is a stop-gap designed to keep older applications secure until companies upgrade to up-to-date, and theoretically safer, versions of those programs.
The tool lets IT administrators, and consumers willing to take the plunge, switch on several Windows defenses -- including ASLR (address-space layout randomization) and DEP (data execution prevention) -- for applications whose developers didn't turn them on by default.
The newest PDF exploit defeated Windows' DEP by leveraging a dynamic link library, or DLL, used by Adobe in both programs. Usually, ASLR prevents DEP bypassing, but according to researchers and Microsoft, the "icucnv36.dll" library doesn't have ASLR enabled. That gave attackers a way to sidestep both defenses.
Microsoft's Serna and Roths showed how to use EMET to switch on ASLR for Reader and Acrobat in Windows Vista, Windows 7, Server 2008 and Server 2008 R2, blocking the current exploit. A different tactic is needed to protect Windows XP and Server 2003 systems, which don't support what Microsoft called "mandatory ASLR."
Both Microsoft and Adobe admitted that they had had little time to test the impact of the EMET-based workaround. "Due to the time-sensitive nature of this issue, we have only been able to perform a cursory look at the functional compatibility of this mitigation," said Serna and Roths. "We recommend that you also test the mitigation in your environment to minimize any impact on your workflows."
Some researchers have blasted Adobe for poor programming practices, saying that its mistakes left Reader and Acrobat users at risk.
"This time Adobe gives a hand to the attacker," said Prevx researcher Marco Giuliani , talking about the failure to enable ASLR in icucnv36.dll. "Adobe could have easily prevented this type of exploit."
For others, the moment when Adobe launches its next version of Reader, which will include "sandboxing" technology to isolate application processes from one another and from the rest of the machine, won't come too soon.
"New stack overflow in Adobe Reader," said vulnerability researcher Charlie Miller on Twitter last week. "Dear Adobe, when you patch out of band every month, you don't have a patch cycle. Hurry with the sandbox."
Sandboxing is designed to stop malicious code from escaping an application to wreak havoc or infect the computer, or at least make it much more difficult for hackers to do so.
Adobe has not set a patch date for the Reader/Acrobat bug. The programs' next regularly-scheduled security update is slated for Oct. 12, but Adobe has pushed out emergency, or out-of-band, updates several times this year to fix flaws being actively exploited by attackers.
The last time Adobe released a rush patch was 19 August, three weeks after Miller talked about a Reader bug at the Black Hat security conference. Google security engineer Tavis Ormandy had privately reported the vulnerability to Adobe before Black Hat.
Microsoft's EMET 2.0 can be downloaded from the company's site .