[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 8 Jul 2016 14:19:02 +0200
From: Jens Erat <jens.erat@...-konstanz.de>
To: cve-assign@...re.org
Cc: oss-security@...ts.openwall.com
Subject: Re: CVE request: several SOGo issues (DOS, XSS, information leakage)
Thank you for your reply.
Am 15.06.2016 um 04:40 schrieb cve-assign@...re.org:
> We have a few questions about this. First, several of the
> https://sogo.nu/bugs URLs provide an "Access Denied" response and we
> were wondering whether that was intentional. MITRE has no role in
> determining the list charter, but
> http://oss-security.openwall.org/wiki/mailing-lists/oss-security says
> "List Content Guidelines ... Any security issues that you post to
> oss-security should be either already public or to be made public by
> your posting."
>
> When required, CVE IDs can be assigned based on commits in conjunction
> with non-public bug reports; this potentially addresses all of the
> cases except for SOGo #3670, which is apparently not yet public at
> all.
I had inverse publishing the issues, apart from #3670 as the fix was released just recently.
> Also, your message didn't mention whether you are making the CVE
> request on behalf of the Inverse team, or whether you are noting
> issues that are security-related from your own perspective.
I'm not requesting on behalf of the Inverse team ("from by own perspective"). Inverse already confirmed the issues (and fixed most of them), but SOGo has a history of missing CVEs even for nasty issues.
> Going through the list of public issues:
>
> SOGo #3510 - is the ultimate case of the entire issue summarized by
> "copies the attachment (into memcached?) and then eliminates the copy
> in the sogod. The memcached copy stays forever/until the SOGo service
> is restarted"? Or is there a second implementation error? It seems
> that part of the issue, but not all of it, is a feature request (SOGo
> #3135) suggesting that SOGo should have size limits because
> configuring limits at the level of the web server and SMTP server
> disrupts the user experience.
The issues was resolved by limiting the upload size, which _also_ was a feature request (but now got important due to the possible DOS attack). Further investigation showed that not memcached was the issue but temporary files kept around, but the rest of the argument stayed the same.
> SOGo #3695 is listed twice but the second one has 3696 in the URL. We
> are guessing that the second "SOGo #3695" is just a "SOGo #3696" typo.
> More importantly, are there two distinct code problems? Or is it a
> single code problem that is reachable with different attack vectors?
These have been two different issues within related code, that have been resolved together:
1. Not all private information removed for the public free/busy view
2. It was possible to join appointments based on the UID of the public free/busy view from different users, to know who has appointments with whom
> SOGo #3718 has two identical
> "Issue: https://sogo.nu/bugs/view.php?id=3718" lines. Was one of them
> supposed to be a different URL?
I duplicated the line by accident.
> SOGo #2598 - we are able to assign CVE-2014 IDs. Does "SOGo #2598:
> Script injection in calendar title ... Reporter: Jens Erat" mean that
> your own discovery was only about the calendar title, and that
> additional attack vectors ("contacts module" and "CSS dialogs") were
> follow-on discoveries by the Inverse team?
The (now public) issue log says I realized the issue also exists with contacts, and the CSS stuff was not an additional attack vector, but a regression fix.
--
Jens Erat
Universität Konstanz
Kommunikations-, Infomations-, Medienzentrum (KIM)
Abteilung Basisdienste
D-78457 Konstanz
Mail: jens.erat@...-konstanz.de
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4913 bytes)
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.
