Adobe has released a new Adobe Reader version that contains functionality to block my /Launch action PoC, but Bkis found a bypass: just put double quotes around cmd.exe, like this: “cmd.exe”.
I did some research and discovered that Adobe implemented a blacklist of extensions for the launch action, but that the blacklisting functionality identifies the file type of “cmd.exe” as .exe”, and not .exe
Adobe is aware of the issue, and will evaluate the need to fix the blacklisting functionality.
But meanwhile, you can apply my fix to block launching “cmd.exe”.
You can configure the blacklist of extensions via the registry. Go to HKLM\SOFTWARE\Policies\Adobe\product\version\FeatureLockDown\cDefaultLaunchAttachmentPerms and open registry value tBuiltInPermList.
This is a list of |-separated extensions, together with the action Adobe Reader should take (3 means block the extension). Add .exe”:3 to block “cmd.exe”:
With this addition, Bkis’ bypass will not work anymore:
Some further testing shows that adding 2 double quotes is also a way to bypass the blacklist: “”cmd.exe””:
So we need to block this too:
I tested 3 and 4 quotes too, but this is not accepted by Adobe Reader. But should there still be other valid characters to append to the extension, you can block them in the same way as I showed here, until Adobe fixes the blacklist functionality.
Didier Stevens 
Hey Didier, you can bypass this by using:
/F (“command.com”)
Comment by cp77fk4r — Monday 5 July 2010 @ 8:33
And like this:
/F (“cmd.exe “)
🙂
Comment by cp77fk4r — Monday 5 July 2010 @ 8:40
@cp77fk4r Yup, like I wrote, you know how to block this now 😉 But it could turn out to be a long list…
Comment by Didier Stevens — Monday 5 July 2010 @ 8:44
There is no escape, they should implement a “learning” white list.
Comment by cp77fk4r — Monday 5 July 2010 @ 8:56
@cp77fk4r Of course, my fix is just a hack until they correctly fix this.
Comment by Didier Stevens — Monday 5 July 2010 @ 9:31
Didier,
interesting post. To take this one step further it’d be interesting to know exactly when and how often Adobe reader reads that Registry entry. Or, to put it differently: what prevents malicious code to tamper with tBuiltInPermList while Adobe reader is running and what would be the consequences?
Comment by Stefan — Monday 5 July 2010 @ 13:11
@Stefan There are several other blacklisting features in the registry, and there is only ACLs preventing malicious code to tamper with this (you need admin rights). But of course, you first need to be able to execute malicious code via a malicious PDF to be able to tamper with the registry keys, but when you’ve achieved this, you can tamper with everything (provided you’ve admin rights).
Comment by Didier Stevens — Monday 5 July 2010 @ 14:04
@Stefan- I really recommend to you to use the tool called “Procmon” to this issue.
@Didier- http://www.digitalwhisper.co.il/0x25/ [Hebrew]
Comment by cp77fk4r — Monday 5 July 2010 @ 16:07
[…] een betrouwbare bron afkomstig is. De Belgische PDF-onderzoeker Didier Stevens heeft inmiddels een oplossing van het probleem gevonden, waarbij gebruikers het Register moeten aanpassen. Bron: security.nl […]
Pingback by Plaats hier software gerelateerd nieuws! - Page 22 — Monday 5 July 2010 @ 17:34
[…] […]
Pingback by Adobe's protection against embedded scripts incomplete — Tuesday 6 July 2010 @ 12:55
Does this issue only affect Windows, or other platforms, as well? If it does affect other platforms, I wonder how they implemented the blacklist.
Comment by Ted Wood — Tuesday 6 July 2010 @ 20:37
@Ted Wood The /Launch action is supported on *Nix and Mac editions of Adobe Reader too, and they’ve also add this blacklist.
Comment by Didier Stevens — Tuesday 6 July 2010 @ 21:05
[…] researcher Didier Stevens posted in his blog the reason why the bug remains unfixed: I did some research and discovered that Adobe implemented a […]
Pingback by Adobe FAIL: PDF bug still unfixed – IndyPosted — Wednesday 7 July 2010 @ 4:11
[…] procedurer i vår Community samt att vi även har en fix på gång för detta problem. Kanske inte så stor attackyta på detta än, men varför inte se till […]
Pingback by Uppdaterade Adobe Reader procedurer i vår Community - upstream - Blog: Upstream - Telligent — Thursday 8 July 2010 @ 13:01
[…] Problemet beskrivs på IDG men kan beskrivs mer tekniskt här. […]
Pingback by Förhindra "/Launch Action cmd.exe" i adobe Reader 9.3.3 - upstream - Blog: Upstream - Telligent — Friday 9 July 2010 @ 10:55
[…] Quickpost: Preventing the /Launch Action “cmd.exe” Bypass – didierstevens.com Adobe has released a new Adobe Reader version that contains functionality to block my /Launch action PoC, but Bkis found a bypass. […]
Pingback by Week 27 in Review – 2010 | Infosec Events — Monday 12 July 2010 @ 10:31
[…] Stevens (well known for his research on Adobe Reader’s /launch feature) tested the exploit with his Ariad tool […]
Pingback by Code for Shortcut Zero-Day Exploit is Public | Data Protection and Recovery Center — Monday 19 July 2010 @ 17:55
[…] Stevens (well known for his research on Adobe Reader’s /launch feature) tested the exploit with his Ariad tool […]
Pingback by Code for Shortcut Zero-Day Exploit is Public | Computer Security Articles — Monday 19 July 2010 @ 22:26
[…] Stevens – Preventing the /launch action « cmd.exe » bypass – https://blog.didierstevens.com/2010/07/04/quickpost-preventing-the-launch-action-cmd-exe-bypass/9 – aout 2010 – Bkis – Adobe fixed /launch function vulnerability – […]
Pingback by escape from PDF | Linux-backtrack.com — Saturday 19 February 2011 @ 21:21