A network service written in C crashes when it receives an input string longer than expected, and researchers then craft a payload that overwrites the saved return address and runs their own code. Which vulnerability is this, and which class of mitigation addresses it?
Select an answer to reveal the explanation.
Short Explanation
Pour a gallon into a pint glass and it spills onto everything next to it. A buffer overflow does that in memory — extra input spills over and overwrites the return address. You stop it by checking lengths in code and turning on protections like ASLR and DEP that make the spill hard to aim.
Full Explanation
A stack-based buffer overflow occurs when a program copies input into a fixed-size buffer without checking its length, as with unsafe C functions such as strcpy or gets. Excess bytes overwrite adjacent memory, including the saved return address, so when the function returns, execution jumps where the attacker chose. The root fix is bounds checking: length-limited functions, input validation, and memory-safe languages. Platform mitigations raise the cost of exploitation: Data Execution Prevention marks stack and heap memory non-executable, address space layout randomization makes target addresses unpredictable, and stack canaries detect overwritten return addresses before they are used. A race condition depends on the timing of concurrent operations on shared state; locking addresses it, but the trigger here is input length, not timing. SQL injection alters database queries built from strings and has no bearing on memory layout in a C service. A weak TLS cipher affects confidentiality of traffic in transit; changing ciphers does nothing about how the service handles a decrypted input string. Exam caveat: ASLR and DEP make exploitation harder but do not remove the bug, and return-oriented programming can bypass DEP. Operational check: confirm the vendor patch, verify the binary is compiled with stack protection and position-independent code, and fuzz the input handler.