Re: Zimbra XSS in aspell.php, CVE request

[Michael Scherer <misc () zarb org>]

Le vendredi 05 avril 2013 à 18:05 -0600, Kurt Seifried a écrit :
> 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

I only used the open source version ( since I doubt the other version is
cloned on github, that would kinda be a license violation ) and I do not
have access to the closed source one ( or rather, i didn't tried very
hard to have access to it to check, as I would not be able to link to
source code for verification )

However, I suspect that's the same for non open source one ( ie, I see
no reason to have less features in the commercial version )

-- 
Michael Scherer