Sunday 4 July 2010 21:20
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.
Posted by Didier Stevens
Tags:
Mobile Site | Full Site
Get a free blog at WordPress.com Theme: WordPress Mobile Edition by Alex King.
Hey Didier, you can bypass this by using:
/F (“command.com”)
By cp77fk4r on Monday 5 July 2010 at 8:33
And like this:
/F (“cmd.exe “)
🙂
By cp77fk4r on Monday 5 July 2010 at 8:40
@cp77fk4r Yup, like I wrote, you know how to block this now 😉 But it could turn out to be a long list…
By Didier Stevens on Monday 5 July 2010 at 8:44
There is no escape, they should implement a “learning” white list.
By cp77fk4r on Monday 5 July 2010 at 8:56
@cp77fk4r Of course, my fix is just a hack until they correctly fix this.
By Didier Stevens on Monday 5 July 2010 at 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?
By Stefan on Monday 5 July 2010 at 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).
By Didier Stevens on Monday 5 July 2010 at 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]
By cp77fk4r on Monday 5 July 2010 at 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 […]
By Plaats hier software gerelateerd nieuws! - Page 22 on Monday 5 July 2010 at 17:34
[…] […]
By Adobe's protection against embedded scripts incomplete on Tuesday 6 July 2010 at 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.
By Ted Wood on Tuesday 6 July 2010 at 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.
By Didier Stevens on Tuesday 6 July 2010 at 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 […]
By Adobe FAIL: PDF bug still unfixed – IndyPosted on Wednesday 7 July 2010 at 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 […]
By Uppdaterade Adobe Reader procedurer i vår Community - upstream - Blog: Upstream - Telligent on Thursday 8 July 2010 at 13:01
[…] Problemet beskrivs på IDG men kan beskrivs mer tekniskt här. […]
By Förhindra "/Launch Action cmd.exe" i adobe Reader 9.3.3 - upstream - Blog: Upstream - Telligent on Friday 9 July 2010 at 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. […]
By Week 27 in Review – 2010 | Infosec Events on Monday 12 July 2010 at 10:31
[…] Stevens (well known for his research on Adobe Reader’s /launch feature) tested the exploit with his Ariad tool […]
By Code for Shortcut Zero-Day Exploit is Public | Data Protection and Recovery Center on Monday 19 July 2010 at 17:55
[…] Stevens (well known for his research on Adobe Reader’s /launch feature) tested the exploit with his Ariad tool […]
By Code for Shortcut Zero-Day Exploit is Public | Computer Security Articles on Monday 19 July 2010 at 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 – […]
By escape from PDF | Linux-backtrack.com on Saturday 19 February 2011 at 21:21