Security in depth · Unit 21

Memory safety: boundaries and lifetimes

Understand what a program may access, why memory errors differ, and how developers prevent them.

9 minready

ATT&CK TA0002 Execution

Helpful before thisHow computers got here Operating systems

After this lesson you can

Distinguish an object's bounds from its valid lifetime.
Explain why a memory error does not automatically prove a particular security impact.
Match prevention, testing, and mitigation to the problem each addresses.

Lessons in this unit

Browse 6 lessons in this topic

A photo app holds an image in memory while you edit it. That sounds simple, but it needs to know where the image starts, how much storage belongs to it, and when that storage may be reused. Memory safety is about keeping those promises. You can understand the important ideas without knowing assembly language.

A program’s working space

An address space is a process’s view of memory. It can contain executable instructions, long-lived data, dynamically allocated objects, and temporary information for function calls. The operating system maps virtual addresses to resources and applies access permissions.

Textbook diagrams often show a stack and heap growing toward each other. Actual layouts depend on the platform, compiler, allocator, and running program; objects need not sit in that order. A process also cannot generally access another process’s memory just because both run on one computer.

A buffer is storage for a sequence such as image pixels. An object can occupy only part of a mapped memory page. Consequently, an operating system may permit access to a page even when a program has crossed an individual object’s boundary.

Bounds and lifetime are two essential checks. This diagram classifies access rules, not physical positions in RAM.

Where and when are different questions

A spatial error accesses outside an object’s allowed bounds. A read may expose unrelated data or cause a failure; a write may alter data or cause a failure. Neither label, by itself, says what an attacker can reliably achieve.

A temporal error concerns lifetime. With use-after-free, a reference remains after the object’s storage was released. The numerical address might still be mapped, or later hold another object, but the old reference is no longer valid.

Imagine borrowing a numbered locker. Reading the neighbouring locker breaks a boundary. Continuing to use your old locker assignment after returning it breaks the lifetime rule. Real memory is more complex, but these two questions remain useful.

A crash is evidence with limits

Suppose our photo app stops while decoding an image. A diagnostic report may identify an invalid read, its location, and the allocation involved. That supports a specific defect. The stop alone does not establish information theft, changed account permissions, or control of execution.

Consequences depend on the operation, affected data, process authority, input exposure, and protections actually active. Keep the observed error separate from a plausible consequence that still needs investigation. Even serious defects can have different effects in a sandboxed preview process and a broadly privileged service.

Protections solve different parts

Protection	What it contributes
Memory-safe abstractions	Enforce rules about bounds, ownership, or lifetime; unsafe components and native dependencies still need review.
NX / DEP	Prevents instruction execution from pages marked non-executable; it does not validate object bounds.
W^X	Restricts a region from being writable and executable simultaneously.
Stack canaries	Detect some overwrites of protected stack data; coverage depends on implementation.
ASLR	Randomizes parts of the address layout; it does not correct invalid accesses.

A mitigation reduces a possible consequence. A repair removes the defect. Both are useful, and neither should be confused with a promise that every memory error is harmless.

From diagnosis to a durable repair

Developers can examine object sizes and ownership, correct length calculations, and replace unsafe interfaces where appropriate. Automated tests should cover the repaired boundary and ordinary behavior. Fuzzing explores varied inputs; sanitizers such as AddressSanitizer detect certain invalid accesses in instrumented runs. Passing tests means those checks passed, not that every possible execution is safe.

Keep dependencies maintained and limit what parsers can access. A useful repair note names the failing object, observed operation, affected build, proposed change, and verification evidence. That gives the next person something concrete to improve.

EXPLORE THE CONCEPT

Read a fictional diagnostic

Choose a report. What does it establish, and what remains unknown?

Out-of-bounds read

The image reader accessed beyond its buffer. A bounds defect is supported; whether sensitive data left the process needs separate evidence.

Use after free

A callback accessed an object after release. Review ownership and callback lifetime; enlarging the buffer does not repair the lifetime rule.

Mitigation stopped execution

A protection prevented an operation. That is useful evidence about this run, but the underlying defect still needs a repair.

A simplified learning model. It connects to no systems and uses no real data.

Terms you met

address space buffer use-after-free mitigation

Check yourself

No timer. No penalties. Read the explanation and try again whenever you like.

A diagnostic shows an access inside a mapped page but outside the intended object. Is it valid?

Show the answer
Correct answer: No; page access permission does not establish object bounds. Objects can be smaller than pages, so these are separate boundaries.
An old reference is used after the object was released. Which distinction matters?

Show the answer
Correct answer: The object's lifetime has ended. A familiar numerical address does not make the old reference valid.
Which statement accurately describes DEP?

Show the answer
Correct answer: It restricts execution from non-executable memory pages. That limits one behavior while leaving the original memory defect to be repaired.
After a sanitizer flags an invalid read, what is the sound conclusion?

Show the answer
Correct answer: A particular invalid read was observed; broader effects need supporting evidence. Record the operation and environment before describing additional consequences.

Try it

WriteA fictional image viewer’s diagnostic report says: “read beyond the image buffer; process stopped.” Write one confirmed observation, one consequence still unknown, and one repair recommendation. Explain why “all files were stolen” would overstate the evidence.

References