Disclosure policy

When a vulnerability has been reported (see Vulnerability reporting) to the Core Team, it is up to them to implement mitigations and fixes as well as report back to stakeholders in a responsible way. This page describes the responsible disclosure policy that applies to the OP-TEE project.

Note

The “core team” in the OP-TEE part of TrustedFirmware.org (who owns the OP-TEE project) mainly consists of engineers coming from the members of TrustedFirmware.org.

Rules

To have some kind of ground to stand on we have defined a set of rules and conditions that applies both when it comes to being a taker of information as well as being reporter of security issues. It should be noted that it is hard to write rules that you can follow to 100%, since depending on the type of security issues being dealt with it might or might not be possible for TrustedFirmware.org to re-distribute the information right away.

As an example of when we couldn’t follow our rules and disclosure policy was when we got informed (under NDA) about the Spectre and Meltdown issues (this was before it was public knowledge). That was considered so sensitive that we weren’t even allowed to share or discuss this outside TrustedFirmware.org. But in general, we strive and try to do our best to follow the rules etc that have been defined on this particular page.

Receiving information

The one receiving information about and fixes related to OP-TEE security vulnerabilities must follow these rules:

  1. The receiver of vulnerability information and/or security fixes shared by TrustedFirmware.org are not allowed to share, re-distribute or otherwise spread knowledge about the issues and security fixes outside their own company until the disclosure deadline has passed and the information is publicly available.

    Note

    If the receiver still insists to share it with other people/companies he must first get approval from TrustedFirmware.org to do so.

Reporting issues

The one reporting security vulnerabilities to the TrustedFirmware.org are asked to do it under the conditions mentioned below. It might seem like a long list, but we hope that it won’t scare people away from reporting issues. It’s mostly common sense and also aims to rule out questions that otherwise might come to mind. In short, the rules by default gives TrustedFirmware.org the power to decide what to do with the reported issue if nothing else has been agreed between them and the reporter.

  1. If nothing else has been agreed between the reporter and

    TrustedFirmware.org, then the rules and information as stated on this page applies.

    1.1. This means that the TrustedFirmware.org will re-distribute the information to the stakeholders according to the plan described further down here.

    1.2. This also means that patches etc will be submitted to the upstream project based on the proposed disclosure day that will be given to the reporter after initial investigation.

  2. By default, the information about the reported issue(s) will be shared within TrustedFirmware.org and a vetted list of stakeholders. If you as a reporter aren’t OK with that, then you must inform us about that when reporting the issue.

  3. By default, the TrustedFirmware.org decides whether there should be a CVE created or not. If the reporter insist on having a CVE created, then this should be expressed when doing the reporting.

  4. TrustedFirmware.org have the rights to involve other experts to help us with mitigations and patches. If you as a reporter aren’t OK with that, then you must inform us about that when reporting the issue.

  5. Reporting security issues under NDA should be seen as a last resort thing. If/when that happens, then we will come up with a mutual agreement on a disclosure plan.

  6. It is appreciated if the reporter have estimated some initial severity scoring as described further down on this page. This is mainly to get an indication whether we share the same view about the severity or not.

Trusted Stakeholders

TrustedFirmware.org keeps track of companies and maintainers who are considered as trustworthy OP-TEE users. This is a vetted list and people from companies can only be added to that list after first talking to TrustedFirmware.org. In short what is required to be added to that list is:

  • A justification of why you need to know about security issues and should have access to security fixes before they are going public.
  • A company email address (we do not accept gmail, yahoo and similar addresses).
  • You accept our disclosure policy rules (as described at here).

Note

The TrustedFirmware.org have the rights to deny anyone to be on this list. We also have the rights to remove people on the list if there should be a reason to do so.

Disclosure deadline

By default we are following the industry standard with 90-days disclosure deadline. This applies both when we find security issues that needs to be fixed in the upstream project, as well as when we are the ones reporting issues found in vendor trees (forks of OP-TEE). The reason for 90-days is to give companies enough time to patch and deploy updated software to their devices.

Likewise we are going to propose a 90-days disclosure deadline for issues that are being reported to us, that we are supposed to fix.

However, for issues that falls in the severity category ‘low’ and in some cases ‘medium’ (see Severity table below), we have the rights to decide whether to upstream patches as soon as they are ready. If the reporter or the some of the trustworthy stakeholders knowing about the security issue disagrees, then they must inform the TrustedFirmware.org about it as soon as possible and then we will come up with an alternate plan.

