hardMultiple ChoiceObjective-mapped
PT0-002 Practice Question: A penetration tester is exploiting a Linux system…
A penetration tester is exploiting a Linux system that has ASLR enabled but no stack canaries. The vulnerability is a classic stack-based buffer overflow. Which of the following is the most effective method to achieve code execution?
⚠ Common exam trap
It's easy for candidates to assume ASLR always prevents code execution, but they overlook that PLT entries have fixed addresses in the binary, making ret2plt a viable bypass when no stack canaries are present.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Return to the PLT entry for system()
With ASLR enabled, direct shellcode injection fails due to randomized stack addresses, but the PLT entry for system() has a fixed, known address in the binary. Since there are no stack canaries, a simple buffer overflow can overwrite the return address to jump directly to system() in the PLT, passing a pointer to a command string (e.g., "/bin/sh") already in memory, achieving code execution without needing to know runtime addresses.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Prepend a NOP sled and inject shellcode into the buffer
Why it's wrong here
Even with a NOP sled, ASLR randomizes the entire stack region, so the attacker cannot predict the absolute address of the injected shellcode; a sled only tolerates small jumps within a known approximate address, not the multi-byte base shift. Moreover, if the NX bit is enabled on modern Linux systems, the stack is non-executable and the CPU will raise a fault regardless of where the shellcode lands. Without a prior memory leak to disclose the stack pointer, this approach is unreliable and easily thwarted.
- ✗
Return-to-libc (ret2libc)
Why it's wrong here
A ret2libc attack redirects execution to a libc function such as system(), but system()'s own address and the address of its argument string (e.g., '/bin/sh') are both located within libc's randomized mapping. Because ASLR re-bases libc at a random address per execution, the attacker must know the libc base to compute those offsets; hardcoding addresses from a previous run leads to a crash. Additionally, modern system() may require 16-byte stack alignment, so blind ret2libc without an info leak and precise ROP setup often faults even when the address is correct.
- ✓
Return to the PLT entry for system()
Why this is correct
In a non-PIE executable, the PLT section is mapped at a fixed virtual address because ASLR does not randomize the executable's own base. The PLT stub for system() lives at that constant address, and returning to it triggers the lazy binding mechanism to resolve and jump to the real system() via the GOT. This sidesteps the need to know libc's randomized base, making it a reliable code-reuse technique when the binary is not compiled with PIE and the GOT entry has already been resolved.
- ✗
Use a ROP chain to bypass ASLR and execute shellcode
Why it's wrong here
ROP chains circumvent non-executable stacks (DEP) by reusing existing code gadgets, but they do not bypass ASLR—gadget addresses are randomised at runtime, so without an information leak the attacker cannot reliably locate those gadgets. This option is tempting because ROP is the standard defence against DEP, but in this scenario ASLR is the active protection, not stack execution restrictions.
Go deeper
Related to this question
Learn chapter
Penetration Testing Methodology
Key term
Buffer overflow
A buffer overflow is a type of software vulnerability where a program writes more data to a memory buffer than it was designed to hold, causing adjacent memory to be overwritten.
Key term
Shellcode
Shellcode is a small piece of code used as a payload in the exploitation of a software vulnerability, typically giving an attacker a command shell on the target machine.
About these practice questions
Courseiva writes every PT0-003 question from scratch — 185 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PT0-003 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PT0-003 exam.