Securing Servers by Restricting Globally Writable Folders

The Attack Vector: Compromised /tmp The command history reveals a classic exploitation path: the attacker compiled source code (gcc foo.c) and placed the executable binary directly into /tmp/lockfile. The key vulnerability here is that /tmp is typically a world-writable directory. This allows any user (or compromised process) to create, modify, or execute files in this location, facilitating arbitrary code execution.

Eliminating Distractors Option A (ASLR) mitigates memory corruption exploits but does not prevent an attacker from simply writing and executing a new binary file if they have write permissions to the folder. Option D (EDR signatures) is reactive; while helpful for detection, it does not address the underlying architectural flaw of allowing unauthorized executables in shared directories. Option B (Application allow lists) is a strong control, but it is overly broad and complex to implement compared to fixing the immediate file system permission issue.

Why C is Correct Option C addresses the root cause: the lack of restrictions on globally writable folders. By implementing OS-level restrictions (such as noexec mount options or restricting write permissions to specific users/groups), the server prevents the creation of executable payloads in /tmp. As noted in community feedback, "Restricting or hardening" these folders stops the attacker from placing the payload where it can be executed. This aligns with CIS Benchmarks and NIST guidelines for securing Linux environments.

Conclusion The question tests the ability to identify insecure default configurations. The presence of a compiled payload in /tmp proves that global write access was exploited. Restricting this access is the most direct and effective preventive measure.