Chapter 48 Quiz: Vulnerability Research & Exploit Development Concepts¶

B — Report the vulnerability privately to the vendor with a detailed technical description, proof of concept, and a reasonable timeline for patch development before any public disclosure

Responsible disclosure (coordinated vulnerability disclosure) requires reporting the vulnerability to the affected vendor first, providing sufficient technical detail to reproduce and fix the issue, and agreeing on a disclosure timeline — typically 90 days (Google Project Zero standard) or as negotiated. This allows the vendor to develop and distribute a patch before the vulnerability becomes public knowledge and exploitable by malicious actors.

B — Stack overflows corrupt the return address or saved frame pointer to redirect execution; heap overflows corrupt heap metadata or adjacent heap objects to achieve arbitrary write or code execution through heap management exploitation

Stack buffer overflows overwrite the return address stored on the stack, redirecting execution when the function returns. Heap overflows corrupt heap chunk metadata (size fields, forward/backward pointers) or adjacent heap objects. Heap exploitation is generally more complex, requiring understanding of the specific allocator implementation (ptmalloc, jemalloc, Windows heap), but can bypass stack-specific protections like stack canaries.

B — The base score remains 9.8; the WAF mitigation is reflected in the Environmental score, which adjusts the base score based on the organization's specific deployment context

CVSS v3.1 has three metric groups: Base (intrinsic vulnerability characteristics), Temporal (exploit availability, patch status), and Environmental (organization-specific factors including mitigations, modified impact). The WAF is an environmental mitigation that would modify the Modified Attack Vector or Modified Attack Complexity in the Environmental score. The base score remains constant across all deployments.

B — Fuzzing automatically generates malformed inputs to trigger unexpected behavior; coverage-guided fuzzing (e.g., AFL, libFuzzer) uses code coverage feedback to mutate inputs toward unexplored code paths, while generation-based fuzzing creates inputs based on format specifications

Coverage-guided fuzzers instrument the target binary to track which code paths each input exercises. Inputs that reach new code coverage are retained and mutated further, systematically exploring the program's state space. Generation-based fuzzers (e.g., Peach, Boofuzz) use protocol or file format specifications to generate structurally valid but semantically malformed inputs. Both approaches complement each other in comprehensive vulnerability research.

B — ASLR randomizes the memory addresses of key areas (stack, heap, libraries, executable) at each execution; common bypasses include information disclosure vulnerabilities that leak addresses and brute-forcing on 32-bit systems where entropy is limited

ASLR defeats exploits that depend on hardcoded memory addresses by randomizing the base addresses of the stack, heap, shared libraries, and (with PIE) the executable itself. Bypass techniques include: information leaks that disclose runtime addresses, brute-forcing (feasible on 32-bit systems with ~16 bits of entropy), partial overwrites that leverage known relative offsets, and Return-Oriented Programming (ROP) chains constructed from non-ASLR modules.

B — A vulnerability where memory is freed but a dangling pointer still references it; if the freed memory is reallocated with attacker-controlled data, the dangling pointer can be used to hijack control flow or achieve arbitrary read/write

Use-After-Free occurs when a program continues to reference memory after it has been deallocated. If an attacker can control the contents of the reallocated memory (through heap spraying or precisely sized allocations), they can overwrite function pointers, vtable entries, or other critical data structures. UAF vulnerabilities are prevalent in browsers and are a leading vulnerability class in modern exploit chains.

B — Report the vulnerability to the program with the observation that it was discovered during normal browsing (not active testing), and do not attempt to exploit or validate it on production

Bug bounty scope must be respected even for critical findings. The researcher should report the vulnerability with available evidence (URL, parameters, observed behavior), note that it was discovered during normal browsing (not active testing against production), and let the program triage team validate it on their own systems. Most mature programs appreciate such reports and may grant exceptions for critical findings discovered passively.

B — It places a random value between local variables and the saved return address; if a sequential buffer overflow overwrites the canary, the process detects the corruption and terminates before the overwritten return address is used

