SECURE CODING IN C AND C++

Chapter 1: Running with Scissors — Exam-Ready Notes

6th Semester IT | Short Answer + Code Analysis Format | Full-Marks Preparation

SECTION 1 — CORE SECURITY TERMINOLOGY

These are the most likely 2-mark definition questions. Learn the precise distinction between each term.

Term Precise Definition Exam-Critical Distinction

Security Policy A set of rules that defines what is and is Everything is judged relative to the
not permitted in a system. All security policy. No policy = no violation.
analysis is measured against this.
Security Flaw A software defect that has the potential A flaw is a DEFECT. It may never
to create a security risk. Not all flaws be exploited if unreachable.
lead to attacks.
Vulnerability A security flaw that is reachable by an Flaw + reachable attack path =
attacker AND can be leveraged to Vulnerability. This is the upgrade
compromise the system. from flaw.
Exploit A specific technique or code that takes Exploit = attacker action =
advantage of a vulnerability to violate VIOLATION. Never use 'validate' or
the security policy. 'test' here.
Mitigation A defensive measure that reduces the Mitigation reduces risk. It is NOT a
risk or impact of a vulnerability. Does fix. Stack canaries mitigate but
not necessarily fix the root cause. don't eliminate buffer overflows.

Students confuse 'exploit' with 'penetration testing'. An exploit VIOLATES security

TRAP ⚠ policy. It is an ATTACKER action, not a tester's tool. Writing 'exploit validates
policy' = zero marks.

The Vulnerability Chain — Memorize This

Security Flaw → (+reachable attack path) → Vulnerability → (+attacker uses it) → Exploit →
(+policy violated) → Security Incident

Blaster: FLAW = unbounded while loop. VULNERABILITY = reachable via port 135
EXAMPLE over internet. EXPLOIT = Xfocus malformed RPC packet. INCIDENT = 8 million
machines infected.

SECTION 2 — THE BLASTER WORM CASE STUDY

Chapter 1 opens with Blaster. Any case study question likely references this. Know every layer.
2.1 What Happened — Timeline
Date Event
July 16, 2003 Microsoft releases Security Bulletin MS03-026 — patches the RPC DCOM buffer
overflow
July 25, 2003 Xfocus publishes working exploit code — 9 days after the patch
Aug 2–3, 2003 DEF CON hacker convention — worm release widely anticipated
Aug 11, 2003 Blaster worm released — 26 days after the patch. 336,000 machines infected
same day.
Aug 14, 2003 Over 1 million machines infected
Final count At least 8 million Windows systems infected (Microsoft data)

2.2 Root Cause — The Vulnerable Code

The flaw was in the hostname extraction logic in the Windows RPC DCOM service:

Version Code Problem

VULNERAB while (*pwszTemp != L'\\') { *pwszServerName+ No null check, no destination
LE + = *pwszTemp++; } bounds check, no null termination
PARTIAL while (*pwszTemp != L'\\' && *pwszTemp != L'\0') Source null-check added BUT
FIX { *pwszServerName++ = *pwszTemp++; } destination still overflows if source
is large
FULLY while (*p != L'\\' && *p != L'\0' && maxLen > 0) Bounds on source AND destination
SECURE { *dst++ = *p++; maxLen--; } *dst = L'\0'; + explicit null termination

2.3 CERT C Violations Triggered

Rule Violation Impact
EXP33-C Reading uninitialized / out-of-bounds memory — Out-of-bounds read → undefined
loop runs past string end behavior
STR31-C No validation that destination has sufficient Destination buffer overflow →
space memory corruption
STR32-C Copied string not null-terminated Subsequent string ops read
garbage memory
ARR30-C Pointer arithmetic proceeds without bounds Out-of-bounds pointer → undefined
check behavior
MSC37-C Multiple pointer increments in one expression Maintenance and review risk
reduces clarity

2.4 How Blaster Propagated

• Generated random IP addresses and attempted infection over TCP port 135
• Sent malformed RPC packet to trigger buffer overflow in DCOM interface
• Delivered shellcode that downloaded and executed [Link] via UDP port 69
• Added registry key for persistence across reboots
 • Launched SYN flood DoS attack on [Link] on specific dates to prevent patching

SECTION 3 — WHY C/C++ IS THE PROBLEM LANGUAGE

Reason Technical Explanation Consequence

No automatic Arrays are raw pointers. The runtime does Buffer overflows occur with no
bounds checking not track array size. arr[200] on a 10- warning or immediate crash.
element array compiles silently.
Trust-based C was designed for expert systems Incorrect code compiles and runs
design philosophy programmers. It delegates all safety — errors are programmer errors,
responsibility to the programmer. not language errors.
Undefined Writing out-of-bounds is undefined Bugs are invisible until exploited.
behavior is silent behavior. Program may continue running No exception is thrown.
with corrupted memory.
Unrestricted Pointers can be incremented past valid An attacker can craft inputs that
pointer arithmetic memory with no runtime error. steer pointer writes to arbitrary
addresses.
Legacy code base Billions of lines of C exist in OS kernels, Vulnerable code persists for
embedded systems, network decades in critical infrastructure.
infrastructure. Rewriting is impractical.

