speaking of hardware CVEs

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

speaking of hardware CVEs

kseifried@redhat.com
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.

--

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: speaking of hardware CVEs

jericho
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).
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: speaking of hardware CVEs

Art Manion
In reply to this post by kseifried@redhat.com
On 3/10/17 10:06 PM, 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.

I didn't read the Cylance page carefully, but there have been issues
with BIOS/UEFI vulnerabilities that I'll argue are *software* and
CVE-worthy.  BIOS is software.

On 3/12/17 11:59 PM, jericho wrote:

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

Getting into the "lacking basic security" discussion, I'll argue that
"insecure default configuration" should warrant a CVE in some cases
(open ACLs on squid a long time ago, maybe mongoDB and memcached today,
and yes, default/shared/hard-coded credentials when the vendor knows
quite well in advance that the thing will be on the internet).

Vulnerabilities are also about surprise/expectations and interaction
with (changing) environment; vulnerabilities aren't purely technical.  I
know, unsatisfying in an engineering sense, and changing the definition
of "vulnerability that gets a CVE ID" makes the corpus messy.

Classification is messy, the world (and thinking about the world)
changes, Pluto is a planet, Apatosaurus is not Brontosaurus.

 - Art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: speaking of hardware CVEs

Coffin, Chris
> 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.

As far as we can tell, the vulnerabilities being reported are in the firmware and this would be covered by CVE.
 
An example of a hardware vulnerability would be if the SMM and SPI flash memory write protection were bypassed.  The advisory implies that they can bypass Intel's SGX, which might be a hardware vulnerability.  We are not familiar enough with SGX to be certain.  One option might be to query the Intel CNA for help in this area.

> CVE has largely said they will not create for default credentials,
> even when it means complete administrative access to the app/device/OS

MITRE does consider default credentials as CVE-worthy vulnerabilities.  In fact, it is listed as an example of what a vulnerability is on the Terminology page of our website (https://cve.mitre.org/about/terminology.html).  

The CVE Team

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Art Manion
Sent: Monday, March 13, 2017 12:36 PM
To: Kurt Seifried <[hidden email]>; cve-editorial-board-list <[hidden email]>
Subject: Re: speaking of hardware CVEs

On 3/10/17 10:06 PM, 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.

I didn't read the Cylance page carefully, but there have been issues with BIOS/UEFI vulnerabilities that I'll argue are *software* and CVE-worthy.  BIOS is software.

On 3/12/17 11:59 PM, jericho wrote:

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

Getting into the "lacking basic security" discussion, I'll argue that "insecure default configuration" should warrant a CVE in some cases (open ACLs on squid a long time ago, maybe mongoDB and memcached today, and yes, default/shared/hard-coded credentials when the vendor knows quite well in advance that the thing will be on the internet).

Vulnerabilities are also about surprise/expectations and interaction with (changing) environment; vulnerabilities aren't purely technical.  I know, unsatisfying in an engineering sense, and changing the definition of "vulnerability that gets a CVE ID" makes the corpus messy.

Classification is messy, the world (and thinking about the world) changes, Pluto is a planet, Apatosaurus is not Brontosaurus.

 - Art
Loading...