[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Should CVE-2018-1000156 be Rejected?

Adding the board to the CC since this raises some highr level issues we probably need to think about and ideally make some decisions on.

On Fri, Apr 6, 2018 at 9:52 AM, Theall, George A <gtheall@mitre.org> wrote:

Hi Kurt,

 

[After I accepted your pull request for CVE-2018-1000156 this morning, another MITRE CVE Team member raised a concern about CVE-2018-1000156 and asks if it should be rejected.]

 

It unfortunately turns out that Debian had also sent us a request

yesterday about the issue of the '!' character in patch files, and at

the time they had suggested changing CVE-2015-1418 to be not specific

to FreeBSD. This request happened to be processed before your

CVE-2018-1000156 pull request. So, at the moment, we have two

populated CVEs that refer to the same problem in the same version of

GNU patch:

 

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1418

 

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000156

 

We completely agree that there are multiple versions of patch that have

diverged over time. We're not sure that the specific affected code has

diverged enough to need multiple CVEs. Our initial thought is that the

focus is on the do_ed_script function in the pch.c file, which seems

to have the same code structure even after the diverging of other

parts of the patch codebase.

 

Do you want to stay with two IDs at this point, or do you want to

reject CVE-2018-1000156 on behalf of the assigning CNA?


I think it really boils down to how we define common code base vs diverged code base. I like the idea of merging because on the one hand it lets us list all the BSDs, Linux, Mac OS (yeah, vulnerable to this too) in one CVE and be done with it, but in this specific case I was worried about confusion due to the timeline and the BSD vs. Linux side. (and also Mac OS is affected and I assume every variant of patch on a system with ed, so Solaris/etc. should be tested too) 

I also worry it sets a precedent for the "common code base or not" e.g. MySQL and all it's children, or other older utilities (like beep apparently) that have security flaws and will have very widely varying amounts of divergence that we may want to think about first. 
 
Perhaps we should look at amending the content decision to be less specific about code base specifically but also include things like common ancestry if it's a more conceptual problem (e.g. the code is correct, it does exactly what it was designed to do, it's just a truly terrible feature). So rather than "does a single common patch fix all these implementations? if yes count as common and MERGE" but "does a single easily defined solution (be it specific code patch, or specific conceptual change to the code) fix this all these implementations? if yes count as common and MERGE". Thish in this case it does, either remove ed support or use ed -r (FreeBSD did the -r by defining a "red" binary and then using it). 

This of course would support the idea of "protocol" level flaws, which I forget if we discussed much/came to a decision on whether we want them or not. 


We're a little concerned about the level of effort it takes to

maintain multiple CVEs for analogous command-injection issues in

different people's copies of the do_ed_script function in the pch.c

file. For example, if CVE-2015-1418 were only FreeBSD, and

CVE-2018-1000156 were only GNU patch 2.7.6, then we're shifting the

work to every other affected code maintainer. Realistically, they're

not all going to bother to make CVE ID requests, and their users won't

know which (if any) of the CVE IDs apply.


I'm ok with REJECT'ing CVE-2018-1000156 in favour of the freeBSD one but I worry in this case that it might also be very confusing to people, which is why I did the new CVE, but if you think MERGE is best we can do that.
 

 

 

George

--

gtheall@mitre.org

The MITRE Corporation

 




--
Kurt Seifried
kurt@seifried.org
Page Last Updated or Reviewed: April 09, 2018