Re: speaking of hardware CVEs

• To: Kurt Seifried <kseifried@redhat.com>
• Subject: Re: speaking of hardware CVEs
• From: jericho <jericho@attrition.org>
• Date: Sun, 12 Mar 2017 22:59:38 -0500
• Authentication-results: spf=none (sender IP is 129.83.29.3) smtp.mailfrom=LISTS.MITRE.ORG; mitre.mail.onmicrosoft.com; dkim=none (message not signed) header.d=none;mitre.mail.onmicrosoft.com; dmarc=none action=none header.from=attrition.org;
• Cc: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
• Delivery-date: Mon Mar 13 08:04:08 2017
• Importance: high
• In-reply-to: <CANO=Ty09VEAZQwjRA-NZ=Mj1Dj4Z1XYWmg_1K+68Pqvzc87Phg@mail.gmail.com>
• List-help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
• List-owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
• List-subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
• List-unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
• References: <CANO=Ty09VEAZQwjRA-NZ=Mj1Dj4Z1XYWmg_1K+68Pqvzc87Phg@mail.gmail.com>
• Sender: <owner-cve-editorial-board-list@lists.mitre.org>
• Spamdiagnosticmetadata: 6cdb8bfc89744bd8bfee511e3e65aa05
• Spamdiagnosticoutput: 1:2
• User-agent: Alpine 2.00 (LNX 1167 2008-08-23)

On Fri, 10 Mar 2017, Kurt Seifried wrote:

: This timely article is out: 
: 
https://www.cylance.com/en_us/blog/uefi-ransomware-full-disclosure-at-black-hat-asia.html
 
: seems like some UEFI implementations are lacking basic security 
: checks/best practices, I would think failing to sue those things 
should 
: be CVE worthy in the modern world.

Devil's advocate:

CVE has largely said they will not create for default credentials, even 
when it means complete administrative access to the app/device/OS [1]. 
If 
that isn't CVE-worthy, then "missing other best practices" doesn't seem 
like it would qualify either.

.b

[1] I realize there are a few default-related IDs, sometimes because 
researchers reserve it (e.g. CVE-2017-3186), a CNA assigns for it (e.g. 
CVE-2016-9215), or when MITRE assigns for it rarely (e.g. 
CVE-2016-6667).

• References:
  • speaking of hardware CVEs
    • From: Kurt Seifried <kseifried@redhat.com>

• Prev by Date: speaking of hardware CVEs
• Next by Date: Re: speaking of hardware CVEs
• Previous by thread: speaking of hardware CVEs
• Next by thread: Re: speaking of hardware CVEs
• Index(es):
  • Date
  • Thread