RE: Re[2]: [Full-disclosure] URI handling woes in Acrobat Reader
I appreciate everyone's replies. Thanks for the replies and the
explanations. I'm not a Microsoft developer, I'm just a security
consultant. I didn't understand the nature of the central issue, at
first, but now I do.=20
Thanks again.
Roger
*****************************************************************
*Roger A. Grimes, InfoWorld, Security Columnist=20
*CPA, CISSP, CISA, MCSE: Security (2000/2003), CEH, yada...yada...
*email: roger_grimes@infoworld.com or roger@banneretcs.com
*Author of Windows Vista Security: Securing Vista Against Malicious
Attacks (Wiley)
*http://www.amazon.com/Windows-Vista-Security-Securing-Malicious/dp/0470
101555
*****************************************************************
-----Original Message-----
From: Thierry Zoller [mailto:Thierry@Zoller.lu]=20
Sent: Saturday, October 06, 2007 12:13 PM
To: Juergen Schmidt; bugtraq@securityfocus.com;
full-disclosure@lists.grok.org.uk
Subject: Re[2]: [Full-disclosure] URI handling woes in Acrobat Reader,
Netscape, Miranda, Skype
Dear Roger,
RAG> The applications in question are accepting abitrary input and not
validating correctly.
Please define "correctly" in case of an Uri handler. I am not aware of
special attack vectors or injections that I should be filtering in case
of mailto: calls, are there any? If yes, where are they documented and
where can I find them ? As a developer I have no control over what
Windows does with this handler, I have to trust it.
Are all Application developers now required to work around obvious bugs
in the way Windows handles the mailto: handler ?
What you call for is in essence - mitigation, yes it's fine to mitigate
a "vulnerability". But shouldn't we be concentrating on finding and
fixing the root cause instead of trying to mitigate the problem in
(hundrets) of third-party applications ?
RAG> How is that a Microsoft or Windows problem?
How is that _not_ a Windows Problem ?
RAG> Don't get me wrong, I want to protect end-users as much as the next
RAG> person (as does MS), but if it is the application not validating=20
RAG> correctly, could there not be hundreds of potential characters and=20
RAG> strings that cause input validation problems in particular=20
RAG> circumstances, which will vary according to the application?
We are speaking of the mailto: handler here that _seems_ to be broken
POST IE7 installation. (Again IMHO)
Could you explain me why POST Ie7:
mailto:test%../../../../windows/system32/calc.exe".cmd
Executes calc
mailto:test%../../../../windows/system32/calc.exe".txt
executes notepad trying to open calc
mailto:test%../../../../windows/system32/calc.exe".doc
Now the surprise :
OFFICE (Winword) opens, SHELLS the mailto handler BUT replaces "%" with
"%25" and " with %22 and surprise it does NOT execute calc but your mail
client. Yes!
Winword mitigated the problem/vulnerability.
Try it, open Winword, add hyperlink with
mailto:test%../../../../windows/system32/calc.exe".cmd
click on it, and check process explorer to see the result winword
replaced the % prior to shelling mailto. Now this is some serious
voodoo.
I think some persons were aware of the problem but couldn't get the
responsible parties to fix it, becuase of arguments like yours. This is
a assumption, not a fact. I have not been there and heard that...
RAG> If Microsoft scrubs out every potential malicious character, it's=20
RAG> bound to break lots of legitimate applications.
What genuine application uses this [1] way to call a mailto: handler ?
[1] mailto:test%../../../../windows/system32/calc.exe".cmd
RAG> At what point should Microsoft scrub URIs so that it hands off only
RAG> "legitmate" characters "most of the time"? How could Microsoft=20
RAG> determine ahead of time what is and isn't legitimate characters to=20
RAG> pass to applications they don't own?
It's not that they should decide what and what to pass or not to pass
on, the problem in the example Juergen sent is - what they pass
INTERNALY not to third party applications.
RAG> If they block
RAG> characters that affect certain applications, it might cause=20
RAG> problems in other applications that have no problem with the
character(s) in question?
RAG> What is the solution? The easy answer is to block the % character=20
RAG> in this particular instance...but that's just a whack-a-mole fix.
The Solution might be :
- Determine the root cause
- Determine the attack vectors
- Determine whether it's wise to fix it at the root or try to mitigate
around it.
RAG> I'm asking, with genuine interest and a listening ear, what is the=20
RAG> best long term solution you envision, to solve the larger problem?
Certainly it's not mitigating through hundrets of third party
applications.
--
http://secdev.zoller.lu
Thierry Zoller
Fingerprint : 5D84 BFDC CD36 A951 2C45 2E57 28B3 75DD 0AC6 F1C7