Sensitive Data Storage in Improperly Locked Memory

Draft Variant
Structure: Simple
Description

This vulnerability occurs when an application stores sensitive information, like passwords or encryption keys, in system memory that isn't properly secured from being written to disk. If the memory isn't locked, the operating system's virtual memory manager can swap it to a page or swap file, leaving the data exposed on the storage drive where attackers could potentially recover it.

Extended Description

To prevent sensitive data from being swapped to disk, developers use functions like `VirtualLock()` on Windows or `mlock()` on POSIX systems. However, these methods have critical limitations and platform dependencies. On older Windows versions (95, 98, Me), `VirtualLock()` is just a stub with no real effect. On POSIX systems, while `mlock()` keeps pages in physical memory, it doesn't universally guarantee they won't also appear in swap, making it an unreliable safeguard for secrets. Furthermore, using `mlock()` typically requires elevated privileges, and its behavior can vary significantly between operating systems. Developers must always check the return values of these locking functions to confirm they succeeded, as a silent failure leaves data unprotected. Crucially, relying solely on memory locking is a fragile strategy. A more secure approach involves avoiding long-term storage of sensitive data in memory altogether, using secure, dedicated functions provided by the operating system for handling secrets, or encrypting the data before it ever touches volatile memory.

Common Consequences 1
Scope: Confidentiality

Impact: Read Application DataRead Memory

Sensitive data that is written to a swap file may be exposed.

Potential Mitigations 2
Phase: Architecture and Design
Identify data that needs to be protected from swapping and choose platform-appropriate protection mechanisms.
Phase: Implementation
Check return values to ensure locking operations are successful.
Modes of Introduction
Implementation
Affected Resources
  1. Memory
Related Weaknesses
Taxonomy Mapping
  • OWASP Top Ten 2004
  • CERT C Secure Coding
  • Software Fault Patterns