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 RAG> next person (as does MS), but if it is the application not RAG> validating correctly, could there not be hundreds of potential RAG> characters and strings that cause input validation problems in RAG> particular 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, RAG> it's 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 RAG> only "legitmate" characters "most of the time"? How could RAG> Microsoft determine ahead of time what is and isn't legitimate RAG> characters to 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 % RAG> character 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 RAG> the 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
