bugtraq - Re[2]: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1074747703.20071006181321@Zoller.lu>
Date: Sat, 6 Oct 2007 18:13:21 +0200
From: Thierry Zoller <Thierry@...ler.lu>
To: Juergen Schmidt <ju@...sec.de>, 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
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