Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Content checks for inline attachments #3372

Closed
rcubetrac opened this issue May 2, 2011 · 7 comments

Comments

Projects
None yet
1 participant
@rcubetrac
Copy link

commented May 2, 2011

Reported by @thomascube on 2 May 2011 09:25 UTC as Trac ticket #1487895

Contents of attachments (such as pictures) which are embedded in HTML (multipart/related) messages should be checked before sending them to the client.

Internet Explorer executes javascript code within images (!) if <script>... exists in content. It entirely ignores mimetype headers but does content sniffing.

This is a XSS vulnerability which exists when using Internet Explorer and is an attack that takes advantage of a bug which exists in the web browser.

Reproduction Procedure:

Disguise HTML which contains a SCRIPT tag as a picture file (.jpg, .gif, etc.) or create a picture file that contains a SCRIPT tag and attach it. Send this email and when this attachment is opened/viewed, the javascript is executed.

Migrated-From: http://trac.roundcube.net/ticket/1487895

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Aug 3, 2011

Comment by @alecpl on 3 Aug 2011 19:23 UTC

See duplicate #1488020 for examples.

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Nov 3, 2011

Comment by Enrico204 on 3 Nov 2011 22:04 UTC

I've attached a possibile workaround to clean attachment.

This bug is IE-related (<= 8), and it's fixed in IE9 only: Internet Explorer reads the file content ignoring the content-type served.

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Nov 29, 2011

Comment by @thomascube on 29 Nov 2011 08:40 UTC

@Enrico204: I'm sorry but your patch isn't a proper solution for this. While it may solve the issue of this ticket it will break some other use cases where people want to download (unmodified) attachments. Also it requires to load all attachment contents into PHP memory which may exhaust some resources and lead to errors. We had good reasons to circumvent output buffering and to pass attachments directly to the client line by line. All this has to be tanken into account when trying to solve this issue.

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Nov 29, 2011

Comment by @alecpl on 29 Nov 2011 09:54 UTC

A solution for memory issue would be stream wrapper (see stream_wrapper_register() function).

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Nov 29, 2011

Comment by @thomascube on 29 Nov 2011 10:27 UTC

Implemented in 57486f6

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Nov 29, 2011

Status changed by @thomascube on 29 Nov 2011 10:27 UTC

new => closed

@rcubetrac rcubetrac closed this Nov 29, 2011

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Nov 29, 2011

Comment by @alecpl on 29 Nov 2011 10:45 UTC

Please read #1488020. This can be used for any attachments not only embed. An attacker can provide a link to attachment (or any message part) without _embed parameter.

@rcubetrac rcubetrac added this to the 0.7-stable milestone Mar 20, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.