Fri, 10 Apr 2026 15:00:38 +0000 https://bugs.horde.org/ticket/5892 Linked attachment feature vulnerability 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". Thu, 15 Nov 2007 20:55:45 +0000 https://bugs.horde.org/ticket/5892#t38645 > 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 Fri, 16 Nov 2007 01:10:22 +0000 https://bugs.horde.org/ticket/5892#t38648 Poster wrote back clarifying that this is an XSS issue (http://blog.beford.org/?p=8). I'm still not sure that this is a vulnerability that we can solve in IMP. To the poster: what is your suggested solution here? Any particular site can turn off linked attachments. But any application that hosts files is "vulnerable" to this. So what can an app do, aside from disallowing jar files? Fri, 16 Nov 2007 04:13:15 +0000 https://bugs.horde.org/ticket/5892#t38651 I guess that won't do the job either... cause it doesn't matter the extension you use, the jar: protocol will interpret it as if it was a jar file... i think that the solution begins with "hiding" the original attachment. Another google example (this time a good one :P): http://mail.google.com/mail/?attid=0.1&disp=attd&view=att&th=1166689ac6fe384d I'm not sure, but i think that what happens in this situation, is that an internal script is run and then you have access to the desired attachment. But not directly. > Poster wrote back clarifying that this is an XSS issue > (http://blog.beford.org/?p=8). I'm still not sure that this is a > vulnerability that we can solve in IMP. > > To the poster: what is your suggested solution here? Any particular > site can turn off linked attachments. But any application that hosts > files is "vulnerable" to this. So what can an app do, aside from > disallowing jar files? Fri, 16 Nov 2007 04:43:59 +0000 https://bugs.horde.org/ticket/5892#t38653 > I guess that won't do the job either... cause it doesn't matter the > extension you use, the jar: protocol will interpret it as if it was a > jar file... i think that the solution begins with "hiding" the > original attachment. Another google example (this time a good one :P): > > http://mail.google.com/mail/?attid=0.1&disp=attd&view=att&th=1166689ac6fe384d > > I'm not sure, but i think that what happens in this situation, is > that an internal script is run and then you have access to the > desired attachment. But not directly. How does that help? By preventing the jar: prefix being on the URL, because you've done a redirect? I guess that might make sense, and if that's it that's a relatively simple change... Sat, 17 Nov 2007 06:05:46 +0000 https://bugs.horde.org/ticket/5892#t38693 Moving to HEAD; will have to be addressed there first no matter how far back any changes are backported. Sat, 17 Nov 2007 06:06:32 +0000 https://bugs.horde.org/ticket/5892#t38694 Well... now i've realized that the solution i mentioned earlier isn't possible too, cause: first the script retrives the file and next the jar: protocol acts. So.. I think that a good solution is to put a secure id in the attachment's URL, for each rcpt of the attachment. That way, no one (except the rcpt) would know the path to the file and the XSS attack won't be possible. Sat, 17 Nov 2007 17:54:00 +0000 https://bugs.horde.org/ticket/5892#t38695 Besides that we already have such an (pseudo) unique id, the timestamp, how would that help? The attacker, which would be the sender, would send the message to himself anyway. Sat, 17 Nov 2007 18:22:14 +0000 https://bugs.horde.org/ticket/5892#t38702 What is needed is not an unique id, it's a secret and unique id.. on gmail, for example, each rcpt receives an unique and secret id in his url, including the sender. A timestamp concatenated with a pseudo-random id, or something like that may be a solution. > Besides that we already have such an (pseudo) unique id, the > timestamp, how would that help? The attacker, which would be the > sender, would send the message to himself anyway. Sat, 17 Nov 2007 18:43:28 +0000 https://bugs.horde.org/ticket/5892#t38703 > What is needed is not an unique id, it's a secret and unique id.. on > gmail, for example, each rcpt receives an unique and secret id in his > url, including the sender. A timestamp concatenated with a > pseudo-random id, or something like that may be a solution. But the attachments are sent to email _recipients_, who don't have accounts. So how do you propose to enforce the uniqueness? The attacker could send them any valid id. Secret doesn't matter. Sat, 17 Nov 2007 18:46:26 +0000 https://bugs.horde.org/ticket/5892#t38706 The idea is that the server generate one unique id for each of the email recipients, in such a way that the recipient could only open his own attachment. Even if the attacker knows a valid id for his evil file, that id should only work with his own horde account. For the rest of the email recipients (who don't have accounts), there's no problem, cause the main problem here is that the file is located and run in the same domain of the recipient webmail account, that makes possible the attack to happen. If you have the evil script running on webmail.server1 and the victim has it's account on webmail.server2, the script won't have the right permissions to XSS the victim. For the "webmail.server1 attacker, webmail.server1 victim" problem, I think that it's possible to check which attachment is "visible" to which account. > But the attachments are sent to email _recipients_, who don't have > accounts. So how do you propose to enforce the uniqueness? The > attacker could send them any valid id. Secret doesn't matter. Sat, 17 Nov 2007 19:05:49 +0000 https://bugs.horde.org/ticket/5892#t38707 I guess the easier but uncool solution is to remove the "Link Attachments" feature ;) but i guess you don't want that... Sat, 17 Nov 2007 20:00:34 +0000 https://bugs.horde.org/ticket/5892#t38708 > I guess the easier but uncool solution is to remove the "Link > Attachments" feature ;) but i guess you don't want that... As I said earlier, people can already disable this with a configuration option. Tue, 20 Nov 2007 21:05:28 +0000 https://bugs.horde.org/ticket/5892#t38823 > Well... now i've realized that the solution i mentioned earlier isn't > possible too, cause: first the script retrives the file and next the > jar: protocol acts. Even with a redirect to a different protocol in between? Tue, 20 Nov 2007 21:06:13 +0000 https://bugs.horde.org/ticket/5892#t38826 I have an alternate thought here than the secret id craziness, and having to determine users by id and email address, which seems really unworkable if you think about forwarding, aliases, and a bunch of other stuff. My head spins. Isn't the simplest answer here to just add an intermediate page? Make it impossible to download a linked attachment directly - you have to go to the page first, get a token that's valid for a few minutes, make a POST request, etc., then you get the file. That way no jar: link could link directly to a file. Tue, 20 Nov 2007 21:10:15 +0000 https://bugs.horde.org/ticket/5892#t38829 > Isn't the simplest answer here to just add an intermediate page? Make > it impossible to download a linked attachment directly - you have to > go to the page first, get a token that's valid for a few minutes, > make a POST request, etc., then you get the file. That way no jar: > link could link directly to a file. Sounds good. Tue, 20 Nov 2007 21:18:53 +0000 https://bugs.horde.org/ticket/5892#t38832 > Sounds good. Agreed. Tue, 20 Nov 2007 21:43:22 +0000 https://bugs.horde.org/ticket/5892#t38835 > As I said earlier, people can already disable this with a configuration option. I guess that doesn't count as an argument, cause if you are suggesting that as a good option, then, for the system's security, it shouldn't be implemented in the first place. > I have an alternate thought here than the secret id craziness, and > having to determine users by id and email address, which seems really > unworkable if you think about forwarding, aliases, and a bunch of > other stuff. My head spins. > > Isn't the simplest answer here to just add an intermediate page? Make > it impossible to download a linked attachment directly - you have to > go to the page first, get a token that's valid for a few minutes, > make a POST request, etc., then you get the file. That way no jar: > link could link directly to a file. I don't know if that "secret id craziness" is that crazy, cause it's how google does it; but maybe i've expressed my self wrong. If you think that's the right solution, ok, but remember that the "jar:" will operate after the url is resolved, and the file retrieved. Tue, 20 Nov 2007 22:24:52 +0000 https://bugs.horde.org/ticket/5892#t38836 >> Isn't the simplest answer here to just add an intermediate page? Make >> it impossible to download a linked attachment directly - you have to >> go to the page first, get a token that's valid for a few minutes, >> make a POST request, etc., then you get the file. That way no jar: >> link could link directly to a file. > > I don't know if that "secret id craziness" is that crazy, cause it's > how google does it; but maybe i've expressed my self wrong. If you > think that's the right solution, ok, but remember that the "jar:" > will operate after the url is resolved, and the file retrieved. ... which is solved by an intermediate page, if not a redirect (I didn't see an answer to that question), right? Think about the ids for a minute. Say someone has an email address on server2 that forwards back to server1. When the attacker sends the message to the server2 address, it'll have to generate a guest id. Then the victim will read it when logged in to server1, and all we can do, maybe, is to say that you can't see this attachment, because we have no record of the email having been sent to the victim at their server1 account. The whole thing seems fragile to me. Tue, 20 Nov 2007 22:52:17 +0000 https://bugs.horde.org/ticket/5892#t38839 > Think about the ids for a minute. Say someone has an email address on > server2 that forwards back to server1. When the attacker sends the > message to the server2 address, it'll have to generate a guest id. > Then the victim will read it when logged in to server1, and all we > can do, maybe, is to say that you can't see this attachment, because > we have no record of the email having been sent to the victim at > their server1 account. The whole thing seems fragile to me. attachment received from the attacker's email with unique_id = 10 received (not even the attacker knows that id, just the rcpt): if the rcpt is authenticated on the server's imp system: if the unique_id corresponds to the logged user: success! else: fail! else: success! (cause then, it wont happen any XSS attack) Maybe that's too complicated, cause maybe i'm not think well about all the problems that it raises, so, let's get back to the other solution mentioned... > ... which is solved by an intermediate page, if not a redirect (I > didn't see an answer to that question), right? Well, i have to say that when you adopted my "redirect" suggestion, i didn't thought that it was a bit modified, cause, my google's previous example (when i explained my redirection idea) won't work on this situation, but i think that a solution with an intermediate page, as you said, it's ok. Tue, 20 Nov 2007 23:17:44 +0000 https://bugs.horde.org/ticket/5892#t38840 It looks like the Mozilla folks at least accepted that this is their own bug: http://blog.mozilla.com/security/2007/11/16/jar-protocol-xss-security-issues/ We should wait for their final measures to deal with that problem and then reconsider if we still need to add some additional protection. Wed, 21 Nov 2007 12:23:33 +0000 https://bugs.horde.org/ticket/5892#t38851 > We should wait for their final measures to deal with that problem and > then reconsider if we still need to add some additional protection. Fixed in FF 2.0.0.10: http://www.mozilla.org/security/announce/2007/mfsa2007-37.html Tue, 27 Nov 2007 19:44:57 +0000 https://bugs.horde.org/ticket/5892#t39095 Seems to me like we should make sure not to send those particular mime types, and otherwise this should be okay now. Tue, 27 Nov 2007 22:20:04 +0000 https://bugs.horde.org/ticket/5892#t39098 Done. http://lists.horde.org/archives/cvs/Week-of-Mon-20071203/072892.html Tue, 04 Dec 2007 08:23:10 +0000 https://bugs.horde.org/ticket/5892#t39329 Wow, just found out about this exploit. Limited employees at our company have mail, however, they can store files in their accounts and give out URL's to all employees allowing access to pictures, documents and other. All of this sharing was going on "under the radar" - have not tried yet to see if this is where they are storing MP3's - So much for being able to control access ! Tue, 22 Jun 2010 11:00:04 +0000 https://bugs.horde.org/ticket/5892#t59197