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

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
Page Last Updated or Reviewed: March 14, 2017