[Tickets #5892] Re: Linked attachment feature vulnerability

[bugs at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=5892
-----------------------------------------------------------------------
 Ticket             | 5892
 Updated By         | Chuck Hagenbuch <chuck at horde.org>
 Summary            | Linked attachment feature vulnerability
 Queue              | IMP
 Version            | 4.1.3
 Type               | Bug
-State              | Unconfirmed
+State              | Feedback
-Priority           | 3. High
+Priority           | 2. Medium
 Owners             | 
-----------------------------------------------------------------------


Chuck Hagenbuch <chuck at horde.org> (2007-11-15 17:10) wrote:

> By exploiting the jar: protocol feature of Mozilla Firefox and the 
> fact that the Imp Web Client allows things like 
>
"https://mail.server/horde/imp/attachment.php?u=user&t=4827164921&f=example.jpg",
it's possible to execute various XSS attacks. For example: 
>
"jar:https://mail.server/horde/imp/attachment.php?u=user&t=4827164921&f=example.jar!/evil.htm".

I'm certainly sensitive to security concerns, but there are several
reasons I don't think this is a vulnerability in IMP itself, though IMP
might be "involved" in exploiting it:

- When downloading linked attachments, we send a content-disposition of
attachment. If the browser displays files directly anyway... there's only
so much we can do about that.

- If I'm reading correctly, you have to prepend jar: to the URL for this
to happen. IMP will never do that, so someone would have to send a
hand-crafted email containing the malicious URL.

- If the attacker is crafting their own URL anyway, isn't it a lot simpler
to put their malicious file somewhere else, and to make it look more
enticing then an email attachment? Admittedly this is a dodge, but I think
the other reasons are more valid.

- A user could upload other kinds of "bad" content to an attachment and
send them out. That makes this a file delivery mechanism - we should
probably have a hook for scanning and accepting/rejecting linked
attachments - but that's no more a vulnerability than an FTP site is.

If you don't disagree, I'll turn this into an enhancement ticket to add a
hook for scanning linked attachments (probably easier to have it handle all
attachments and accept/reject on initial upload, actually). If you do
disagree, please explain, and we'll see where we are.

Thanks,
Chuck