Message-ID: <096A04F511B7FD4995AE55F13824B833213120@contoso>
Date: Sat, 6 Oct 2007 21:30:20 -0400
From: "Roger A. Grimes" <roger@...neretcs.com>
To: "Thierry Zoller" <Thierry@...ler.lu>,
	"Juergen Schmidt" <ju@...sec.de>, <bugtraq@...urityfocus.com>,
	<full-disclosure@...ts.grok.org.uk>
Subject: RE: Re[2]: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype

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@...oworld.com or roger@...neretcs.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@...ler.lu] 
Sent: Saturday, October 06, 2007 12:13 PM
To: Juergen Schmidt; bugtraq@...urityfocus.com;
full-disclosure@...ts.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 
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

Powered by blists - more mailing lists