ZDI-18-1372 – The Elegant BypassDecember 21, 2018 | Abdul-Aziz Hariri
2. search.query(<word>, "Index", <idx-path>)
3. search.query(<word>, "Folder", <idx-path>)
4. search.query(<word>, "ActiveDoc")
Methods 2 and 3 are security restricted, as mentioned in the JS API documentation. Thus, the functionality to load indexes from a certain path (including UNC paths) can’t be triggered without elevated privileges.
Method 1 can be executed without elevated permissions, though the parsing of any embedded search index does not happen! This was likely a design decision to not open up the Onix search API to potentially malicious embedded indexes.
However, using method 4 with the parameter “ActiveDoc”, Acrobat Reader DC and Acrobat DC first save the embedded index to the folder
C:\Users\<USER>\AppData\LocalLow\Adobe\Acrobat\DC\Search, and then start parsing it! Thus, using the “ActiveDoc” parameter, an attacker gets the opportunity to hit the whole Onix parsing engine.
The following steps should be taken to confirm hitting the Onix parsing engine:
1. Delete all files from folder C:\Users\<USER>\AppData\LocalLow\Adobe\Acrobat\DC\Search to avoid loading a cached index file
2. Open Acrobat Reader DC
3. Attach debugger and set a (deferred) breakpoint on onix32!ixCreateIndexManager (This method gets called first whenever idx-file parsing starts)
4. Now open poc.pdf
a. You will get 4 alerts before each of the possible search.query method calls
b. You will NOT hit onix32!ixCreateIndexManager calling search.query with method 1
c. You will NOT hit onix32!ixCreateIndexManager calling search.query with methods 2 and 3 (which will throw exceptions)
d. But you will hit onix32!ixCreateIndexManager when calling search.query with method 4! Also, you will notice that during the 4th call the embedded index file(s) will be written to the search folder
The poc will force the search dialog to popup and kick off a search in the PDF, thus triggering the parsing code that was not hittable before.
It’s amazing how much individual research can expose. Even the vendor thought that the attack surface was mitigated. Anyway, Adobe finally figured out a scientific way to fix the bugs in this attack surface - killing the whole parsing code. Yup, they basically ended up disabling the parsing code. While this change likely impacts performance, and certainly impacts functionality, sometimes the best way to “fix” a security problem is simply to remove the offending feature. That takes the term “attack surface reduction” to a whole new level.
Until next time.