1 message in net.sourceforge.lists.courier-sqwebmail[sqwebmail] Re: [SECUNIA] Vulnerabili...
FromSent OnAttachments
Sam VarshavchikAug 24, 2005 4:01 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:[sqwebmail] Re: [SECUNIA] Vulnerability in SqWebMailActions...
From:Sam Varshavchik (mrs@courier-mta.com)
Date:Aug 24, 2005 4:01:02 am
List:net.sourceforge.lists.courier-sqwebmail

Thomas Kristensen writes:

Hello Sam,

I believe that you fail to understand the impact of this.

This is the most hillarious thing I've read in a long time:

Beware of opening attachments from unknown sources! They may contain hostile and malicious content, that pretends to be benign!

Thank God we have all these security vendors that get paid, in order to give us such profound advice!

This kind of issue has been rated as and regarded as a vulnerability by other vendors of web mail programs.

Really? Would you be kind enough to enlighten me as to what other “vendors” do in order to properly address this alleged “vulnerability”?

If you still believe this isn't a problem in SqWebMail, and your only "fix" is to display the mime/type, then we will be releasing this information tomorrow (25th August).

You are welcome to release it any time. The change has been rolled out and announced, already.

-- Kind regards,

Thomas Kristensen CTO

Secunia Hammerensgade 4, 2. floor DK-1267 Copenhagen K Denmark

Tlf.: +45 7020 5144 Fax: +45 7020 5145

On Tue, 2005-08-23 at 18:58 -0400, Sam Varshavchik wrote:

Jakob Balle writes:

This will result in SqWebMail displaying an attached file, giving the options to either "Display" or "Download" the file "test.jpg". Since this is an "image", close to all users would naturally choose "Display". Hereafter, in this scenario, SqWebMail will display the contents of the file (the html/script) in context of SqWebMail, resulting in cross-site scripting, making the attacker able to do anything the web mail user can do.

I hope this sheds some light over the issue.

We have assigned SA16539 to this vulnerability and set a preliminary release date of the 7th September. We are naturally prepared to push the release date if you require more time to properly fix the vulnerability.

Well, even if the MIME content would, in fact, be image/jpeg, in your little example, that by no means eliminates the possibility of malicious content from an untrusted source.

After all, we've all just went through a number of known issues with various implementation bugs in jpeg decompression libraries being exploitable through a hand-crafted image file causing buffer overflows during decoding.

If you have a mail from an untrusted source, and you explicitly instruct the browser to open an attachment, and the attachment contains malicious content, then this really falls under the "Doctor, it hurts when I do this/Well, don't do that, then" category.

The only thing I'm going to do is show the attachment's given MIME content-type. When the state of computer science advances to the point where it becomes algorithmically possible to deterministically evaluate the maliciousness level of arbitrary content, then appropriate enhancements would of course be put in place. But, unless you know something that I don't, this is far from the current state of contemporary technology to evaluate. So, in the meantime, giving the attachment's MIME content type is the only thing that I can do.

I have no problem with 2005.09.07 release date. You should indicate in your announcements that: sqwebmail builds dated 20050823, or later, will show each attachment's MIME content type, and a patch for older versions can be downloaded from: http://www.courier-mta.org/beta/patches/sqwebmail-mimetype-display/