Stack canaries (implemented as -fstack-protector in GCC/Clang, /GS in MSVC) insert a random value on the stack between local buffers and the saved return address. Before a function returns, the canary is verified. A sequential overflow that overwrites the return address must also corrupt the canary, triggering detection. Bypass techniques include information leaks to read the canary value, non-sequential writes, and format string vulnerabilities.

B — Coordinated disclosure involves working with the vendor on a timeline before public disclosure; full disclosure publishes vulnerability details immediately — coordinated disclosure gives time for patches but may leave users unknowingly at risk, while full disclosure pressures rapid fixes but exposes users to attacks

Coordinated disclosure (ISO 29147/30111) balances vendor patch development time against user risk. Full disclosure advocates argue that immediate publication pressures vendors to patch faster and empowers users to take interim mitigations. The industry standard is 90-day coordinated disclosure (Google Project Zero), with adjustments for active exploitation (shorter timeline) or complex patches (extensions).

B — The exploitability and impact should be evaluated in context — the CVSS Environmental score should reflect that the component is not exposed, reducing the effective risk, though remediation is still recommended to prevent future exposure

Context-aware risk assessment prevents alert fatigue and misallocation of remediation resources. While the CVSS base score reflects intrinsic severity, the Environmental score should account for compensating controls, deployment context, and actual exposure. An unexposed component carries lower immediate risk, but should still be remediated or removed to prevent future exposure through configuration changes or lateral movement.

B — ROP chains together short instruction sequences (gadgets) already present in executable memory, ending in ret, to build arbitrary computation — it was developed to bypass DEP/NX (non-executable memory) which prevents executing injected shellcode

DEP (Data Execution Prevention) / NX (No-Execute) marks data pages as non-executable, preventing traditional shellcode injection. ROP bypasses this by reusing existing executable code — small instruction sequences ending in ret (gadgets) are chained on the stack. Each gadget performs a small operation (pop a register, move data), and the chain collectively performs the desired action (e.g., calling mprotect() to make shellcode executable, or calling execve()).

B — Severity should be based on actual demonstrated impact — blind SSRF without data exfiltration or internal service exploitation is typically medium to high, not critical, unless it can be chained with other vulnerabilities to achieve greater impact

Bug bounty severity ratings should reflect actual demonstrated impact, not theoretical worst-case scenarios. Blind SSRF that can only confirm internal service existence is less severe than SSRF that exfiltrates cloud credentials or accesses internal APIs. However, if the researcher can chain the SSRF with other findings (e.g., accessing an unprotected admin panel on an internal service), the combined impact determines the severity.

B — A race condition (TOCTOU — Time-of-Check-to-Time-of-Use) occurs when a security check and a subsequent operation on the same resource can be interleaved by concurrent operations, allowing the resource state to change between the check and use

TOCTOU race conditions exploit the gap between a security validation (check) and the subsequent operation (use). For example, a program checks file permissions (check), then opens the file (use). An attacker can replace the file with a symlink to a sensitive file between the check and use operations. Unlike memory corruption bugs, race conditions exploit temporal logic flaws in concurrent code execution.

B — It marks memory pages as either writable or executable (but not both), preventing attackers from executing injected shellcode in data regions such as the stack or heap

DEP/NX enforces the W^X (Write XOR Execute) principle at the hardware level using the NX bit in page table entries. Memory pages can be writable (stack, heap) or executable (code sections), but not both simultaneously. This prevents classic exploitation where an attacker injects shellcode into a buffer (writable region) and redirects execution to it. ROP was developed specifically to bypass this mitigation.

B — Send follow-up communications through multiple channels (security@, PSIRT, executive contacts), engage a coordination center (CERT/CC, NCSC), document all communication attempts, and extend the disclosure timeline reasonably before considering public disclosure

Industry standards (ISO 29147, CERT/CC guidelines) recommend escalating through multiple vendor contacts, leveraging national coordination centers (CERT/CC, NCSC, JPCERT) as intermediaries, and documenting all communication attempts. CERT/CC will attempt to contact the vendor on the researcher's behalf and publishes a disclosure timeline (typically 45 days from their own notification). Public disclosure is a last resort when all coordination attempts have been exhausted.