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]
Date: Fri, 22 Jun 2007 12:42:13 +0900
From: "HASEGAWA Yosuke " <yosuke.hasegawa@...il.com>
To: Full-Disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: 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+DQo8c2NyaXB0PmFsZXJ0KGRvY3VtZW50LmxvY2F0aW9uKTs8L3NjcmlwdD4NCjwv
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-February/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/

Powered by blists - more mailing lists