0day exploits

This is a previously unknown and unpatched vulnerability which is been used actively in the wild. As a consequence of that we believe that 0day exploits require a much more urgent action. I.e., a fix or some kind of mitigation that limits the damage needs to be created as soon as possible. Our target for such fixes and mitigations are within 14 days from the day when we learned about the 0day exploit (full weeks, including weekends).

Issue process

For regular security issues (non 0day) we follow the flow chart below. Note that the orange path is when it is a low (and maybe medium) severity issue we are dealing with, so that is a special case with an alternate path.

digraph issue_process {
    start [label="Issue reported\nDay 1\n90 day counter starts", shape="box", style=rounded];
    end [label="Day 90", shape="box", style=rounded];
    create [label="Create mitigations"];
    inform [label="Inform stakeholders"];
    patch_ready [label="Patch ready"];
    go_public [label="Update security advisories"];
    upstream_fixes [label="Upstream Fixes"];
    medhigh_prio [label="Severity >= Low/Medium?", shape="parallelogram"];
    create_cve [label="Create CVE"];
    update_cve [label="Update CVE\n(if created)"];


    start -> create;
    start -> inform;

    create -> medhigh_prio;
    medhigh_prio -> create_cve [label="Yes"];
    medhigh_prio -> upstream_fixes [label="No", color="orange"];

    create -> patch_ready;
    patch_ready -> inform [label="Share fixes"];
    patch_ready -> end;
    patch_ready -> medhigh_prio [label="Check if patch should go upstream directly", color="orange"];

    end -> inform;
    end -> go_public;
    end -> upstream_fixes;
    end -> update_cve;
}

For 0day exploits we follow this flow chart:

digraph issue_process {
    start [label="\0day issue reported\nDay 1\n14 day counter starts", shape="box", style=rounded];
    end [label="Day 14", shape="box", style=rounded];
    create [label="Create mitigations"];
    inform [label="Inform stakeholders"];
    patch_ready [label="Patch ready"];
    go_public [label="Update security advisories"];
    upstream_fixes [label="Upstream Fixes"];
    medhigh_prio [label="Severity >= Medium?", shape="parallelogram"];
    create_cve [label="Create CVE"];
    update_cve [label="Update CVE"];

    start -> create;
    start -> inform;

    create -> medhigh_prio;
    medhigh_prio -> create_cve [label="Yes"];

    create -> patch_ready;
    patch_ready -> inform [label="Share fixes"];
    patch_ready -> end;

    end -> inform;
    end -> go_public;
    end -> upstream_fixes;
    end -> update_cve;
}

Recognition

Once the disclosure deadline has passed and information and mitigations will go public we want to give credits to the ones finding, reporting and fixing the issues. Typically that is given in two ways. One is in textual form at our security advisories page and the other way is directly in patches applied on the upstream project in questions.

For patches we prefer having a real physical person being mentioned (see Reported-by and Suggested-by in the example below), but also a company name or group could be used if it was a joint effort finding the security issue or if the person finding the issue prefer not being mentioned directly for some reason. A patch would typically look like this:

core: fixes privilege escalation

By doing X, one was able to exploit a privilege escalation
vulnerability. By changing Y this is no longer a security
issue.

Fixes CVE-20xx-YYYY

Signed-off-by: John Doe <john.doe@foobar.org>
Reviewed-by: Richard Roe <richard.roe@foobar.org>
Reported-by: Jane Doe <jane.doe@notable-hackers.com>
Suggested-by: Jane Doe <jane.doe@notable-hackers.com>

CVE

If there is a need to request a CVE identifier, then the Distributed Weakness Filing Project should be used. At that page you will find the current link to the DWF project.

Severity scoring

When deciding the severity for a vulnerability we start out by doing a scoring similar to the DREAD scoring system, but tweaked for OP-TEE purposes. This mainly serves as a guide to get some kind of indication of the severity. The final severity is decided on case by case basis.

Note

A DREAD score can change over time. The initial analysis could give a certain score, but later on when a vulnerability is well known and exploits are readily available the score will be different (ususally more severe).

Damage Potential

This should give an answer to much damage is caused if the vulnerability is exploited.

