I'm generally in favor of broadening the scope of "things that get CVE IDs." But I think in this case I'd argue against.
All examples of serious bugs with serious impacts, including safety critical impacts. Knowledge needs to be conveyed and tracked, organizations made aware, actions taken in response. But not IMO "security" bugs, nor CVE-worthy. Adversary doesn't have any influence over the bug being triggered, it's just a function of time. Closer to metal fatigue and MTBF (in these cases you have an unusually precise MTBF).
The thought I have is you have a weakness, which can be parlayed into a vulnerability (and the attacker nay not need to actively exploit it to benefit from it), speaking to your metal fatigue example then where would something like the Kobe Steel fraud ( https://www.reuters.com/article/us-kobe-steel-scandal-ceo-idUSKBN1GH2SM ) fit in, effectively we have a manufacturer that made a promise/guarantee ("this is alloy X") when it may or may not have been. In CVE land we have the precedent that a promise of a capability that is wrong or missing, like having a firewall enabled can be CVE worthy.
- Art
On 2020-09-23 14:28, TK blast wrote:
> Kurt, my read on your logic below is that we should reconsider or expand on "attacker triggered" - it is much more about a general potential and likelihood. I too agree that if the likelihood is based on wall clock or some finite exhaustion of resource it is not chance but an inevitability occurrence. I think your argument is that attack triggered is too narrow? If so I agree.
>
> -- tk
> Tim "tk" Keanini
> Cisco
> mbl: 415.328.2722
> twtr: @tkeanini
>
>> On Sep 23, 2020, at 4:54 AM, Kurt Seifried <> wrote:
>>
>>
>> So CVE famously covers "bugs that cross a trust boundary" and to a lesser extent are "attacker triggered" and then a famous "and CVE is actionable, you can do something about it" (fix it, compensating control, etc.). Yes I know about INC1-4 as well, but I'm speaking more generally.
>>
>> What is the reason a bug like the 787 51 day reboot bug isn't classified as a security problem?
>>
>> https://www.theregister.com/2020/04/02/boeing_787_power_cycle_51_days_stale_data/
>>
>> So bad data from flight systems affecting pilot decisions, I think we can all agree that's "bad" for pretty large values of "bad" and violates a trust boundary (you're supposed to get good data into your flight system).
>>
>> Can it be attacker triggered? ... Sort of, in that an attacker could do an attack to prevent a reboot (falsify some paperwork? distract the person who is supposed to do it?) this is definitely a weakness.
>>
>> Can you do something about it, is it actionable? Well the FAA sent out a directive:
>>
>> https://ad.easa.europa.eu/ad/US-2020-06-14
>>
>> If you look at http://cveproject.github.io/docs/cna/application-guidance.html through a certain lense the above example can pass through inclusion rules INC1, INC2, INC3, INC4.
>>
>> I'm seeing bugs that have a major impact on systems (like rendering them non functional, destroying data, etc.) and while not attacker controlled, are worse in that they will happen regardless (due to time or number of cycles), and most of these are actionable (often a reboot or firmware update).
>>
>> Also please note this thread isn't just about "should we add more stuff to CVE and increase inclusion" but also "can we maybe better define the rules so we can clearly explain what is included and why"
>>
>> E.g. INC1 actually doesn't mention the ability to trigger, just if it "provides" the attacker a capability:
>>
>> ===
>> Does exploitation of the issue provide the attacker with extra privileges or information, or cause a denial of service, that the attacker would not already have before they attempt to exploit the issue?
>> ===
>>
>> Other examples:
>> https://www.theregister.com/2017/02/06/cisco_intel_decline_to_link_product_warning_to_faulty_chip/
>>
>> https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-a00092491en_us
>>
>> --
>> Kurt Seifried
>> <mailto:>