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. Thanks again. Roger ***************************************************************** *Roger A. Grimes, InfoWorld, Security Columnist *CPA, CISSP, CISA, MCSE: Security (2000/2003), CEH, yada...yada... *email: roger_grimes@xxxxxxxxxxxxx or roger@xxxxxxxxxxxxxx *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@xxxxxxxxx] Sent: Saturday, October 06, 2007 12:13 PM To: Juergen Schmidt; bugtraq@xxxxxxxxxxxxxxxxx; full-disclosure@xxxxxxxxxxxxxxxxx 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 RAG> correctly, could there not be hundreds of potential characters and RAG> strings that cause input validation problems in particular 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 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 RAG> determine ahead of time what is and isn't legitimate characters to 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 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 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 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
