CWE-1323: Improper Management of Sensitive Trace Data
Weakness ID: 1323
Abstraction: Base Structure: Simple
Status: Draft
Presentation Filter:
Description
Trace data collected from several sources on the System-on-Chip (SoC) is stored in unprotected locations or transported to untrusted agents.
Extended Description
To facilitate verification of complex System-on-Chip (SoC) designs, SoC integrators add specific IP blocks that trace the SoC's internal signals in real-time. This infrastructure enables observability of the SoC's internal behavior, validation of its functional design, and detection of hardware and software bugs. Such tracing IP blocks collect traces from several sources on the SoC including the CPU, crypto coprocessors, and on-chip fabrics. Traces collected from these sources are then aggregated inside trace IP block and forwarded to trace sinks, such as debug-trace ports that facilitate debugging by external hardware and software debuggers.
Since these traces are collected from several security-sensitive sources, they must be protected against untrusted debuggers. If they are stored in unprotected memory, an untrusted software debugger can access these traces and extract secret information. Additionally, if security-sensitive traces are not tagged as secure, an untrusted hardware debugger might access them to extract confidential information.
Relationships
The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
Relevant to the view "Research Concepts" (CWE-1000)
Nature
Type
ID
Name
ChildOf
Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase
Note
Architecture and Design
Implementation
Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope
Impact
Likelihood
Confidentiality
Technical Impact: Read Memory
Can read secret values if they are captured in debug traces and stored unsafely
Demonstrative Examples
Example 1
In a SoC, traces generated from sources
include security-sensitive IP blocks such as CPU (with
tracing information such as instructions executed and
memory operands), on-chip fabric (e.g., memory-transfer
signals, transaction type and destination, and
on-chip-firewall-error signals), power-management
IP blocks (e.g., clock- and power-gating signals), and
cryptographic coprocessors (e.g., cryptographic keys and
intermediate values of crypto operations), among
other non-security-sensitive IP blocks including timers
and other functional blocks. The collected traces are
then forwarded to the debug and trace interface used by
the external hardware debugger.
(bad code)
Example Language: Other
The traces do
not have any privilege level attached to them. All
collected traces can be viewed by any debugger (i.e., SoC
designer, OEM debugger, or end user).
(good code)
Example Language: Other
Some of the
traces are SoC-design-house secrets, while some are OEM
secrets. Few are end-user secrets and the rest are
not security-sensitive. Tag all traces with the
appropriate, privilege level at the source. The bits
indicating the privilege level must be immutable in
their transit from trace source to the final, trace
sink. Debugger privilege level must be checked before
providing access to traces.
Potential Mitigations
Phase: Implementation
Tag traces to indicate owner and debugging privilege level (designer, OEM, or end user) needed to access that trace.
[REF-1151] Jerry Backer, David Hely
and Ramesh Karri. "Secure and Flexible Trace-Based Debugging of Systems-on-Chip". 2016-12.
<https://dl.acm.org/doi/pdf/10.1145/2994601>.
Content History
Submissions
Submission Date
Submitter
Organization
2020-07-20
Hareesh Khattri, Parbati K. Manna, and Arun Kanuparthi
The Intel Corporation
More information is available — Please select a different filter.
Description
