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
juheisec.de
GPG-Key: 0x38EA4970,  5D7B 476D 84D5 94FF E7C5  67BE F895
0A18 38EA 4970

[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_grimesinfoworld.com or rogerbanneretcs.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:juheisec.de] 
Sent: Friday, October 05, 2007 8:59 AM
To: bugtraqsecurityfocus.com; full-disclosurelists.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
juheisec.de
GPG-Key: 0x38EA4970,  5D7B 476D 84D5 94FF E7C5  67BE F895
0A18 38EA 4970

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

----- Original Message ----- 
From: "Thierry Zoller" <ThierryZoller.lu>

> 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 ?

If the application is what exposes the URI handling routine
to untrusted 
code from the internet, then it's the application's job to
make sure that 
code is trusted before exposing system components to it's
commands, no?

In this case how is acrobat reader any different than
telnetd? If telnetd 
exposes system functions to untrusted users (no password
required) who is 
supposed to enforce security? In the case of acrobat reader,
it's acrobat 
exposing the system to untrusted sources and it should be
that application 
that is responsible for mitigation of attacks via those
exposed interfaces.

Geo. 

Dear Geo.,

G> If the application is what exposes the URI handling
routine to untrusted
G> code from the internet,
Sorry, Untrusted code from the internet ?

The user clicks on a mailto link, is that untrusted code?
Or the mailto link is clicked for him.

Anyways, the mailto link
POST IE7 has a flaw/threat/vulnerablity it hasn't had PRE
IE7.

G>  then it's the application's job to make sure that
G> code is trusted before exposing system components to
it's commands, no?
Yes to a certain degree it is, like I said mitigation is
fine, though
it shouldn't be the final word here, _if_ my assumptions I
derive from
the things I know and just tested are correct. I might be
wrong, but I
dont' think so =)

The problem here is the root cause, the root cause is that
IE7
introduced a problem, you can call it
"vulnerability" or "Threat" or
whatever floats your boat, I don't care, my point is, in my
opinion
the handler itself is broken.


-- 
http://secdev.zoller.lu
Thierry Zoller
Fingerprint : 5D84 BFDC CD36 A951 2C45  2E57 28B3 75DD 0AC6
F1C7

In my opinion, every application should handle incoming data
as bad data. 
Its poor programming to assume that incoming data is
properly formatted and 
safe to process as is, even if the data is supposed to come
from a process 
you own. Why so extreme? Because the bad guys are going to
figure out how to 
get bad data to your code using pathways you didn't
consider. In other 
words, I agree with Geo that each of the applications should
inspect the URI 
before processing it. The OS components that are involved
should too, but 
the 3rd party apps should never assume that IE or whatever
has done so.

--------------------------------------------------
From: "Thierry Zoller" <ThierryZoller.lu>
Sent: Saturday, October 06, 2007 1:06 PM
To: <bugtraqsecurityfocus.com>;
<full-disclosurelists.grok.org.uk>
Subject: Re[2]: [Full-disclosure] URI handling woes in
Acrobat Reader, 
Netscape,Miranda, Skype

> Dear Geo.,
>
> G> If the application is what exposes the URI
handling routine to 
> untrusted
> G> code from the internet,
> Sorry, Untrusted code from the internet ?
>
> The user clicks on a mailto link, is that untrusted
code?
> Or the mailto link is clicked for him.
>
> Anyways, the mailto link
> POST IE7 has a flaw/threat/vulnerablity it hasn't had
PRE IE7.
>
> G>  then it's the application's job to make sure
that
> G> code is trusted before exposing system components
to it's commands, no?
> Yes to a certain degree it is, like I said mitigation
is fine, though
> it shouldn't be the final word here, _if_ my
assumptions I derive from
> the things I know and just tested are correct. I might
be wrong, but I
> dont' think so =)
>
> The problem here is the root cause, the root cause is
that IE7
> introduced a problem, you can call it
"vulnerability" or "Threat" or
> whatever floats your boat, I don't care, my point is,
in my opinion
> the handler itself is broken.
>
>
> -- 
> http://secdev.zoller.lu
> Thierry Zoller
> Fingerprint : 5D84 BFDC CD36 A951 2C45  2E57 28B3 75DD
0AC6 F1C7
>
> 

Juergen Schmidt wrote:

> 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.

