You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@asterixdb.apache.org by Apache Security Team <se...@apache.org> on 2020/11/09 12:51:35 UTC
Re: [EXT] Re: CVE Publication Service Request 941606
Hi Mitre folks; just a re-ping on this one. Would you like us to
reject the CVE or come up with alternative wording?
Regards, Mark
On Wed, Sep 30, 2020 at 2:23 PM Kelly Todd <kt...@mitre.org> wrote:
>
> Hello, all:
>
> From our research, the only public mentions regarding the CVE ID (excluding mirrors) is found here:
>
> https://www.openwall.com/lists/oss-security/2020/08/08/2
>
> https://archives-cert.univ-amu.fr/courant/certmsgVULN441
>
> We have a few options to consider, such as pushing the request through and then rejecting, but the prose description as submitted would need to follow the CNA rules before doing so.
>
> https://cve.mitre.org/cve/cna/rules.html#section_8-2_cve_entry_prose_description_requirements
>
> Let's please discuss to come up with a suitable solution.
>
> Thanks,
>
> Kelly Todd
> Senior Cybersecurity Engineer
> CVE Content Team
> ktodd@mitre.org
>
> -----Original Message-----
> From: mjc@gsuite.cloud.apache.org <mj...@gsuite.cloud.apache.org> On Behalf Of Apache Security Team
> Sent: Wednesday, September 30, 2020 3:06 AM
> To: Ian Maxon <im...@uci.edu>
> Cc: Kelly Todd <kt...@mitre.org>; dev@asterixdb.apache.org; imaxon@apache.org; private@asterixdb.apache.org; CVE Request <CV...@mitre.org>
> Subject: Re: [EXT] Re: CVE Publication Service Request 941606
>
> Hi AsterixDB team;
>
> Mitre is correct here, at the ASF we do not allocate CVE names when the issue only applied to a development version. i.e. you need to have had made an official ASF release that was affected. There are a few exceptions, but mostly only when the vulnerability was introduced into some downstream (i.e. if a vendor packages your development version into something which is their release, then we have to figure out between the vendor and us where the CVE name lies).
>
> Usually we (security@apache) can tell this from the report or discussion so we can help guide the project. I notice that our guidance doesn't mention this case and I'll come up with some additional text to cover it. https://s.apache.org/cveprocess
>
> For this specific case, Mitre folks, since this issue is now published and public do you wish to reject it or live with it?
>
> Thanks, Mark
> ASF Security
>
> On Tue, Sep 29, 2020 at 6:56 PM Ian Maxon <im...@uci.edu> wrote:
> >
> > Hi Kelly,
> > It wasn't in an official release, no. However our git repository is
> > public, this was on master, and people run builds from master
> > frequently. So in that sense the code was released to the public for a
> > period of time, between when the vulnerable commit was added and until
> > it was reported and fixed. I also wanted to give credit where credit
> > was due for the reporter, instead of just taking the report and
> > silently fixing it.
> >
> > I am not really certain at all how to interpret the rule myself. This
> > is the first vulnerability report we've gotten and the first one I've
> > handled. Is there some similar situation in the past that might serve
> > as precedent?
> >
> >
> > - Ian
> >
> >
> > On Tue, Sep 29, 2020 at 6:52 AM Kelly Todd <kt...@mitre.org> wrote:
> > >
> > > Hi Ian,
> > >
> > > To confirm, is this for an unreleased build? If so, 7.4.7 of the CAN rules would apply:
> > >
> > > https://cve.mitre.org/cve/cna/rules.html
> > >
> > > Please advise?
> > >
> > > Kelly Todd
> > > Senior Cybersecurity Engineer
> > > CVE Content Team
> > > ktodd@mitre.org
> > >
> > > -----Original Message-----
> > > From: Ian Maxon <im...@apache.org>
> > > Sent: Friday, September 18, 2020 11:32 AM
> > > To: Kelly Todd <kt...@mitre.org>
> > > Cc: Apache Security Team <se...@apache.org>;
> > > private@asterixdb.apache.org; imaxon@apache.org; CVE Request
> > > <CV...@mitre.org>
> > > Subject: Re: [EXT] Re: CVE Publication Service Request 941606
> > >
> > > Hi Kelly,
> > > Sorry for the late response. I'm not sure what was wrong with the entry. I guess I must have forgot to put the product version info in the description? I don't have what I entered to review though.
> > > Would this info be correct?:
> > > --------------------------
> > > CVE-2020-9479: AsterixDB directory traversal
> > > Severity: Important
> > >
> > > Vendor: The Apache Software Foundation
> > >
> > > Versions Affected: None released, git commits
> > > 580b81aa5e8888b8e1b0620521a1c9680e54df73 to
> > > 28c0ee84f1387ab5d0659e9e822f4e3923ddc22d , fixed in
> > > 28c0ee84f1387ab5d0659e9e822f4e3923ddc22d and mitigated by
> > > 694ffd194ce5c6e610f61368c1511778d0bff254
> > >
> > > Description: When loading a UDF in unreleased bulds of asterixdb from commits 580b81aa5e8888b8e1b0620521a1c9680e54df73 to 28c0ee84f1387ab5d0659e9e822f4e3923ddc22d , a specially crafted zip file could allow files to be placed outside of the UDF deployment directory.
> > >
> > > Mitigation: Upgrade unreleased versions past 28c0ee84f1387ab5d0659e9e822f4e3923ddc22d or to 0.9.5 .
> > > Don't allow untrusted access to the UDF endpoint.
> > >
> > > Example: The zip file will contain a directory entry named ".."
> > >
> > > Credit: This issue was discovered by Yiming Xiang of NSFOCUS
> > > --------
> > >
> > > Thanks,
> > > - Ian
> > >
> > > On Fri, Sep 18, 2020 at 7:37 AM Kelly Todd <kt...@mitre.org> wrote:
> > > >
> > > > Hello,
> > > >
> > > > Has there been any response to Mark's request? I do not see anything yet, but we did resolve another issue for a different product fairly easily. Please advise.
> > > >
> > > > Thanks,
> > > >
> > > > Kelly Todd
> > > > Senior Cybersecurity Engineer
> > > > CVE Content Team
> > > > ktodd@mitre.org
> > > >
> > > > -----Original Message-----
> > > > From: mjc@gsuite.cloud.apache.org <mj...@gsuite.cloud.apache.org> On
> > > > Behalf Of Apache Security Team
> > > > Sent: Monday, September 14, 2020 6:31 AM
> > > > To: private@asterixdb.apache.org
> > > > Cc: imaxon@apache.org; CVE Request <CV...@mitre.org>; Kelly
> > > > Todd <kt...@mitre.org>
> > > > Subject: [EXT] Re: CVE Publication Service Request 941606
> > > >
> > > > Hey AsterixDB folks; I note this request is still outstanding.
> > > > Did you resolve this issue with Mitre? Need any help see
> > > > https://s.apache.org/cveprocess
> > > >
> > > > Cheers, Mark
> > > >
> > > > On Mon, Aug 10, 2020 at 6:26 PM Kelly Todd <kt...@mitre.org> wrote:
> > > > >
> > > > > Per the CNA rules (http://cve.mitre.org/cve/cna/rules.html), CVE entry descriptions must contain the minimum data requirements (https://cve.mitre.org/cve/cna/rules.html#section_8-2_cve_entry_prose_description_requirements). To process request 941606 and populate the entry(s) for CVE-2020-9479 to the CVE list, please include the data requirements identified below.
> > > > >
> > > > >
> > > > >
> > > > > - Affected product information (the product information needs to
> > > > > be in the description even though it is also in the product
> > > > > field)
> > > > >
> > > > >
> > > > >
> > > > > Online resources;
> > > > >
> > > > > - Minimum data requirements and approved formats are documented in the CNA Rules, https://cve.mitre.org/cve/cna/rules.html#section_8_cve_entry_requirements.
> > > > >
> > > > > - Submitting CVE entry(s),
> > > > > https://cve.mitre.org/cve/cna.html#submitting_cve_entry_info
> > > > >
> > > > >
> > > > >
> > > > > If you have any questions, please do not hesitate to contact us.
> > > > >
> > > > >
> > > > >
> > > > > Kelly Todd
> > > > >
> > > > > Senior Cybersecurity Engineer
> > > > >
> > > > > CVE Content Team
> > > > >
> > > > > ktodd@mitre.org
> > > > >
> > > > >
Re: [EXT] Re: CVE Publication Service Request 941606
Posted by Mark J Cox <mj...@apache.org>.
I've created a PR https://github.com/CVEProject/cvelist/pull/936
Feel free to reject after merge
Regards, Mark J Cox
ASF Security
On Mon, Nov 9, 2020 at 2:21 PM Kelly Todd <kt...@mitre.org> wrote:
> Either option would be up to Apache as a CNA. Please let us know your
> decision and we will process the item accordingly.
>
> Kelly Todd
> Senior Cybersecurity Engineer
> CVE Content Team
> ktodd@mitre.org
>
> -----Original Message-----
> From: mjc@gsuite.cloud.apache.org <mj...@gsuite.cloud.apache.org> On Behalf
> Of Apache Security Team
> Sent: Monday, November 9, 2020 6:52 AM
> To: Kelly Todd <kt...@mitre.org>
> Cc: Ian Maxon <im...@uci.edu>; dev@asterixdb.apache.org;
> imaxon@apache.org; private@asterixdb.apache.org; CVE Request <
> CVE-Request@mitre.org>; Jonathan L Evans <je...@mitre.org>
> Subject: Re: [EXT] Re: CVE Publication Service Request 941606
>
> Hi Mitre folks; just a re-ping on this one. Would you like us to reject
> the CVE or come up with alternative wording?
>
> Regards, Mark
>
> On Wed, Sep 30, 2020 at 2:23 PM Kelly Todd <kt...@mitre.org> wrote:
> >
> > Hello, all:
> >
> > From our research, the only public mentions regarding the CVE ID
> (excluding mirrors) is found here:
> >
> > https://www.openwall.com/lists/oss-security/2020/08/08/2
> >
> > https://archives-cert.univ-amu.fr/courant/certmsgVULN441
> >
> > We have a few options to consider, such as pushing the request through
> and then rejecting, but the prose description as submitted would need to
> follow the CNA rules before doing so.
> >
> > https://cve.mitre.org/cve/cna/rules.html#section_8-2_cve_entry_prose_d
> > escription_requirements
> >
> > Let's please discuss to come up with a suitable solution.
> >
> > Thanks,
> >
> > Kelly Todd
> > Senior Cybersecurity Engineer
> > CVE Content Team
> > ktodd@mitre.org
> >
> > -----Original Message-----
> > From: mjc@gsuite.cloud.apache.org <mj...@gsuite.cloud.apache.org> On
> > Behalf Of Apache Security Team
> > Sent: Wednesday, September 30, 2020 3:06 AM
> > To: Ian Maxon <im...@uci.edu>
> > Cc: Kelly Todd <kt...@mitre.org>; dev@asterixdb.apache.org;
> > imaxon@apache.org; private@asterixdb.apache.org; CVE Request
> > <CV...@mitre.org>
> > Subject: Re: [EXT] Re: CVE Publication Service Request 941606
> >
> > Hi AsterixDB team;
> >
> > Mitre is correct here, at the ASF we do not allocate CVE names when the
> issue only applied to a development version. i.e. you need to have had
> made an official ASF release that was affected. There are a few
> exceptions, but mostly only when the vulnerability was introduced into some
> downstream (i.e. if a vendor packages your development version into
> something which is their release, then we have to figure out between the
> vendor and us where the CVE name lies).
> >
> > Usually we (security@apache) can tell this from the report or
> > discussion so we can help guide the project. I notice that our
> > guidance doesn't mention this case and I'll come up with some
> > additional text to cover it. https://s.apache.org/cveprocess
> >
> > For this specific case, Mitre folks, since this issue is now published
> and public do you wish to reject it or live with it?
> >
> > Thanks, Mark
> > ASF Security
> >
> > On Tue, Sep 29, 2020 at 6:56 PM Ian Maxon <im...@uci.edu> wrote:
> > >
> > > Hi Kelly,
> > > It wasn't in an official release, no. However our git repository is
> > > public, this was on master, and people run builds from master
> > > frequently. So in that sense the code was released to the public for
> > > a period of time, between when the vulnerable commit was added and
> > > until it was reported and fixed. I also wanted to give credit where
> > > credit was due for the reporter, instead of just taking the report
> > > and silently fixing it.
> > >
> > > I am not really certain at all how to interpret the rule myself.
> > > This is the first vulnerability report we've gotten and the first
> > > one I've handled. Is there some similar situation in the past that
> > > might serve as precedent?
> > >
> > >
> > > - Ian
> > >
> > >
> > > On Tue, Sep 29, 2020 at 6:52 AM Kelly Todd <kt...@mitre.org> wrote:
> > > >
> > > > Hi Ian,
> > > >
> > > > To confirm, is this for an unreleased build? If so, 7.4.7 of the
> CAN rules would apply:
> > > >
> > > > https://cve.mitre.org/cve/cna/rules.html
> > > >
> > > > Please advise?
> > > >
> > > > Kelly Todd
> > > > Senior Cybersecurity Engineer
> > > > CVE Content Team
> > > > ktodd@mitre.org
> > > >
> > > > -----Original Message-----
> > > > From: Ian Maxon <im...@apache.org>
> > > > Sent: Friday, September 18, 2020 11:32 AM
> > > > To: Kelly Todd <kt...@mitre.org>
> > > > Cc: Apache Security Team <se...@apache.org>;
> > > > private@asterixdb.apache.org; imaxon@apache.org; CVE Request
> > > > <CV...@mitre.org>
> > > > Subject: Re: [EXT] Re: CVE Publication Service Request 941606
> > > >
> > > > Hi Kelly,
> > > > Sorry for the late response. I'm not sure what was wrong with the
> entry. I guess I must have forgot to put the product version info in the
> description? I don't have what I entered to review though.
> > > > Would this info be correct?:
> > > > --------------------------
> > > > CVE-2020-9479: AsterixDB directory traversal
> > > > Severity: Important
> > > >
> > > > Vendor: The Apache Software Foundation
> > > >
> > > > Versions Affected: None released, git commits
> > > > 580b81aa5e8888b8e1b0620521a1c9680e54df73 to
> > > > 28c0ee84f1387ab5d0659e9e822f4e3923ddc22d , fixed in
> > > > 28c0ee84f1387ab5d0659e9e822f4e3923ddc22d and mitigated by
> > > > 694ffd194ce5c6e610f61368c1511778d0bff254
> > > >
> > > > Description: When loading a UDF in unreleased bulds of asterixdb
> from commits 580b81aa5e8888b8e1b0620521a1c9680e54df73 to
> 28c0ee84f1387ab5d0659e9e822f4e3923ddc22d , a specially crafted zip file
> could allow files to be placed outside of the UDF deployment directory.
> > > >
> > > > Mitigation: Upgrade unreleased versions past
> 28c0ee84f1387ab5d0659e9e822f4e3923ddc22d or to 0.9.5 .
> > > > Don't allow untrusted access to the UDF endpoint.
> > > >
> > > > Example: The zip file will contain a directory entry named ".."
> > > >
> > > > Credit: This issue was discovered by Yiming Xiang of NSFOCUS
> > > > --------
> > > >
> > > > Thanks,
> > > > - Ian
> > > >
> > > > On Fri, Sep 18, 2020 at 7:37 AM Kelly Todd <kt...@mitre.org> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > Has there been any response to Mark's request? I do not see
> anything yet, but we did resolve another issue for a different product
> fairly easily. Please advise.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Kelly Todd
> > > > > Senior Cybersecurity Engineer
> > > > > CVE Content Team
> > > > > ktodd@mitre.org
> > > > >
> > > > > -----Original Message-----
> > > > > From: mjc@gsuite.cloud.apache.org <mj...@gsuite.cloud.apache.org>
> > > > > On Behalf Of Apache Security Team
> > > > > Sent: Monday, September 14, 2020 6:31 AM
> > > > > To: private@asterixdb.apache.org
> > > > > Cc: imaxon@apache.org; CVE Request <CV...@mitre.org>;
> > > > > Kelly Todd <kt...@mitre.org>
> > > > > Subject: [EXT] Re: CVE Publication Service Request 941606
> > > > >
> > > > > Hey AsterixDB folks; I note this request is still outstanding.
> > > > > Did you resolve this issue with Mitre? Need any help see
> > > > > https://s.apache.org/cveprocess
> > > > >
> > > > > Cheers, Mark
> > > > >
> > > > > On Mon, Aug 10, 2020 at 6:26 PM Kelly Todd <kt...@mitre.org>
> wrote:
> > > > > >
> > > > > > Per the CNA rules (http://cve.mitre.org/cve/cna/rules.html),
> CVE entry descriptions must contain the minimum data requirements (
> https://cve.mitre.org/cve/cna/rules.html#section_8-2_cve_entry_prose_description_requirements).
> To process request 941606 and populate the entry(s) for CVE-2020-9479 to
> the CVE list, please include the data requirements identified below.
> > > > > >
> > > > > >
> > > > > >
> > > > > > - Affected product information (the product information needs
> > > > > > to be in the description even though it is also in the product
> > > > > > field)
> > > > > >
> > > > > >
> > > > > >
> > > > > > Online resources;
> > > > > >
> > > > > > - Minimum data requirements and approved formats are documented
> in the CNA Rules,
> https://cve.mitre.org/cve/cna/rules.html#section_8_cve_entry_requirements.
> > > > > >
> > > > > > - Submitting CVE entry(s),
> > > > > > https://cve.mitre.org/cve/cna.html#submitting_cve_entry_info
> > > > > >
> > > > > >
> > > > > >
> > > > > > If you have any questions, please do not hesitate to contact us.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Kelly Todd
> > > > > >
> > > > > > Senior Cybersecurity Engineer
> > > > > >
> > > > > > CVE Content Team
> > > > > >
> > > > > > ktodd@mitre.org
> > > > > >
> > > > > >
>