bugtraq - Fwd: [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>] [day] [month] [year] [list]

Message-ID: <d0bf6bdc0710101635u4257b352j16d6413bebe7ef04@mail.gmail.com>
Date: Wed, 10 Oct 2007 13:35:54 -1000
From: merigoth@...il.com
To: bugtraq@...urityfocus.com
Subject: Fwd: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape,Miranda, Skype

I know I've jumped on this conversation late, but it seems to me that this
is not a "URI/RL" handling problem. Like was mentioned earlier, this is
probably a content-type/file association/command string handling problem. I
was recently researching the image file "exploit" from splitbrain.org (
http://www.splitbrain.org/blog/2007-02/12-internet_explorer_facilitates_cross_site_scripting).
During the research, I ran across the IE7's dev team's blog (
http://blogs.msdn.com/ie/archive/2005/02/01/364581.aspx) where they describe
how IE7 determines how to process content based upon the first 256bytes of
the information rather than directly based upon how information is passed
from the server. I quote "If it cannot find the clsid, the file will be Shell
Executed<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/shellexecute.asp>and
shell will use the extension to determine the application to handle
the
file." So, I wonder if these two incidents are some how related at the shell
process level.

In the original posting, The string (
mailto:test%../../../../windows/system32/calc.exe".cmd<test%../../../../windows/system32/calc.exe".cmd>)
would be processed as a command script as indicated by the percent sign
(variable identifier) and the ".cmd" and "overwrite" the mailto initator. In
the case of the ".doc" and ".txt", it appears the final association will
determine how the rest of the string is processed.

File association plays a role because command line will attempt to launch
the default mail handler. This seems to indicate the problem is at a "lower"
level than the browser/mail client. This would explain why it works equally
well despite having Firefox, IE7, thunderbird, or outlook.

Based upon the IE7 blog posting, it seems this fundamental change may have
been introduced with IE7/XPSP2. However, this is mainly theory. I have
tested the "malicious" string on an XP (no service pack) and IE6. The string
was processed as described. Meaning the default mail-client (in this case
outlook express6) launched with the string in the "TO:" line of a blank
email.

All of this may seem obvious, and if I'm re-stating information, I
apologize. As far as possible mitigation techniques, microsoft also
described the "new functionality" of XP SP2 in this tech net article,
http://technet.microsoft.com/en-us/library/bb457150.aspx. They describe what
registry settings can affect how content logic can be forced. I haven't
really tested this solution because I've been busy. But these are some loose
thoughts on the subject.

merigoth