Testing shows that the mailto: thingy in Acrobat also works
on Windows
2003 Server, SP2.


-- 
Mit freundlichen Gruessen
Andreas Lindenblatt

Solution - The Computer People e.K.
Apoldaer Weg 7, 68309 Mannheim
Amtsgericht Mannheim, HRA 4576

-- Some people have twenty years of experience, some people
have
one year of experience twenty times over. -- Anonymous

http://www.solution.de
fon:  +49 621 715112 / fax:  +49 621 7140721

----- Original Message ----- 
From: "Thierry Zoller" <ThierryZoller.lu>

> The user clicks on a mailto link, is that untrusted
code?

Depends on where the link comes from. If it's a shortcut on
the users 
desktop no it's not untrusted, if it's in a PDF file you
received in your 
email then yes it's untrusted.

> Anyways, the mailto link
> POST IE7 has a flaw/threat/vulnerablity it hasn't had
PRE IE7.

> The problem here is the root cause, the root cause is
that IE7

Ok I'm game, so then show me this exploit without having
Acrobat on your 
system. IE7 handles mailto links in untrusted web pages. Put
the mailto link 
in an untrusted html page and make it work with IE7.

Geo. 

Juergen Schmidt wrote:

> 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 be more specific:

A custom .pdf with a link inside like this:

>
mailto:test%../../../../windows/system32/calc.exe".cmd
(You can just put a full page sized button behind the text
and use the
mouseover event of Acrobat, so there's no click necessary)

starts successfully calc.exe on a Windows 2003 Server.

Tested on:

W2003 SBS(german, SP2) IE7, Adobe Reader 8.1
W2003 R2 (german, SP2) IE7, Adobe Reader 8.1
W2003 R2 with Citrix on top, IE7, Adobe Reader 8.1

This is also true for Terminal-Sessions.

Editing of the registry key as advised by Adobe works like
advertised,
you just get an error message.


-- 
BYE Andreas

Solution - The Computer People e.K.

-- Some people have twenty years of experience, some people
have
one year of experience twenty times over. -- Anonymous

Geo. ha scritto:
> I don't agree. Whatever program takes input from an
untrusted source, it's 
> that programs duty to sanitize the input before passing
it on to internal 
> components. It's like a firewall, you filter before it
gets inside the 
> system.

NO! wrong! stop the "input sanitization" fallacy!
Input is perfectly
fine. Input goes into a parser, an abstract form comes out.
You operate
internally on the abstract form, which is (hopefully!)
designed to avoid
all the ambiguities of the text form you get from input. You
take UTF-8
in? you'd better operate on its UTF-16 or UTF-32 equivalent
then. You
take XML? deserialize into the corresponding object from
your data
model. And so on. The interesting issue is handing out your
abstract
form to an outside component. Think about it. SQL
injections? outputting
to a database engine. XSS? outputting to a DOM engine. Path
traversal?
outputting to an I/O model's path parser. This is not
something you can
just shoehorn in your application at any later time. You
need to know
beforehand if you have any problematic external components,
which e.g.
won't take Unicode input, and devise strategies that don't
cause loss of
fidelty: store the password's SHA-1 in hex maybe? or pass
the sort key
(see <http://blogs.msdn.com/michkap/archive/2007/09/2
4/5085893.aspx>) in
the invariant locale instead of the actual string, if the
component only
needs to be able to compare strings for equality/collation
order. No
excuses. Information is sacred and irreplaceable, and input
filtering an
unacceptable blasphemy. If you filter input, you haven't
thought hard enough

> Example, an ftp server has to sanitize filenames to
prevent useage of 
> streams on NTFS, you don't blame the filesystem that
the input gets passed 
> to, it's the job of the ftp server to do the sanitizing
of untrusted input.

See what I mean? The server needs to deserialize the input
(converting
it from whatever implied charset into an internal
representation), and
then serialize it again into the native form of the target
component
it's outputting to (UTF-16 Unicode in NT path syntax, in
this case). If
the format is a delimited or otherwise marked-up string (as
paths are),
special characters must be quoted. If a character cannot be
quoted (as
the NTFS colon can't), you raise an error. The error bubbles
up to the
client. That's the way you do it. Not any other way. You are
getting it
right only by chance, you are messing up the hierarchy of
components and
their responsibilities. You are forcing the layer that is
the furthest
from the external component to deal with its subtleties