[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1365157287.11234.38.camel@liliana.cdg.redhat.com>
Date: Fri, 05 Apr 2013 12:21:27 +0200
From: Michael Scherer <misc@...b.org>
To: oss-security@...ts.openwall.com
Subject: Zimbra XSS in aspell.php, CVE request
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 ?
--
Michael Scherer
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.
