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 > > > > > > > >
