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 <[email protected]> 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 > [email protected] > > -----Original Message----- > From: [email protected] <[email protected]> On Behalf > Of Apache Security Team > Sent: Wednesday, September 30, 2020 3:06 AM > To: Ian Maxon <[email protected]> > Cc: Kelly Todd <[email protected]>; [email protected]; > [email protected]; [email protected]; CVE Request > <[email protected]> > 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 <[email protected]> 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 <[email protected]> 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 > > > [email protected] > > > > > > -----Original Message----- > > > From: Ian Maxon <[email protected]> > > > Sent: Friday, September 18, 2020 11:32 AM > > > To: Kelly Todd <[email protected]> > > > Cc: Apache Security Team <[email protected]>; > > > [email protected]; [email protected]; CVE Request > > > <[email protected]> > > > 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 <[email protected]> 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 > > > > [email protected] > > > > > > > > -----Original Message----- > > > > From: [email protected] <[email protected]> On > > > > Behalf Of Apache Security Team > > > > Sent: Monday, September 14, 2020 6:31 AM > > > > To: [email protected] > > > > Cc: [email protected]; CVE Request <[email protected]>; Kelly > > > > Todd <[email protected]> > > > > 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 <[email protected]> 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 > > > > > > > > > > [email protected] > > > > > > > > > >
