Base · Medium

CWE-1323: Improper Management of Sensitive Trace Data

Trace data collected from several sources on the System-on-Chip (SoC) is stored in unprotected locations or transported to untrusted agents.

CWE-1323 · Base Level ·1 Mitigations

Description

Trace data collected from several sources on the System-on-Chip (SoC) is stored in unprotected locations or transported to untrusted agents.

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.

Potential Impact

Confidentiality

Read Memory

Demonstrative Examples

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
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
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.

Mitigations & Prevention

Implementation

Tag traces to indicate owner and debugging privilege level (designer, OEM, or end user) needed to access that trace.

Frequently Asked Questions

What is CWE-1323?

CWE-1323 (Improper Management of Sensitive Trace Data) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Base-level weakness. Trace data collected from several sources on the System-on-Chip (SoC) is stored in unprotected locations or transported to untrusted agents.

How can CWE-1323 be exploited?

Attackers can exploit CWE-1323 (Improper Management of Sensitive Trace Data) to read memory. This weakness is typically introduced during the Architecture and Design, Implementation phase of software development.

How do I prevent CWE-1323?

Key mitigations include: Tag traces to indicate owner and debugging privilege level (designer, OEM, or end user) needed to access that trace.

What is the severity of CWE-1323?

CWE-1323 is classified as a Base-level weakness (Medium abstraction). Its actual severity depends on the specific context and how the weakness manifests in your application.