A memory-safe language prevents or detects invalid memory accesses through language rules, runtime checks, or implementation safeguards. It reduces failures such as out-of-bounds reads, use-after-free, uninitialized memory, and double freeing. section 10.6
The security risk is concrete: a client-controlled length can exceed the received data, causing memcpy() to read beyond a buffer and expose sensitive server memory. Heartbleed demonstrates how missing bounds checks turn ordinary message handling into information disclosure. section 10.6
Practical guidance:
- Prefer memory-safe languages such as C#, Rust, Go, Java, Swift, or JavaScript where possible. section 10.6
- When C or C++ is unavoidable, maximize test coverage and fuzz extensively to find memory-safety defects. section 10.6
Figure 10.9 The Heartbleed vulnerability: a malicious client requests a very long heartbeat but provides very little data to echo. The vulnerable server reads beyond the heartbeat buffer into other areas of memory.
Trace how a malicious heartbeat requests more data than it supplies, prompting an out-of-bounds read. section 10.6
