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 > kt...@mitre.org > > -----Original Message----- > From: m...@gsuite.cloud.apache.org <m...@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 <ima...@uci.edu>; dev@asterixdb.apache.org; > ima...@apache.org; priv...@asterixdb.apache.org; CVE Request < > cve-requ...@mitre.org>; Jonathan L Evans <jev...@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 > > kt...@mitre.org > > > > -----Original Message----- > > From: m...@gsuite.cloud.apache.org <m...@gsuite.cloud.apache.org> On > > Behalf Of Apache Security Team > > Sent: Wednesday, September 30, 2020 3:06 AM > > To: Ian Maxon <ima...@uci.edu> > > Cc: Kelly Todd <kt...@mitre.org>; dev@asterixdb.apache.org; > > ima...@apache.org; priv...@asterixdb.apache.org; CVE Request > > <cve-requ...@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 <ima...@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 > > > > kt...@mitre.org > > > > > > > > -----Original Message----- > > > > From: Ian Maxon <ima...@apache.org> > > > > Sent: Friday, September 18, 2020 11:32 AM > > > > To: Kelly Todd <kt...@mitre.org> > > > > Cc: Apache Security Team <secur...@apache.org>; > > > > priv...@asterixdb.apache.org; ima...@apache.org; CVE Request > > > > <cve-requ...@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 > > > > > kt...@mitre.org > > > > > > > > > > -----Original Message----- > > > > > From: m...@gsuite.cloud.apache.org <m...@gsuite.cloud.apache.org> > > > > > On Behalf Of Apache Security Team > > > > > Sent: Monday, September 14, 2020 6:31 AM > > > > > To: priv...@asterixdb.apache.org > > > > > Cc: ima...@apache.org; CVE Request <cve-requ...@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 > > > > > > > > > > > > kt...@mitre.org > > > > > > > > > > > > >
