Likes: 
----=_0edib09dan6os27juq9aq5mjt7e5o15ke1.MFSBCHJLHS
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
I discovered a new XSS vuln in SquirrelMail which is quite dangerous
since it could be exploited simply by sending a specially crafted mail
to the victim. The victim only has to read the email in order to
trigger the exploit. This bug is present in latest versions (as well
as older ones).
I also noticed that latest Debian stable distro ships a very old
version of SquirrelMail, which is vulnerable to several old XSS bugs
(in addition to the new one).
Detailed info is included in attached advisory. Just in case of
problems with the attachment, you can download it from my site:
http://www.rs-labs.com/adv/RS-Labs-Advisory-2004-1.txt
=46inally, I'd like to publicly state that somebody is using my nickname
(RoMaNSoFt) for mass-defacing PHP-Nuke sites (and some other nasty
actions like claiming to be the author of docs written by me) in a
clear attempt to incriminate myself. I'm not either a defacer, neither
a cracker. So please, don't mistake that script-kiddie with the real
RoMaNSoFt. Contact me for additional information or if you've been
affected/attacked by this likely Moroccan kiddie.
Regards from Spain,
--Roman
- --
PGP Fingerprint:
09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742
[Key ID: 0xEAD56742. Available at KeyServ]
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
iQA/AwUBQLh7SOR/in3q1WdCEQL4kgCgjiwOlryda2lDHgszFmg3pX6tlrIAoLhR
34XnlOcYqsDDAv3Xl2A/5rzj
=3DGz6D
-----END PGP SIGNATURE-----
----=_0edib09dan6os27juq9aq5mjt7e5o15ke1.MFSBCHJLHS
Content-Type: text/plain; charset=ISO-8859-1; name=RS-Labs-Advisory-2004-1.txt
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename=RS-Labs-Advisory-2004-1.txt
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
- RS-Labs Security Advisory -
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
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=E1n Medina-Heigl Hern=E1ndez (a.k.a. RoMaNSoFt) =
<roman@rs-labs.com>
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).
=20
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=3D10, 11). I =
diff'ed the
sources. I noticed something like:
- - "<B>$mailer</B> " .
+ "<B>" . htmlentities($mailer) . "</B> " .
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 .=3D =
htmlentities(sqimap_find_displayable_name($senderN ames_part));
+ 'message' =
=3D> htmlentities($fdata[5]),
+ 'reminder' =
=3D> htmlentities($fdata[6]) );
+ " <TD ALIGN=3DLEFT BGCOLOR=3D\"$color[4]\">" . =
htmlentities($event_title) . "</TD></TR>\n".
+ " <TD ALIGN=3DLEFT BGCOLOR=3D\"$color[4]\">" . =
htmlentities($event_text) . "</TD></TR>\n".
+ "<B>" . htmlentities($mailer) . "</B> " .
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=3D\"$color[0]\" ALIGN=3DRIGHT =
VALIGN=3DTOP>" .
_("Mailer") . ': '.
"</TD><TD BGCOLOR=3D\"$color[0]\" VALIGN=3DTOP =
colspan=3D2>" .
- - "<B>$mailer</B> " .
+ "<B>" . htmlentities($mailer) . "</B> " .
'</TD>' .
"</TR>" . "\n";
=20
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 !=3D '') {
$senderName .=3D ', ';
}
- - $senderName .=3D =
sqimap_find_displayable_name($senderNames_part);
+ $senderName .=3D =
htmlentities(sqimap_find_displayable_name($senderN ames_part));
}
}
Both cases could be exploited in a simple way: the attacker sends an =
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 :-)).
=20
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 =3D formatAttachments($message,$ent_ar,$mailbox, =
$passed_id);
if ($attachmentsdisplay) {
echo ' </table>';
echo ' <table width=3D"100%" cellpadding=3D"1" cellspacing=3D"0" =
align=3D"center"'.' border=3D"0" bgcolor=3D"'.$color[9].'">';
echo ' <tr><td>';
echo ' <table width=3D"100%" cellpadding=3D"0" cellspacing=3D"0"=
align=3D"center" border=3D"0" bgcolor=3D"'.$color[4].'">';
echo ' <tr>' . html_tag( 'td', '', 'left', $color[9] );
echo ' <b>' . _("Attachments") . ':</b>';
echo ' </td></tr>';
echo ' <tr><td>';
echo ' <table width=3D"100%" cellpadding=3D"2" =
cellspacing=3D"2" align=3D"center"'.' border=3D"0" =
bgcolor=3D"'.$color[0].'"><tr><td>
';
echo $attachmentsdisplay;
echo ' </td></tr></table>';
echo ' </td></tr></table>';
echo ' </td></tr>';
echo '<TR><TD HEIGHT=3D"5" COLSPAN=3D"2" BGCOLOR=3D"'.
$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 =
(headers) being received by the victim so it is easily spoofable by an =
evil
attacker (for instance, my good friend "Crg" of "!dSR" team }:-)).
=20
In "functions/mime.php":
=20
- -----------------
function formatAttachments($message, $exclude_id, $mailbox, $id) {
[...]
$att_ar =3D $message->getAttachments($exclude_id);
if (!count($att_ar)) return '';
$attachments =3D '';
=20
$urlMailbox =3D urlencode($mailbox);
foreach ($att_ar as $att) {
$ent =3D $att->entity_id;
$header =3D $att->header;
$type0 =3D strtolower($header->type0);
$type1 =3D strtolower($header->type1);
[...]
$attachments .=3D '<TR><TD>' .
'<A =
HREF=3D"'.$defaultlink.'">'.decodeHeader($display_ filename).'</A> </=
TD>' .
'<TD><SMALL><b>' . =
show_readable_size($header->size) .
'</b> </small></TD>' .
"<TD><SMALL>[ $type0/$type1 ] </SMALL></TD>"=
Quote
