Thread-topic: [Full-disclosure] MS07-034: Executing arbitrary script with mhtml:protocol handler
> -----Original Message-----
> From: full-disclosure-bounces@xxxxxxxxxxxxxxxxx
> [mailto:full-disclosure-bounces@xxxxxxxxxxxxxxxxx] On Behalf
> Of HASEGAWA Yosuke
> Sent: Friday, June 22, 2007 7:42 AM
> To: Full-Disclosure@xxxxxxxxxxxxxxxxx; bugtraq@xxxxxxxxxxxxxxxxx
> Subject: [Full-disclosure] MS07-034: Executing arbitrary
> script with mhtml:protocol handler
>
> MS07-034: Executing arbitrary script with mhtml: protocol handler
>
> Author:Yosuke HASEGAWA <yosuke.hasegawa at gmail.com>
> Date: Wed, 21 Jun 2007
> CVE: CVE-2007-2225, CVE-2007-2227
>
> Original advisory:
> http://openmya.hacker.jp/hasegawa/security/ms07-034.txt
> http://archive.openmya.devnull.jp/2007.06/msg00060.html
>
> Abstract:
> In Internet Explorer, with mhtml: protocol handler and using Outlook
> Express's feature, arbitrary resources (such as HTML, image,
> application
> file and so on) can opened as MHTML formatted file and
> Content-Type: is
> disregarded.
>
> It is possible to treat by text/html including JavaScript
> encoded base64
> or Quoted-Printable in MHTML format.
> Therefore, it was possible to have bypassed filtering of the dangerous
> character (or string) usually carried out in the Web
> application of the
> large range, and to have execute arbitrary scripts.
>
> Tested version:
> Outlook Express 6 / Internet Explorer 6 / Internet Explorer 7
>
> Details:
> In IE, When the prefix of "mhtml" is given to the URL and it accesses
> a resource, the function of OE is used( mhtml protocol
> handler is called),
> and IE deals with that resource as a MHTML(RFC2557) formatted
> document.
>
> The behavior of IE is peculiar as follows when a document is opened as
> a MHTML form through mhtml: protocol handler.
>
> - Content-Type: HTTP response header is ignored.
> - It doesn't depend on the setting "Open files based on content, not
> file extension", and "MHTML" is always forced as a file type for the
> resource.
> - In the MHTML document, Separated from the MHTML header by a
> MHTML body
> by the CR/LF in HTTP response body.
> - In the MHTML document, encoding by base64 or Quoted-Printable can be
> used for the MHTML body part by specifying it with a MHTML header.
> - In the MHTML document, text/html document type can be used for the
> MHTML body part by specifying it with a MHTML header and can be
> included script in the body part.
> - "Content-Disposition: attachment" HTTP response header is ignored,
> and the resource is opened without user's confirmation.
>
> Therefore, even if it was it to the Web application that it coped with
> it suitably, script was put in the form encoded with base64
> and Quoted-
> Printable inside, and it was possible that XSS was made to occur.
>
> For example,
>
> --
> <html><body><div>
> <!-- begin of input from user(escaped properly as HTML) -->
> Subject: test
> Content-Type: text/html; charset=us-ascii
> Content-Transfer-Encoding: base64
>
> PGh0bWw+DQo8c2NyaXB0PmFsZXJ0KGRvY3VtZW50LmxvY2F0aW9uKTs8L3Njcm
> lwdD4NCjwv
> aHRtbD4NCg==
> <!-- end of input -->
> </div></html>
> --
>
> Open this HTML file through the mhtml: protocol handler such as
> <mhtml:http://example.com/test.html>,
> IE/OE assumed the file as MHTML, not HTML, including script encoded by
> base64. The script is encoded by base64, Because it is being encoded
> with base64, script passes through the web application's
> filter, and it
> is possible that XSS is made to occur.
> In order to ignore Content-Type: header completely, includes the MHTML
> contents, it was possible even in XML, images, application fille like
> as *.doc, and the like not only HTML to execute the script.
>
> Background:
> May 2004
> The publication by the first discoverer (probably).
> (Japanese contents)
>
> http://web.archive.org/web/20040607114853/www2.sala.or.jp/~uuu
> /security/jpeg1.html
> Jul 2004
> Article of Slashdot Japan "Many Unmeasures vulnerability
> discoverd in Japan"
> is published. (Japanese contents)
> http://slashdot.jp/security/article.pl?sid=04/07/29/0635211
> Feb 2005
> [Full-Disclosure] Possible XSS issue on Windows XPSP2 IE6 via MIME
> Encapsulation of Aggregate HTML
>
> http://lists.grok.org.uk/pipermail/full-disclosure/2005-Februa
> ry/032058.html
> Sep 2006
> Ask to grasp it as a vulnerability in Microsoft about this.
> Oct 2006
> Response from Microsoft, "Behavior by design of IE".
> Oct 2006
> Report to Microsoft that the XSS is made to occur and can
> steel Cookie by
> using this behavior on on search.microsoft.com / search.live.com /
> search.msn.com.
> Oct 2006
> Report to Microsoft via IPA/ISEC as the vulnerability of Web
> application
> that the XSS is made to occur and can steel Cookie by
> using this behavior on on spaces.live.com / msn.co.jp.
> Oct 2006
> Report to Microsoft via IPA/ISEC as the vulnerability of IE,
> about the
> "Content-Disposition: attachment" header is ignored via mhtml:
> protocol handler.
> Dec 2006
> Received the contact to deal with handling this case as a
> vulnerability
> of OE from Microsoft via IPA/ISEC.
> Jun 2007
> Security fix for OE released as MS07-034.
>
> Acknowledgment:
> I appreciate deeply hoshikuzu|star_dust who told me the problem that
> it is introduced to the public in 2004 existing for 2006
> years even in
> the moment, the offer of PoC, and various information.
>
> --
> HASEGAWA Yosuke
> yosuke.hasegawa at gmail.com
> Microsoft MVP for Windows - Security (Oct 2005 - Sep 2007)
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>