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 !

Done.

http://lists.horde.org/archives/cvs/Week-of-Mon-20071203/072892.html

Seems to me like we should make sure not to send those particular mime 
types, and otherwise this should be okay now.

Fixed in FF 2.0.0.10:

http://www.mozilla.org/security/announce/2007/mfsa2007-37.html

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.

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...
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.

... 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.

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 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.

Agreed.

Sounds good.

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.

Even with a redirect to a different protocol in between?

As I said earlier, people can already disable this with a 
configuration option.

I guess the easier but uncool solution is to remove the "Link 
Attachments" feature ;) but i guess you don't want that...

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.

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.

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.

Moving to HEAD; will have to be addressed there first no matter how 
far back any changes are backported.

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...

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?

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

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".