You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@asterixdb.apache.org by Ian Maxon <im...@uci.edu> on 2020/09/29 17:56:34 UTC
Re: [EXT] Re: CVE Publication Service Request 941606
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
> > > > > >
> > > > > >
>
Re: [EXT] Re: CVE Publication Service Request 941606
Posted by Apache Security Team <se...@apache.org>.
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 Apache Security Team <se...@apache.org>.
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
> > > >
> > > >