• Adobe X with Armor. Now to Find the Cracks.

    by  • December 7, 2010 • Uncategorized

    I finally got a chance to sit down and spend some time reading about Adobe X and their newly introduced sandbox. After finishing the 4 part series, FAQ and guide sections, I had to applaud the efforts put forth by Adobe and couldn’t help but think they actually care. I have yet to test out the functionality of the sandbox itself, but I am willing to take their word on how it operates for now. 

    Being the security engineer that I am, I know that no solution is ever 100% bullet proof (Adobe admits this) from attack and I decided to take notes on things that I felt were interesting or needed more in-depth analysis. Below are a few notes/features/improvements that I felt were worth looking into in hopes of breaking the sandbox implementation:

    Adobe Whitelisted the following actions:

    • Writing to the user’s TEMP folder
    • Writing (saving) Adobe Reader-specific user-modified preferences to the registry
    • Launching a tracker to handle shared reviews
    • Launch a .docx attachment in Microsoft Word
    Attack the IPC (Inter-Process Communications)
    • Deals with the broker which deals with the OS
    • Broker gets invoked on updates and outside COM creation
    Attack the OS functionality in regards to privileges 
    • Sandbox relies heavy on Windows protections
    • Look into the integrity aspects of a running process (Vista and up only)

    Modify policy rules

    • Custom policies can be created to bypass the sandbox itself
    • Saving the file automatically allows write access
    • Identify how custom policies are included
    Places where protected mode fails
    • Hosting Reader on a Citrix server.
    • Installing Reader on a mapped network drive.
    • Running Reader on WinXP when the OS is installed in a public folder.
    • Launching Reader in XP-compatible mode on Vista and Win7.
    • Launching Reader by right clicking AcroRd32.exe and choosing Run As.
    • Using PKCS#11 smart cards in signature workflows. Some cards can work in the presence of custom protected mode policies.
    • Collaborating in real time using the Collaborate Live feature.
    • Certain configurations of anti-virus software that has not yet white-listed AcroRd32.exe
    • The iFilter shell extension has a limitation with Microsoft Desktop Search and is not installed with Reader X.

    There is a lot of work that needs to get put in to see what is worthwhile. Adobe is clear to point out the past model vs. the new model in regards to exploitation. They mention that an attacker would essentially need to have a two exploit approach that would first exploit the sandbox to break free and then a second exploit to attack the system itself. There are certainly a couple more hoops an attacker would need to go through to get a successful exploit. Couple that with Adobes push for automatic updating and you have yourself a pretty shielded PDF viewer. 

    Going forward (in parallel with my current research) I would like to dive more into the ways to shut protected mode off by using one of the methods mentioned in the last bulleted list or through a custom policy. There is a reason protected mode is failing in this areas and I think it is worthwhile to read more into that as there may be a hole in that part of the system. For those looking for more information on the new features, you can check out: