COMMON WEAKNESS ENUMERATIONIncomplete

CWE-1295

Debug Messages Revealing Unnecessary Information

The product fails to adequately prevent the revealing of unnecessary and potentially sensitive system information within debugging messages.

Abstraction

Base

Structure

Simple

Likelihood of Exploit

Medium

Understand the problem

What is the problem?

The product fails to adequately prevent the revealing of unnecessary and potentially sensitive system information within debugging messages.

Extended description

Debug messages are messages that help troubleshoot an issue by revealing the internal state of the system. For example, debug data in design can be exposed through internal memory array dumps or boot logs through interfaces like UART via TAP commands, scan chain, etc. Thus, the more information contained in a debug message, the easier it is to debug. However, there is also the risk of revealing information that could help an attacker either decipher a vulnerability, and/or gain a better understanding of the system. Thus, this extra information could lower the "security by obscurity" factor. While "security by obscurity" alone is insufficient, it can help as a part of "Defense-in-depth".

Root cause

How and when does the problem arise?

Lifecycle phase

Implementation

Risk

What does successful exploitation lead to?

Read MemoryBypass Protection MechanismGain Privileges or Assume IdentityVaries by Context

Affected security scopes: Confidentiality, Integrity, Availability, Access Control, Accountability, Authentication, Authorization, Non-Repudiation

Defence

How is it prevented and fixed?

Implementation

Implementation-phase defence

Detail
Ensure that a debug message does not reveal any unnecessary information during the debug process for the intended response.

Verification

How is it detected?

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)