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: <096A04F511B7FD4995AE55F13824B833213116@contoso>
Date: Fri, 5 Oct 2007 15:54:11 -0400
From: "Roger A. Grimes" <roger@...neretcs.com>
To: "Juergen Schmidt" <ju@...sec.de>, <bugtraq@...urityfocus.com>,
	<full-disclosure@...ts.grok.org.uk>
Subject: RE: URI handling woes in Acrobat Reader, Netscape, Miranda, Skype

[Disclosure: I work for Microsoft. But this is my opinion, not Microsoft's]

If I click on the test link in IE 7, by itself, it does not have the vulnerability.

The applications in question are accepting abitrary input and not validating correctly. 

How is that a Microsoft or Windows problem?

Don't get me wrong, I want to protect end-users as much as the next person (as does MS), but if it is the application not validating correctly, could there not be hundreds of potential characters and strings that cause input validation problems in particular circumstances, which will vary according to the application?

If Microsoft scrubs out every potential malicious character, it's bound to break lots of legitimate applications.  That would make plenty of users and developers mad.

At what point should Microsoft scrub URIs so that it hands off only "legitmate" characters "most of the time"?  How could Microsoft determine ahead of time what is and isn't legitimate characters to pass to applications they don't own?  If they block characters that affect certain applications, it might cause problems in other applications that have no problem with the character(s) in question?

What is the solution?  The easy answer is to block the % character in this particular instance...but that's just a whack-a-mole fix.  

I'm asking, with genuine interest and a listening ear, what is the best long term solution you envision, to solve the larger problem?

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/0470101555
*****************************************************************



-----Original Message-----
From: Juergen Schmidt [mailto:ju@...sec.de] 
Sent: Friday, October 05, 2007 8:59 AM
To: bugtraq@...urityfocus.com; full-disclosure@...ts.grok.org.uk
Subject: URI handling woes in Acrobat Reader, Netscape, Miranda, Skype

Hello,

the URI handling problem on Windows XP systems with IE 7 installed hits a lot of applications, not only Firefox (and mIRC) -- namely Skype, Acrobat Reader, Miranda, Netscape.

To recap: with the installation of IE 7 Microsoft changes the handling of URLs that are passed to the operating system on Windows XP. After this, URLs that contain an invalid "%" encoding can launch abitrary programms. One example is:

mailto:test%../../../../windows/system32/calc.exe".cmd

that launches the calculator when activated in affected applications. 
Firefox fixed this problem in 2.0.6. After being notified by heise Security, Skype fixed the problem in 3.5.0.239.


Still vulnerable (as of 4th of October) are:

Adobe Acrobat Reader 8.1: If a user clicks on such a link
in a PDF, calc.exe is executed.

Miranda v0.7: If a user klicks on this link in a chat window, calc.exe is 
executed

Netscape 7.1: mailto is handled by Netscape itself, but 
similar telnet:-links start the calculator.

This list can propably be extended with little effort.


On a question to MSRC if Microsoft is planning to react on this, we 
recieved the following response:

"After its thorough investigation, Microsoft has revealed that this is 
not a vulnerability in a Microsoft product." 


For further information see:

http://www.heise-security.co.uk/news/96982

bye, ju


-- 
Juergen Schmidt   editor-in-chief   heise Security     www.heisec.de
Heise Zeitschriften Verlag,    Helstorferstr. 7,       D-30625 Hannover
Tel. +49 511 5352 300      FAX +49 511 5352 417       EMail ju@...sec.de
GPG-Key: 0x38EA4970,  5D7B 476D 84D5 94FF E7C5  67BE F895 0A18 38EA 4970

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