Race Conditions

📋 Instructions: Answer all questions, then click Grade Quiz to see your results.

1. What is a race condition?

A. A denial-of-service attack that floods a system with more requests than it can handle B. A flaw that occurs when the outcome depends on the relative timing of operations accessing a shared resource C. A technique for bypassing firewall rules by sending packets faster than they can be inspected D. An encryption vulnerability caused by insufficient random number generation speed

Correct answer: B. A race condition is specifically about timing and ordering of operations on shared resources — not about speed or volume of requests. A: a flood of requests is a denial-of-service attack. C: packet speed has nothing to do with race conditions. D: random number generation speed is unrelated to this vulnerability class.

2. A program checks whether a file is safe to write (time of check), then writes to it (time of use). An attacker replaces the file with a symbolic link to a sensitive system file between those two steps. Which term BEST describes this attack?

A. Buffer overflow B. SQL injection C. TOCTOU (Time-of-Check/Time-of-Use) D. Man-in-the-middle

Correct answer: C. This is the classic TOCTOU pattern: the check and use refer to different things because the resource changed in the race window between them. A: buffer overflow involves writing past buffer boundaries, not file replacement. B: SQL injection manipulates database queries. D: man-in-the-middle intercepts communications between parties.

3. Which technique COMPLETELY eliminates the race window in a TOCTOU vulnerability?

A. Making the check and use an atomic operation B. Increasing the size of the buffer between check and use C. Requiring user authentication before every file access D. Logging all file access events for later audit review

Correct answer: A. Atomic operations eliminate the race window by making check and use a single indivisible step — no gap exists for the resource to change. B: buffer size is irrelevant to TOCTOU. C: authentication verifies identity but does not prevent resource state changes between check and use. D: logging records events after the fact and has no preventive effect on the race window.

4. A developer states that their TOCTOU vulnerability is not exploitable because the race window is only 500 microseconds. Why is this reasoning flawed?

A. 500 microseconds is actually a very large window — it is longer than most cryptographic operations B. Race windows can only be measured in milliseconds, not microseconds C. The developer is correct — a 500-microsecond window is too short to exploit D. An attacker running a replacement loop can execute thousands of operations per second, making even microsecond windows reliably exploitable with automation

Correct answer: D. The absolute window size doesn't determine exploitability — what matters is how many attacker attempts fit within the window per second. Automation makes tiny windows reliably hittable. A: this comparison is irrelevant; the reasoning is about automation, not comparing operations. B: race windows absolutely can be measured in microseconds and are exploitable at that scale. C: the developer is wrong — automation eliminates the constraint of manual timing.

5. A banking application allows users to initiate transfers. Two simultaneous $500 withdrawal requests are submitted against an account with $1,000. Both requests pass the balance check and both execute. What type of vulnerability does this demonstrate?

A. SQL injection — the attacker manipulated the balance query B. Race condition — both requests read the balance before either's debit was applied, resulting in a double-spend C. Buffer overflow — the concurrent requests exceeded the application's processing buffer D. Privilege escalation — one of the threads gained elevated access to complete the second transaction

Correct answer: B. Classic double-spend race condition: two concurrent threads both pass the same check before either's write-back is applied. A: no query manipulation occurred — both queries ran correctly but non-atomically. C: concurrent requests are not a buffer overflow. D: no privilege escalation occurred — both threads executed with the same access level they already had.

6. Matching: Match each race condition term to its description.

TERM

TOCTOU

Race Window

Mutex

Atomic Operation

DESCRIPTION

The time gap between a resource check and its use — the window where an attacker can change the resource

A synchronization lock that allows only one thread to access a shared resource at a time

An operation that completes as a single, uninterruptible step with no gap between check and use

A race condition where a program checks a resource at one time and uses it at another — vulnerable if the resource changes in between

7. Analysis: A web application's session management system checks whether a session token is valid (not expired) and then uses it to authorize the request. The check and authorization happen as two separate database queries. What specific risk does this create, and what should the developer do to fix it?

Risk: The gap between the validity check and the authorization use creates a TOCTOU race condition. An attacker who can invalidate the session token between the check and the use — for example, by expiring it in a second request — may cause the authorization to proceed on a token that is no longer valid. Additionally, if two simultaneous requests use the same token, both may pass the validity check before either's use triggers a "consumed" state.

Fix: Use a single atomic database operation that both validates and marks the token as consumed in one indivisible step — so the token can only be used once, and the check-and-use cannot be separated. With atomic handling, the second concurrent request cannot pass the validity check because the first request's consumption is committed before the second can read the token's state.

8. Evaluation: A security auditor finds a TOCTOU vulnerability in a system utility that writes log files. The developer responds: "This is a theoretical vulnerability — exploiting it requires perfect timing, and real attackers don't have that kind of precision." Evaluate this response. Is the developer's reasoning sound?

Disagree — the developer's reasoning is unsound.

The premise that race conditions require "perfect timing" is wrong. An attacker does not manually time the attack. They write two concurrent scripts: one triggers the vulnerable program in a tight loop, and another replaces the target file in a tight loop. Both run simultaneously at maximum speed. With thousands of operations per second on each side, the attacker will statistically land a replacement inside the race window within seconds — often faster than a human can react.

The fact that the window is small does not make it unexploitable; it just means more attempts are needed, and automation provides exactly that. Real-world TOCTOU exploits have been demonstrated against operating system utilities, package managers, and privilege escalation paths in production systems.

"Requires precise timing" is only true when the attacker is performing the attack manually — automation eliminates that constraint entirely. The developer has confused human manual capability with automated machine capability. The correct response is to fix the vulnerability, not to assume attackers lack the precision that automation trivially provides.

Race Conditions Quiz