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

Re: [CVENEW] New CVE CANs: 2017/04/23 19:00 ; count=1

Greetings,

 

As part of our work related to item #1 in your message, we noticed that a low-priority issue in sudo, mentioned in the

<http://marc.info/?l=oss-security&m=142376206707936&w=2> post, had never been published on the cve.mitre.org site. This has been published within the past few days. During work on this CVE entry, we realized that a second ID (CVE-2014-9681) was also assigned and it has the same marc.info URL.

 

However, this was widely recognized within the user community as an issue that did not cross a privilege boundary, e.g.,

 

<https://bugzilla.novell.com/show_bug.cgi?id=919737>

<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772706>

<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778341>

 

There did not seem to be significant value in re-opening a 2015 oss-security thread since it did not seem anyone believes the CVE ID originally should have existed for that procmail behavior.

 

There was similar adverse information available a few days ago under

<https://security-tracker.debian.org/tracker/CVE-2014-9681> but that has since been removed when

<https://security-tracker.debian.org/tracker/CVE-2014-9681> was updated.

 

It has not been general practice to include reference URLs for CVE IDs in the "REJECT" state. Thus, although we can respond to questions about a CVE ID with REJECT status, we do not have a resource on the web to answer questions in advance. We can consider adding this as a new bit of data going forward, and we'll want to discuss that with the Board.

 

The original rationale for omitting references for non-vulnerability CVE IDs was to avoid highlighting false information, e.g., someone could make a false claim in a blog post, and that blog post would have a high rank in web search results because of a link from the cve.mitre.org site. We realize that we could work around that now, but mechanisms to work around that were not always available in the past.

 

(As some background, we had chosen to delay CVE-2014-9680 because we were unclear as to why CVE-2014-9680 was a valid CVE ID when CVE-2014-9681 was not. Because we now have a better understanding, we updated the entries such that CVE-2014-9680 is published but CVE-2014-9681 is rejected.

 

Regarding robots.txt, last February we had made a change to robots.txt. Currently, it is only disallowing the following:

User-agent: *

Disallow: /about/images/

Disallow: /compatible/includes/

Disallow: /compatible/images/

Disallow: /compatible/questionnaires/images/

Disallow: /compatible/questionnaires/certificates/

Disallow: /cve/images/

Disallow: /news/images/

Disallow: /images/

Disallow: /includes/

Disallow: /css/

 

(It appears that the change was not announced on the Board list after the suggestion was made. We apologize for not following up at the time.)

 

Are you aware of archive sites where they are still not able to archive our site? If so, we can reach out to them and determine what the problem is.

 

Please let us know if you have any other questions.

 

Thanks.

 

-Dan, for the CVE Team

 

From: <owner-cve-editorial-board-list@lists.mitre.org> on behalf of jericho <jericho@attrition.org>
Date: Monday, April 24, 2017 at 01:27
To: Common Vulnerabilities & Exposures <cve@mitre.org>
Cc: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: Re: [CVENEW] New CVE CANs: 2017/04/23 19:00 ; count=1

 

MITRE,

 

This doesn't work in the big picture of CVE.

 

On Sun, 23 Apr 2017, cve@mitre.org wrote:

 

: ======================================================

: Name: CVE-2014-9681

: Status: Candidate

: Final-Decision:

: Interim-Decision:

: Modified:

: Proposed:

: Assigned: 20150212

: Category:

:

: ** REJECT **

:

: DO NOT USE THIS CANDIDATE NUMBER.  ConsultIDs: none.  Reason: This

: candidate was withdrawn by its CNA.  Further investigation showed that

: it was not a security issue.  Notes: none.

 

On 2015-02-12, MITRE made this assignment:

 

 

   : Procmail is another program that recklessly whitelists TZ

 

     Use CVE-2014-9681 for the similar issue in procmail.

 

Now, jump to today, and the entry went from presumably RESERVED to

REJECTED. Looking at NVD we see a better date history than MITRE offers:

 

 

Original release date:

04/23/2017

Last revised:

04/23/2017

 

Since MITRE has long blocked archival sites via robots.txt, which has been

brought up before on list, we can't show evidence that this was RESERVED

yesterday and REJECTED today, but it is pretty clear.

 

So... this leaves two obvious questions:

 

1. This was a 2014 assignment, on oss-sec, on a public disclosure. Yet,

the ID was RESERVED all this time. Why?

 

2. Tonight, the ID was suddenly REJECTED as "not a security issue", with

no additional information from MITRE, no reply to the old thread, and no

provenance for the "not an issue" decision. Why?

 

I fully understand #1 due to past MITRE issues. But today, the sudden

change without information does not make sense, and does not seem

appropriate.

 

I'd like to get more information on this, not just about CVE-2014-9681,

but the general process that led to this decision.

 

Thank you,

 

Brian

 

Page Last Updated or Reviewed: April 25, 2017