From the book: 'A relatively small number of root causes accounts for the majority
KEY
of vulnerabilities.' — The goal of secure coding is to eliminate those root causes at
QUOTE
the source.

SECTION 4 — SECURITY CONCEPTS (EXTENDED)

4.1 Who is the Threat?

Threat Actor Profile Motivation
Script Kiddies Low skill, use existing tools and exploits Disruption, reputation, boredom
Criminals Organized, financially motivated Data theft, ransomware, fraud
Nation-State High skill, significant resources Espionage, infrastructure disruption
Actors
Insiders Authorized access, trusted position Financial gain, revenge, ideology
Security Skilled, authorized or responsible Finding flaws to improve security
Researchers disclosure

4.2 Cost of Insecure Software

• Direct costs: Incident response, system recovery, legal liability
• Indirect costs: Loss of customer trust, brand damage, regulatory fines
• National security: Critical infrastructure attacks affect governments and citizens
 • Patch lag: Even after a patch, 90-95% of vulnerable systems take months to update (as shown
by Blaster)

4.3 Software Security vs. Security Software

Software Security = building security IN during development (proactive)
Security Software = bolt-on tools like antivirus, firewalls (reactive)
The book argues that reactive solutions are reaching their limits. Root cause elimination during coding
is the only scalable solution.

SECTION 5 — DEVELOPMENT PLATFORMS (Brief)

5.1 Operating Systems Relevant to This Course

• Linux/UNIX — ELF binary format, GOT, PLT, ASLR, W^X, PaX (covered in detail in Ch 2–3)
• Windows — PE/COFF format, IAT, SEH, RtlHeap, DEP (covered in detail in Ch 3–4)

5.2 Compiler Protections (Preview)

Protection What It Does Chapter Covered
Stack Canaries (GCC - Places a random value before return Chapter 2
fstack-protector) address. Checks it before return. Detects
stack smashing.
ASLR (OS-level) Randomizes base addresses of stack, Chapter 2
heap, libraries. Makes shellcode
addresses unpredictable.
NX / DEP / W^X Marks memory regions either Writable OR Chapter 2
eXecutable — never both. Prevents code
injection.
RELRO Makes GOT read-only after dynamic Chapter 3
linking. Prevents GOT overwrite attacks.

SECTION 6 — EXAM STRATEGY FOR CHAPTER 1

6.1 High-Probability Question Types

Question Type What to Expect Marks
Definition pair Distinguish vulnerability from exploit, flaw from 2–3
vulnerability
Blaster case study Identify the root cause, the specific flaw, the fix 3–5
Code analysis Show the vulnerable while loop, ask what's wrong 4–5
and how to fix it
Why is C insecure? List and explain 3–4 technical reasons 3–4
 CERT C violations Name the rules violated by a given code snippet 2–3

6.2 Answer Template for Short Answer Questions

For any 'what is X' question, use this 3-part structure:
• DEFINITION: One precise sentence defining the term technically
• DISTINCTION: What makes this different from the adjacent concept (flaw vs vulnerability, etc.)
• EXAMPLE: One concrete example from Blaster or the while loop code

6.3 Examiner Traps — Do NOT Fall Into These

Exploit ≠ Testing. An exploit VIOLATES policy. Never write 'exploit is used to test
TRAP 1
or validate security'.

Mitigation ≠ Fix. A mitigation reduces risk. Stack canaries mitigate buffer overflows
TRAP 2
but do not fix the root cause (unbounded copy).

Vulnerability ≠ Flaw. Not every flaw is exploitable. A flaw only becomes a

TRAP 3
vulnerability when there is a reachable attack path.

Partial fix ≠ Full fix. Adding null-check to source without adding destination bounds
TRAP 4
check still leaves a buffer overflow. Always check BOTH sides.

SECTION 7 — RAPID REVISION CHEAT SHEET

Read this the night before the exam. Everything you need to recall Chapter 1 in 5 minutes.

Topic Key Facts to Recall

Security Flaw Software defect with POTENTIAL security risk. May never be exploited.
Vulnerability Flaw + reachable attack path. The key upgrade word is REACHABLE.
Exploit Attacker technique that VIOLATES security policy. Never 'tests' it.
Mitigation Reduces risk. Does not eliminate root cause. Examples: canaries, ASLR,
DEP.
Blaster root cause Unbounded while loop — no null check, no destination bounds — in
Windows RPC DCOM.
Blaster impact 8 million machines infected. 26 days after patch release. Port 135 TCP.
Blaster flaw code while (*p != L'\\') { *dst++ = *p++; } — missing null check AND size limit
Full secure fix needs (1) null terminator check on source, (2) maxLen counter on dest, (3) explicit
null termination after loop
CERT rules violated EXP33-C, STR31-C, STR32-C, ARR30-C, MSC37-C
Why C is vulnerable No bounds checking + trust-based design + undefined behavior is silent +
 unrestricted pointer arithmetic
Patch lag problem 90-95% of vulnerable systems take months to patch even after fix is
available
Software security goal Eliminate root causes during development. Reactive solutions (AV, firewalls)
are insufficient at scale.

Chapter 1 Complete — Next: Chapter 2 Strings (Highest Exam Weight)