[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 05 Apr 2013 18:05:13 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
CC: Michael Scherer <misc@...b.org>
Subject: Re: Zimbra XSS in aspell.php, CVE request
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/05/2013 04:21 AM, Michael Scherer wrote:
> Hi,
>
> While trying to see how hard a bug would be to fix in Zimbra
> during a discussion with a coworker, I stumbled across a XSS flaw
> in Zimbra, in a spell checking external webservice.
>
> Since I didn't found the public web interface for the source code
> of Zimbra and since perforce is not as straightforward to run on
> linux than git and slow to download the 2G of source code, I
> recommend to people to look at the github mirror, even if this mean
> losing some information and changelog.
>
> The issue is on this file :
> https://github.com/Zimbra-Community/zimbra-sources/blob/master/main/ZimbraServer/src/php/aspell.php
>
>
> The problem is that $dictionary is coming from user input ( from
> GET parameters ), since it is a copy of $_REQUEST. Then if no text
> is given ( and so $text is empty ), it is printed back in the html
> form displayed without any kind of sanitization at all ( line133 :
> https://github.com/Zimbra-Community/zimbra-sources/blob/master/main/ZimbraServer/src/php/aspell.php#L133
> )
>
> So a attacker could inject javascript/html there just by giving
> crafted link to a user, running as the domain of zimbra ( albeit on
> a different port ). Something like
> http://example.org/aspell.php?disctionnary=><script>
> alert('foo');</script>
>
> ( with proper url encoding of course ).
>
> Due to typecasting, "" is considered as equal to NULL for '==',
> while it may not be the case in other circumstances.
>
> If I am not wrong, the default location for the spell checking
> service is http://$config{HOSTNAME}:7780/aspell.php, so a
> improperly secured server ( ie, without a firewall ) could be
> vulnerable to javascript injection, which could be used to steal
> various informations ( like the session cookie ).
>
> However, depending on the browser and the security setting, the
> issue could be mitigated, even if it seems we can still steal the
> cookie with a spear phising attempt (
> http://seckb.yehg.net/2012/06/xss-gaining-access-to-httponly-cookie.html
> )
>
> The issue can be tested quite easily, just take any php hosting,
> download the aspell.php file there and run :
>
> $ curl
> 'http://www.example.org/aspell.php?dictionary=insert_html_here_with<blink>'
>
> You should see that the html code is inserted back in the form. I
> didn't spent time on writing a trivial exploit for that.
>
> Upstream have been notified on 2013-01-12 on a private bug (
> https://bugzilla.zimbra.com/show_bug.cgi?id=79640 ), with first
> answer on 2013-02-22, along with a fix following on the next hours.
> However, the fix is incorrect, and my attempt to make the coder
> change his mind failed.
>
> The fix that was written can be found on a aggregate commit on
> https://github.com/Zimbra-Community/zimbra-sources/commit/e7682c00be82a0c3ab51ee92f518bdcc1e07536c#L3L148
>
> While that could fix a XSS issue if the code was correctly used,
> there was no security issue since the call of the function is wrong
> on line 67, we see 1 parameter is missing and the value of
> $dictionnary is overwrote by the return code and is always 0, so we
> cannot inject anything with it.
>
> As I couldn't convince upstream to correct this, and given that I
> have let enough time to react to them after following the
> procedure, I consider that full disclosure is the next step to have
> it corrected.
>
> Can someone assign a CVE for it ?
>
Is this also in the open source version?
http://wiki.zimbra.com/wiki/Building_Zimbra_using_Perforce
- --
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iQIcBAEBAgAGBQJRX2a5AAoJEBYNRVNeJnmTq9AP/0RNlD+BHdaPoe2vU6sTMLWo
9EYu5PWg0OQQ6n75fCI+YASIQOWvaYT0zfQHoRT+HiyPM0/uS99DHIMYZAWtWfgP
008skYVOLD7gU0oh1/InxyKbUdCqTyg0cCeGgbDTXHHXPUw5pf01gQF141Xk6Ip7
2kDkDNuYpROG/ROOEZMGX79JRrymEKzhGM6MIXwldMrHdgReJyNTrebmlbo7F2fX
He0TNNntikFhhRecnjEYBFG43FrKkYK7KuaQAMgK4IgfLKBACHUPNeaE+O+gUgvE
0ei7PHVpcRqj5Ttl2a5808C8OtyG8fPSNj6dvF8A61S56GGa5kZoxku/BIl+wnUV
uuU4e2U+onGsXUkJ6ZBM4bxgwYtTDhpzWBu4X8RyXhykZ/693dVuVkH/f5lD8cXi
3dd7aEvmsbatxupZHgaN4raeRCnaxToZ6D9jmqldUddOziDWn9KZbIdLBAyGOkXh
lHByQfmWJym8OxqgXQFwTeyyc0T0zXqlNSZv+BKUIuR6ba+dqPLj7z0/4n4L023Q
B+Ethv5aUMvuVSDr44cJyRzUNRNsbF1yGKRJCQcWW8qcVWwr8BbpYinYlxTWQWvE
/FJSYYCPo9o7ifHx/EG9xSslyPCGqeZ69UHPQQcEITIHMz3d6BJaazZIxsoJHaHe
7bDA9DWIk/j/56qkvC06
=8/EA
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
