Draft CWE related to the Intel issue we discussed a couple of weeks ago: Physical Attacks

FIPS explicitly mentions electroexplosive systems so that the hardware can commit suicide before you interogate it (so to speak). So for certain values of physical security you can actually build systems that can't easily be defeated. They're just hideously expensive and don't apply to most real world scenarios.

On Tue, Jun 2, 2020 at 3:41 PM Art Manion <> wrote:

On 2020-06-02 15:44, Chris Levendis wrote:

> *CWE-xxxx: Improper Physical Protection Mechanism*
>
> Abstraction: Class Level Weakness
>
> *Description*
>
> The product does not protect or incorrectly protects against an unauthorized actor's ability to physically access restricted regions of the product.

OK so far, possibly "...does not sufficiently protect..."?

> *Extended Description*
>
> Sections of a product intended as restricted may be rendered physically accessible through the inadvertent or intended efforts of a user to compromise the product's physical security. Product design should take into consideration the physical protection portions of the product intended as user inaccessible. Additionally, testing should occur to ensure the manufacturing process results in the intended physical protection mechanism for the product to be deployed.

My starting point is that physics (and physical access) always wins -- there is ultimately no computer/network/digital/cyber way to defend against physical access.

But that's OK, it is still widespread practice to provide *some* defenses against physical access, like secure boot, tamper evidence, wipe my phone after N bad password attempts, and content distribution/other routing tricks for DDoS defense. We also have locks on cases and doors. Even fuses on some devices.

So it seems like a non-physical security bug in one of these defenses is easy to qualify as a CWE (and CVE). There is a defense mechanism, it can be bypassed with only remote/non-physical access, you had one job and failed. Also valid to CWE/CVE for physical access, particularly for the type of physical access the control is designed to defend against. Maybe secure boot shouldn't fail due to unauthorized USB device, and a fingerprint reader shouldn't accept invalid fingerprints.

Now we reach the line. Crack open the case? Power glitching? Attach probes? Shave off silicon? There are some defenses against these sorts of physical attacks, but private key is somewhere in the hardware.

One issue is that the line will continue to move as practices and expectations move. We don't like telnet much anymore because plain text.

So, I'm OK with the CWE language, I think it leaves open the possibility of shifting practices and expectations.

Issuing a CVE or not for this CWE will probably remain a topic of discussion. One answer is to tend to assign, because CVE IDs are labels. Assessing risk (attacker has to open the case and do things) is separate, and to one person a specific CVE may be near zero risk, someone else may choose not to deploy laptops in certain environments. Same CVE ID, different risk.

- Art

... [show rest of quote]

--

Kurt Seifried

I remain uneasy with this. At best, I guess I would hope this might be a rare one to use to begin with. But more exactly, even where it may be appropriate... it's not so much the physical access that's the problem as what you can accomplish with that physical access. An attacker with physical access to the device can achieve physical access to the device... what next? We should, in most things, call an info leak an info leak, regardless of whether the attack vector is "Network" or "Physical". To Art's point, do we then assign a CVE..? Well, I feel we may be looking into the deep.

From: Chris Levendis <>
Date: Tuesday, June 2, 2020 at 8:33 PM
To: CVE Editorial Board Discussion <>, "Manion, Art" <>
Subject: Re: [EXT] Re: Draft CWE related to the Intel issue we discussed a couple of weeks ago: Physical Attacks

Since this is on the public list, is the Board okay with me copying Alec Summers and Drew Buttner on these messages so that they can participate?

Drew is my Deputy PL for standards and technology and Alec is the CWE technical leader. They need this great feedback, which I greatly appreciate you all offering.

Since this convo is public, any objections?

C

Get Outlook for iOS

From: Art Manion <>
Sent: Tuesday, June 2, 2020 5:39:56 PM
To: Chris Levendis <>; CVE Editorial Board Discussion <>
Subject: [EXT] Re: Draft CWE related to the Intel issue we discussed a couple of weeks ago: Physical Attacks

On 2020-06-02 15:44, Chris Levendis wrote:

> *CWE-xxxx: Improper Physical Protection Mechanism*
>
> Abstraction: Class Level Weakness
>
> *Description*
>
> The product does not protect or incorrectly protects against an unauthorized actor's ability to physically access restricted regions of the product.

OK so far, possibly "...does not sufficiently protect..."?

> *Extended Description*
>
> Sections of a product intended as restricted may be rendered physically accessible through the inadvertent or intended efforts of a user to compromise the product's physical security. Product design should take into consideration the physical protection portions of the product intended as user inaccessible. Additionally, testing should occur to ensure the manufacturing process results in the intended physical protection mechanism for the product to be deployed.

My starting point is that physics (and physical access) always wins -- there is ultimately no computer/network/digital/cyber way to defend against physical access.

But that's OK, it is still widespread practice to provide *some* defenses against physical access, like secure boot, tamper evidence, wipe my phone after N bad password attempts, and content distribution/other routing tricks for DDoS defense. We also have locks on cases and doors. Even fuses on some devices.

So it seems like a non-physical security bug in one of these defenses is easy to qualify as a CWE (and CVE). There is a defense mechanism, it can be bypassed with only remote/non-physical access, you had one job and failed. Also valid to CWE/CVE for physical access, particularly for the type of physical access the control is designed to defend against. Maybe secure boot shouldn't fail due to unauthorized USB device, and a fingerprint reader shouldn't accept invalid fingerprints.

Now we reach the line. Crack open the case? Power glitching? Attach probes? Shave off silicon? There are some defenses against these sorts of physical attacks, but private key is somewhere in the hardware.

One issue is that the line will continue to move as practices and expectations move. We don't like telnet much anymore because plain text.

So, I'm OK with the CWE language, I think it leaves open the possibility of shifting practices and expectations.

Issuing a CVE or not for this CWE will probably remain a topic of discussion. One answer is to tend to assign, because CVE IDs are labels. Assessing risk (attacker has to open the case and do things) is separate, and to one person a specific CVE may be near zero risk, someone else may choose not to deploy laptops in certain environments. Same CVE ID, different risk.

- Art

TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.

For details about what personal information we collect and why, please see our Privacy Notice on our website at: [ https://www.trendmicro.com/privacy]