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

Re: Should be a CVE?

I had an offline conversation with Intel, posting the following on 
their behalf.


There seem to have been some conversations regarding this CVE that look to be tied to my 
lack of mentioning “anti-rollback” bypass.  I’ve updated the 
description to better add this, thoughts?

[CVEID]: CVE-2017-5698
[PRODUCT]:Intel® Active Management Technology, Intel® Standard 
Manageability, and Intel® Small Business Technology
[VERSION]:version 11.0.25.3001 and 11.0.26.3000
[PROBLEMTYPE]:Escalation of Privilege
[REFERENCES]:https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00082&languageid=en-fr
[DESCRIPTION]: Intel® Active Management Technology, Intel® Standard 
Manageability, and Intel® Small Business Technology firmware versions 
11.0.25.3001 and 11.0.26.3000 anti-rollback will not prevent upgrading to firmware 
version 11.6.x.1xxx which is vulnerable to CVE-2017-5689 and can be performed by a 
local user with administrative privileges.

BTW – I used “escalation of privilege” due to the second CVE, can’t 
figure out what to call it otherwise.


My (Art's) take is that the anti-rollback feature has the vulnerability 
-- it fails at it's stated security purpose.

I don't know what the constraints on [PROBLEMTYPE] are at the moment, 
any valid CWE?

Maybe CWE-837: Improper Enforcement of a Single, Unique Action?

http://cwe.mitre.org/data/definitions/837.html

Or leave blank if no good match?

 - Art







On 9/13/17 9:15 AM, Coffin, Chris wrote:

  * My ability to install/upgrade/downgrade to any software versions 
does not get a CVE ID, even if what I'm moving to has known CVD IDs.

Completely agree with Art on this. Based on the current information, the 
“install/upgrade/downgrade to any software” issue is not a 
vulnerability on its own and should not have a CVE ID assigned.

  * Intel/MITRE should reject the new CVE and update the original. Is 
this correct?

Yes. I believe that this is the most appropriate way to handle the 
situation. We will be reaching out to our Intel CNA contact for 
additional information, unless Kent chimes in sooner. J

Chris C

*From:*owner-cve-editorial-board-list@lists.mitre.org 
[mailto:owner-cve-editorial-board-list@lists.mitre.org] *On Behalf Of 
*Waltermire, David A. (Fed)
*Sent:* Tuesday, September 12, 2017 5:32 PM
*To:* Millar, Thomas <Thomas.Millar@hq.dhs.gov>; Kurt Seifried 
<kurt@seifried.org>; Art Manion <amanion@cert.org>
*Cc:* cve-editorial-board-list 
<cve-editorial-board-list@lists.mitre.org>
*Subject:* RE: Should be a CVE?

This makes sense. So if this is the case, Intel/MITRE should reject the 
new CVE and update the original. Is this correct?

Dave

-------- Original Message --------
From: "Millar, Thomas" <Thomas.Millar@hq.dhs.gov 
<mailto:Thomas.Millar@hq.dhs.gov>>
Date: Tue, September 12, 2017 5:49 PM -0400
To: Kurt Seifried <kurt@seifried.org <mailto:kurt@seifried.org>>, Art Manion 
<amanion@cert.org <mailto:amanion@cert.org>>
CC: "Waltermire, David A. (Fed)" <david.waltermire@nist.gov 
<mailto:david.waltermire@nist.gov>>, cve-editorial-board-list@lists.mitre.org 
<mailto:cve-editorial-board-list@lists.mitre.org>
Subject: RE: Should be a CVE?

It should probably be an update to the previous SA & CVE by Intel. The 
two particular 3XXX firmware versions are not safe, despite what the 
original advisory stated.



Tom Millar, US-CERT

Sent from +1-202-631-1915
https://www.us-cert.gov **

**

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

*From:*owner-cve-editorial-board-list@lists.mitre.org 
<mailto:owner-cve-editorial-board-list@lists.mitre.org> on behalf of 
Kurt Seifried
*Sent:* Tuesday, September 12, 2017 10:44:52 PM
*To:* Art Manion
*Cc:* Waltermire, David A. (Fed); cve-editorial-board-list@lists.mitre.org 
<mailto:cve-editorial-board-list@lists.mitre.org>
*Subject:* Re: Should be a CVE?

I'm not clear, the CVE ID, was it assigned because people are NOT 
supposed to be able to upgrade or something?

By this logic every vendor would need a CVE ID for every software 
package that can be updated to a version that has a flaw introduced in 
a later version (so like uhh.. all of them basically).

On Tue, Sep 12, 2017 at 2:01 PM, Art Manion <amanion@cert.org 
<mailto:amanion@cert.org>> wrote:

    On 2017-09-12 15:19, Waltermire, David A. (Fed) wrote:
     > Looking at the following, it appears that a CVE was issued for 
the potential that someone might upgrade software to a vulnerable version, 
which has another CVE. I don't think this should qualify as a CVE, given 
the actual vulnerability already has one.
     >
     > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5698
     >
     > Should this CVE be rejected?

    I think it should be rejected.

    Version A1 has vulnerability V1, version B1 has vulnerability V2, 
V1 and V2 are documented (have CVE IDs), the ability to change from V1 
to V2 does not warrant a CVE ID.

    My ability to install/upgrade/downgrade to any software versions 
does not get a CVE ID, even if what I'm moving to has known CVD IDs.

    Intel is welcome to release an advisory, upgrading and being 
newly/differently vulnerable is unexpected, which goes to the core of many 
vulnerability/security issues.  But no CVE ID.

      - Art



--

Kurt Seifried
kurt@seifried.org <mailto:kurt@seifried.org>
Page Last Updated or Reviewed: September 26, 2017