Application, web and operating-system vulnerabilities

Objective 2.3 in this course covers vulnerabilities — CompTIA's scope note for it explains application, hardware, mobile device, virtualization, operating system (OS)-based, cloud-specific, web-based and supply chain vulnerabilities. This lesson takes application, web and OS; hardware, mobile, virtualisation, cloud and supply chain are the next lesson.

Why this matters

This objective asks you to explain vulnerabilities, not to exploit them, and that is exactly how the exam treats them. You are expected to recognise a described weakness by name, know what class of control addresses it, and not confuse it with the attack that uses it.

That last distinction is the one that costs marks. SQL injection is a vulnerability in 2.3 and an attack in 2.4, and the two objectives ask different questions about it: 2.3 asks what the weakness is, 2.4 asks what its exploitation looks like in a log.

The lesson

Memory injection, buffer overflow, and what the exam expects you to recognise

Memory injection is getting your own data or instructions into a running process's memory space so that the process acts on them. CompTIA names it as a vulnerability class; the everyday examples are injecting code into another process and running it under that process's identity and privileges, which is also why it appears again in Domain 2's malware material as a technique for evading file-based detection.

A buffer overflow is the classic case. A program allocates a fixed amount of memory for some input and then writes more than that into it, so the extra spills into adjacent memory. In the worst case the overwritten region includes the address the function will return to, and the attacker controls where execution goes next.

What the exam wants:

• the cause is failure to validate the length of input, not a flaw in the hardware;
• the consequence ranges from a crash (availability) to arbitrary code execution (everything);
• the defences are input validation and bounds checking in the code, plus platform mitigations — ASLR, which randomises memory layout so the attacker cannot predict addresses, and DEP/NX, which marks data regions non-executable;
• and languages with automatic memory management make the whole class much harder to hit, which is why "rewrite it in a memory-safe language" is a real answer and not a joke.

You will not be asked to write shellcode. You will be asked which control addresses it.

Race conditions: TOC/TOU, and why the gap between check and use matters

A race condition is a flaw where the outcome depends on the timing of events that were assumed to happen in order.

The security-relevant form is time-of-check to time-of-use (TOCTOU). The program checks a condition — this file is safe, this user has permission, this balance is sufficient — and then acts on it. Between the check and the use there is a window, and if an attacker can change the thing being checked inside that window, the program acts on a decision that is no longer true.

Concretely: a program verifies that a path is not a symbolic link, then opens it. An attacker replaces the path with a symlink to a privileged file in between. The check passed. The open hits the wrong file.

The same shape appears in business logic: a voucher validated and then redeemed, or a balance checked and then debited, where submitting many requests in parallel gets several to pass the check before any completes the use. This is why the exam's race condition questions often describe "the same request sent repeatedly and simultaneously".

The fix is to make check and use atomic — one indivisible operation, or a lock held across both — rather than to shorten the window, which only makes exploitation harder rather than impossible.

SQL injection and cross-site scripting stated as vulnerabilities, not exploits

Both are injection vulnerabilities, and both have the same root cause: input supplied by a user is treated as instructions rather than as data.

SQL injection exists when user input is concatenated into a database query. The application intended the input to be a value; the database reads part of it as query syntax. The consequences run from reading data the user should not see, through modifying or deleting it, to executing commands on the database host.

The control is parameterised queries (prepared statements), where the query structure is fixed and the input can only ever be a value. Input validation and least-privilege database accounts are defence in depth; a web application firewall is a compensating control that blocks known patterns. Note the ordering for exam purposes: parameterisation is the fix, the others reduce impact.

Cross-site scripting (XSS) exists when user input is included in a page without being neutralised, so a browser executes it as script. Variants worth knowing:

• Stored (persistent) — the payload is saved server-side and served to everyone who views the page. Highest impact.
• Reflected — the payload is in the request and comes straight back in the response, so the attacker must get the victim to follow a crafted link.
• DOM-based — the payload never reaches the server; client-side JavaScript writes attacker-controlled data into the page.

The controls are output encoding appropriate to the context, input validation, and a content security policy that restricts where scripts may come from. Marking session cookies HttpOnly limits what a successful XSS can steal.

Malicious update, and the trust an updater is granted by design

A malicious update is an update that installs successfully, is signed correctly, arrives through the official channel — and is hostile.

It is worth its own heading because it inverts the usual advice. "Keep software patched" is correct and remains correct, and it also means every one of your machines has a standing agreement to run code a third party sends it, with privilege, automatically.

Three routes:

• the vendor's build pipeline is compromised, so the malicious code is present before signing and the signature is genuine;
• the vendor's signing key is stolen, so an attacker can sign anything;
• the distribution channel is compromised, which is the weakest of the three because signature verification catches it.

What you can actually do: verify signatures, obtain software from the vendor rather than a mirror, stage updates so a small group gets them first and problems are caught before the fleet is affected, and monitor what newly updated software does rather than assuming an update is inert. Then accept that residual risk consciously — which is the Domain 5 answer, not a technical one.

Operating-system vulnerabilities, and end-of-support as a vulnerability class

OS-based vulnerabilities are flaws in the operating system itself: the kernel, the privileged services, the drivers. They matter more than application flaws of similar severity because the OS is the thing enforcing every boundary above it. A kernel privilege escalation defeats user permissions, application sandboxes and container isolation in one step.

Three sub-cases the exam uses:

• Privilege escalation flaws, which turn a limited foothold into full control and are therefore the second half of most real intrusions.
• Driver and firmware-adjacent flaws, which run with very high privilege and are patched on a different schedule from the OS — often by the hardware vendor rather than the OS vendor.
• Misconfiguration, which is not strictly a vulnerability in the software but is the most common real finding: unnecessary services enabled, weak default permissions, legacy protocols left on.

End-of-support deserves naming as a vulnerability class in its own right. Once support ends, the count of unpatched vulnerabilities only increases, and the vendor will publish nothing. The risk is therefore not static but growing, which changes how it should be recorded in the risk register: an accepted risk with a fixed review date, not a permanent exception.

What to take into the exam

• Buffer overflow's cause is unvalidated input length; ASLR and DEP/NX are platform mitigations, not fixes.
• TOCTOU is fixed by making check and use atomic, not by shortening the gap.
• Parameterised queries fix SQL injection. Output encoding fixes XSS. A WAF mitigates both and fixes neither.
• Stored XSS hits every viewer; reflected needs the victim to follow a link; DOM-based never reaches the server.
• A malicious update is correctly signed and arrives normally — staging and behavioural monitoring are what help.
• End-of-support is a vulnerability whose severity grows over time.