Score Damange potential
0 No damage.
1 Normal World User space is compromised and could leak sensitive data.
1 Denial of service from Normal World.
2 Normal World Linux kernel space is compromised and could leak sensitive data.
5 TEE Trusted Application compromised and could leak data only accessible by the Trusted Application.
7 TEE core (kernel space) compromised and leaking trivial information.
9 TEE core (kernel space) compromised and leaking sensitive information.
10 TEE fully compromised and the attacker in full control.

Reproducibility

This describes how easy (or hard) it is to reproduce the attack.

Score Reproducibility
0 Not reproducible.
1 No proven attack exists.
1 The attack is very difficult to reproduce, even with knowledge of the security hole (requires special lab equipment for example)
2 Proof of concept attack exists, but only works in a specially crafted, non-standard configuration.
4 The attack can be reproduced, but only with tooling / software / knowledge that has not been made public (typically the one finding the security issue have created a tool, which hasn’t been released yet).
9 The attack can be reproduced, but only with tooling (JTAG, ChipWhisperer etc) / software / knowledge that is readily available to anyone.
10 The attack can be reproduced every time by a novice user without any need for extra tools.

Exploitability

This should answer how easy it is to launch an attack.

Score Exploitability
0 Not exploitable.
1 Theoretically exploitable (even with knowledge, there seems to be no viable path for a real exploit).
7 Only authenticated user(s) can make the attack.
8 A skilled programmer with in-depth knowledge could make the attack.
9 A novice programmer could make the attack in a short time.
10 A novice user could make the attack in a short time (exploits readily available on internet and/or integrated in known hacker/pen-testing tools).

Affected Users

This should give a rough answer to how many people are affected by a successful attack.

Score Affected Users
0 No users affected.
1 All users, running a debug/developer configuration.
1 A single user.
10 All users, running a release configuration (key customers).

Discoverability

This should answer how easy it is to discover the threat.

Score Discoverability
0 Not discoverable.
1 The vulnerability would require other successful exploits in order to be able to discover this bug.
2 The bug is obscure, and it is unlikely that users will work out damage potential.
5 Information explaining the attack exists, but is only shared with a small group of people (and it is not intended to be shared publicly in a foreseeable time or until mitigations has been merged).
10 Published information explains the attack.

Severity table

Based on the DREAD score, we get some kind of indication of the severity. In the table below you can see how we are mapping things between a DREAD score and severity.

Severity Score CVE? Comment
No risk [0, 1) No CVE created. This is not considered as a security issue, it’s a regular bug.
Low [1, 4) No CVE created. This could be seen as a security issue, but could probably be treated as general bug.
Medium [4, 7) Depends. This is a security issue, but on the lower side of the score it might be treated as a bug. For the higher end it is likely that a CVE will be created.
High [7, 9) CVE created. It is definitely a security issue.
Critical [9, 10] CVE created. It is definitely a security issue, very urgent to start working with mitigations etc.

Example

To have a better understanding how this would look like in practice, let’s show a couple of examples.

Example 1 - Spectre v2 - Branch Target Injection (CVE-2017-5715)

Note that this example should be seed from a TrustZone / TEE point of view.

  • D: What damage could it cause?
    • TEE leaking sensitive data, i.e., 9.
  • R: Easy to reproduce?
    • No proven attack exists on TrustZone/TEE software, i.e, 1.
  • E: Easy to launch the attack?
    • Theoretically exploitable, i.e., 1
  • A: How many users would be affected by a successful attack?
    • All users, i.e., 10.
  • D: How easy is it to discover this issue?
    • It’s public information, i.e., 10.

This gives the score: (9 + 1 + 1 + 10 + 10) / 5 = 6.2 which indicates that this would a bit on the higher end of medium severity.

Example 2 - Bellcore attack on OP-TEE (CVE-2017-1000412)

  • D: What damage could it cause?
    • TEE leaking sensitive data (private key used to sign and verify Trusted Applications), i.e., 9.
  • R: Easy to reproduce?
    • With a ChipWhisperer (readily available) it would be possible for a somewhat skilled engineer to do this on their own on a device running OP-TEE, i.e., 9.
  • E: Easy to launch the attack?
    • A skilled engineer with in-depth knowledge could make the attack, i.e., 8.
  • A: How many users would be affected by a successful attack?
    • All users, i.e., 10.
  • D: How easy is it to discover this issue?
    • It’s public information, i.e., 10.

This gives the score: (9 + 9 + 8 + 10 + 10) / 5 = 9.2 which indicates that this would be a critical issue.