Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

XSS in Roundcube using Flash files #4014

Closed
rcubetrac opened this Issue Nov 21, 2012 · 11 comments

Comments

Projects
None yet
1 participant

Reported by enriquerando on 21 Nov 2012 14:54 UTC as Trac ticket #1488828

An attacker can use Flash files to run Javascript in the context of the current roundcube session

Keywords: xss, flash
Migrated-From: http://trac.roundcube.net/ticket/1488828

Comment by @alecpl on 21 Nov 2012 17:47 UTC

Am I right that this is again Internet Explorer only issue?

Milestone changed by @alecpl on 21 Nov 2012 17:47 UTC

later => 0.9-beta

Comment by @alecpl on 21 Nov 2012 17:50 UTC

Oops, I didn't read carefully. Could you provide a sample message?

Comment by enriquerando on 21 Nov 2012 19:56 UTC

Replying to alec:

Oops, I didn't read carefully. Could you provide a sample message?

Actually, it is easier to exploit this vulnerability in Firefox than in IE since in Roundcube's attachment page, the attached file is placed directly inside an IFRAME.

In cases like this, Firefox automatically creates a window.document for the IFRAME object while IE doesn't, so expressions like window.document raise an exception in IE and work perfectly ok in Firefox. That's the reason why in the example in the document I use window.parent.document (to refer to the main window document object, that exists in both browsers).

With respect to your question "Could you provide a sample message?", I guess I don't understand what you are asking me to provide. If you need a SWF file I could send you a standalone one so that you can send it and receive it by email and test it on different environments. Anyway, as that would make you trust a file you doesn't know, I think it would be better for you to compile a slightly modified version of the one I provide in the PDF document, replacing the JavaScript code inserted inside the document object. Something like:

package {
    import flash.display.Sprite;

    import flash.external.ExternalInterface;

    public class poc extends Sprite{


        public function poc() {
            ExternalInterface.call('eval',

            'window.parent.document.write("<script>alert(111)</script>")');
        }
    }
}

(I hope I didn't make any typo)

You can compile it with the Flex SDK:
http://www.adobe.com/devnet/flex/flex-sdk-download.html

To compile it and create the swf file, just run from the command line

mxmlc poc.as

Don't hesitate to contact me for any other info you may need.

Comment by @thomascube on 27 Nov 2012 11:42 UTC

This turns out to be kind of a styling problem. Since there's no specific attachment icon defined for application/x-shockwave-flash, the file extension .txt is used. To avoid accidental opening of such faked attachments we could either remove application/x-shockwave-flash from the list of files which can be displayed by the browser. But that can be overridden by local config.

Better protection could be achieved by checking the file extension or even Content-Type headers against the real content type of an attachment file and show a warning if they don't match. But this requires some more local configuration to add a mapping table of mime-type => file extensions. A mapping file like this usually is part of the Apache webserver and the path just needs to be configured.

Comment by @thomascube on 27 Nov 2012 15:31 UTC

Fix to detect fake attachments added in 928cb34...c14b337

This however requires a correctly configured installation of Roundcube. Especially the config options 'mime_magic' and 'mime_types' are relevant for the correct detection of file mime-types and their extensions.

Status changed by @thomascube on 27 Nov 2012 15:31 UTC

new => closed

@rcubetrac rcubetrac closed this Nov 27, 2012

Comment by enriquerando on 27 Nov 2012 16:17 UTC

Sorry. I had no time to analize the solution yet. But from the message that changes the status of the ticket to "closed" I am not sure if the solution involves only fake type attachments or all SWF attachments.

Does this solution work for SWF files with SWF extensions?

I mean: if a user is tricked into clicking on an malicious flash file attachment with SWF extension... would the Javascript code be executed on the context of the RoundCube session?

Replying to thomasb:

Fix to detect fake attachments added in 928cb34...c14b337

This however requires a correctly configured installation of Roundcube. Especially the config options 'mime_magic' and 'mime_types' are relevant for the correct detection of file mime-types and their extensions.

Comment by @thomascube on 30 Nov 2012 09:59 UTC

Replying to enriquerando:

Sorry. I had no time to analize the solution yet. But from the message that changes the status of the ticket to "closed" I am not sure if the solution involves only fake type attachments or all SWF attachments.

Does this solution work for SWF files with SWF extensions?

No it doesn't. If a user decides to open a flash files which is declared as a flash file Roundcube doesn't block it. It's the same as opening a Word file with some malicious VB code inside.

I mean: if a user is tricked into clicking on an malicious flash file attachment with SWF extension... would the Javascript code be executed on the context of the RoundCube session?

Yes. The only way around that would be a sandboxed environment (e.g. another host/domain) where attachments are opened.
But one can disable flash files from being opened in the browser and sent for download instead. This can be done by manually overriding the 'client_mimetypes' config option in Roundcube.

Comment by enriquerando on 30 Nov 2012 10:43 UTC

Replying to thomasb:

"one can disable flash files from being opened in the browser and sent for download instead"

I think this should be the default configuration. SWF files may be dangerous as there are more ways to make the browser open the flash file, in addition to the one I mentioned in my last message.

For instance, the attacker could send a message with the SWF as an attachment and a link to a remote web server. This remote web server being controlled by the attacker.

Examinig the "Referer" HTTP header from the request, the malicious web server could determine the URL that makes the browser open the attachment.

Then it could return a web page with a hidden IFRAME opening the URL obtained in the previous step. Then, then SWF would be opened and the JavaScript code executed.

Comment by enriquerando on 30 Nov 2012 10:45 UTC

Replying to thomasb:

"one can disable flash files from being opened in the browser and sent for download instead"

I think this should be the default configuration. SWF files may be dangerous as there are more ways to make the browser open the flash file, in addition to the one I mentioned in my last message.

For instance, the attacker could send a message with the SWF as an attachment and a link to a remote web server. This remote web server being controlled by the attacker.

If the user clicks on the link, the malicious web server could determine the URL that makes the browser open the attachment by examinig the "Referer" HTTP header from the request.

Then it could return a web page with a hidden IFRAME opening the URL obtained in the previous step. Then, then SWF would be opened and the JavaScript code executed.

@rcubetrac rcubetrac added this to the 0.9-beta milestone Mar 20, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment