L09 · Format Strings, Integer Conversion & Off-by-One Bugs

1. Format Strings, Integers & Off-by-One

Title

CS 161 · Lesson 9 of 45

printf's stack walk · %x leak / %n write · signed vs unsigned · the single null byte

2. By the end of this lesson you can…

Objectives

1. Explain why printf(user_input) is a vulnerability and printf("%s", user_input) is safe, and why the compiler cannot catch the difference.
2. Trace where each % modifier reads on the stack — starting 8 bytes above printf's rip, walking up 4 bytes each — and tell %x (read) apart from %n (write).
3. Show how a signed length passed to an unsigned size_t parameter bypasses a bounds check, and how count * size overflow under-allocates.
4. Locate a single-byte off-by-one as the low byte of the saved frame pointer, and explain why strncpy may leave a string not null-terminated.
5. Connect all three to control-flow hijacking, ASLR defeat, and the Week-4 defenses.

3. What survived from L08 · Buffer Overflows & Stack Smashing?

Warm-up

4. Format Strings

Section

Part A · §3.3

5. Three bugs, one root: data trusted as control

Concept

Today's three classes look unrelated, but they share a theme from L8: attacker data crossing into a role it shouldn't have. A format string becomes a program; a length becomes a size; one extra byte becomes a frame pointer.

All three are memory-safety bugs in C, and all three end the same way: corrupted memory the attacker steers toward control of the program.

6. Fill in: Data that escapes its role for Three bugs, one root: data trusted as control

Comparison

7. printf is variadic — it trusts its first argument

Concept

printf takes a variable number of arguments. It learns how many — and of what type — only by reading the format string at runtime and counting the % modifiers it finds.

variadic function — A function that accepts a variable-length argument list (declared with ...). The callee, not the compiler, decides how many arguments to pull off the stack.

printf("x=%d y=%d\n", x, y);  // 2 modifiers -> reads 2 args
printf("hello\n");            // 0 modifiers -> reads 0 args

8. What each one costs: printf is variadic — it trusts its first argument

Trade off

9. Intuition — the format string is a tiny program

Intuition

Think of the format string as a little program that printf executes. Each % is an instruction: go grab the next argument off the stack and print it this way.

If the attacker writes that little program (because the format string came from user input), the attacker decides how many arguments printf grabs and what it does with them. The data on the stack is no longer printf's to interpret — it's the attacker's.

10. Break it if you can: Intuition — the format string is a tiny program

Counterexample

11. Safe vs vulnerable: one argument of difference

Concept

The whole bug is which slot the user input lands in: as data behind a %s it is harmless; as the format string itself it is interpreted.

// SAFE: user_input is DATA, consumed by the %s
printf("%s", user_input);

// VULNERABLE: user_input IS the format string
printf(user_input);

12. By analogy: Safe vs vulnerable: one argument of difference

Analogy

13. The compiler cannot save you here

Concept

printf is legally variadic — taking 0, 1, or 20 arguments is all valid. So the compiler cannot flag printf(buf) as wrong: a format string with zero % modifiers and zero extra arguments is a perfectly legal call.

The mismatch only exists at runtime, once the actual string is known. (Modern compilers offer a heuristic warning — -Wformat-security — but it is opt-in and only fires on a non-literal format string; the language itself permits the call.)

14. It is not only printf

Concept

Any function that takes a format string has the same exposure if user data reaches that parameter: fprintf, sprintf, snprintf, vprintf, and especially syslog(priority, user_msg) — a very common real-world sink.

syslog(LOG_INFO, user_msg);      // VULNERABLE if user_msg has %n
syslog(LOG_INFO, "%s", user_msg); // safe
sprintf(out, fmt_from_user, ...); // VULNERABLE format parameter

15. Which is which, by Format parameter

Discrimination

16. The mechanism: where printf starts reading

Concept

When printf runs and meets its first % modifier, its internal argument pointer starts 8 bytes above printf's saved rip and walks upward 4 bytes for each modifier consumed.

high addr
  ...                              (further stack args)
  arg #1  (first real argument)    rip + 8   <- argptr STARTS here
  &format-string                   rip + 4
  saved rip of printf              rip + 0
  saved ebp of printf
low addr  (printf's locals)

17. Guess the shape of the answer: Worked: printf("x=%d y=%d z=%d", x, y, z)

Estimation

18. Worked: printf("x=%d y=%d z=%d", x, y, z)

Worked example

int x = 11, y = 22, z = 33;
printf("x=%d y=%d z=%d", x, y, z);  // three %d, three args

Output: x=11 y=22 z=33. Every modifier had a matching argument, so every read landed on real data.

19. Watch it run: Worked: printf("x=%d y=%d z=%d", x, y, z)

Pattern

20. Guess the shape of the answer: Worked: the MISMATCH — three %d, only two…

Estimation

21. Worked: the MISMATCH — three %d, only two args

Worked example

int x = 11, y = 22;
printf("x=%d y=%d z=%d", x, y);  // THREE %d, only TWO args!

The compiler never complained — the call is legal. The mismatch is a silent information leak (CWE-134).

22. Work backwards from the answer: Worked: the MISMATCH — three %d, only two…

Reverse engineer

23. %x — the read/leak primitive

Concept

%x prints the next stack word as hex. A string of %x %x %x simply walks up the stack, leaking one word per modifier. %08x zero-pads each to 8 hex digits so the dump lines up.

// attacker sends this AS the format string:
printf("%08x %08x %08x %08x");  // == printf(user_input)

No matching arguments exist, so every %x dumps live stack memory — saved registers, return addresses, canaries, pointers. This is how a format-string bug defeats ASLR (Lesson 15): it reads back a real runtime address.

24. Teach it back: %x — the read/leak primitive

Explain it

25. %n — the write primitive (the dangerous one)

Concept

%n does not print anything. It writes the number of bytes printed so far into the address held by the next argument slot — turning a read bug into an arbitrary memory write.

%n — Stores the count of characters output so far into an int* taken from the next argument slot. Attacker-controlled width specifiers control the value written; attacker-placed pointers control where.

// CONCEPTUAL / TOY only — do not build a real exploit
int count;
printf("hello%n", &count);  // count <- 5 ("hello" is 5 chars)

Because the attacker controls both the address slot (by walking the stack) and the value (via field-width padding), %n is a write-what-where primitive — the seed of a control-flow hijack, kept strictly conceptual here.

26. Take the definitions apart: variadic function vs %n

Definition probe

27. Intuition — direct parameter access supercharges the walk

Intuition

Walking the stack %x by %x is tedious. The $ notation (%7$x) lets an attacker jump directly to the 7th argument slot without printing the six before it — like an array index into the stack.

This is why a format-string bug is so powerful: once the attacker knows which slot holds a target pointer, %N$n writes to exactly that slot. The stack walk is no longer linear and clumsy — it is random access into memory.

28. Guess the shape of the answer: Worked: leaking 4 stack words with %08x

Estimation

29. Worked: leaking 4 stack words with %08x

Worked example

// attacker input becomes the format string:
//   printf("AAAA %08x %08x %08x %08x")
// 'AAAA' = 0x41414141 sits in the buffer on the stack

The leaked return address is a real runtime pointer — exactly what an attacker needs to bypass ASLR before the L8-style hijack.

30. Inspect it line by line: Worked: leaking 4 stack words with %08x

Error analysis

31. Why this is a control-flow primitive, not just a leak

Concept

Combine the two halves: %x finds a live address (the rip slot, defeating ASLR), and %n writes to an address the attacker placed in the buffer. Read then write = a full hijack chain — all from one printf(buf).

Kept strictly conceptual — the takeaway is that a single uncontrolled format string yields BOTH disclosure and corruption, which is why CWE-134 is rated so severely.

32. Something is wrong here: printf(buf) vs printf("%s", buf)

Anomaly

33. Trap: printf(buf) vs printf("%s", buf)

Trap

34. Trap: 'the compiler catches the arg-count mismatch'

Trap

35. Something is wrong here: '%x and %n do the same thing'

Anomaly

36. Trap: '%x and %n do the same thing'

Trap

37. Integer Conversion

Section

Part B · §3.4

38. Same bits, two meanings

Concept

A 32-bit word is just bits. Whether it means a signed value (two's complement) or an unsigned value depends only on the type the code uses to read it. The bug is when one piece of code disagrees with another about which interpretation applies.

Callback to L4: the all-ones word 0xFFFFFFFF is -1 read as int, but 4294967295 (~4.29e9) read as unsigned.

39. Watch it run: Same bits, two meanings

Pattern

40. The conversion rule that bites: mixed comparisons go unsigned

Concept

When C compares a signed and an unsigned operand of the same width, the signed one is converted to unsigned first. So (int)-1 < (unsigned)10 is evaluated as 4294967295u < 10u — which is false. The negative number wins by becoming gigantic.

int s = -1;
unsigned u = 10;
if (s < u)  /* FALSE: -1 -> 4294967295u, not < 10 */
    puts("reached?");   // never prints

This is exactly why a if (len < bufsize) guard fails for negative len: the comparison silently promotes len to a huge unsigned value.

41. Intuition — a negative length becomes 'enormous'

Intuition

Lengths and sizes in C library calls are usually size_t, which is unsigned. If your own code carries a length as a signed int and an attacker makes it negative, the moment it crosses into a size_t it flips to a huge positive number.

So a check like if (len < MAX) happily passes for a 'small' negative len — but the very same len, handed to memcpy, is interpreted as billions of bytes. The guard and the copy disagree about what len means.

42. Fill in: Passes if (len < MAX)? for Intuition — a negative length becomes…

Comparison

43. What has to happen first: Worked: signed length bypasses the bounds check

Ranking

44. Worked: signed length bypasses the bounds check

Worked example

void copy_into(char *src, int len) {   // len is SIGNED
    char buf[64];
    if (len > 64) return;              // guard: reject too-big
    memcpy(buf, src, len);             // memcpy wants size_t (unsigned)
}
// attacker calls copy_into(src, -1);

45. Draw the shape of it: Worked: signed length bypasses the bounds…

Blank canvas

46. Intuition — wraparound is an odometer rolling over

Intuition

A 32-bit unsigned value is an odometer with 2^32 positions. Add past the top and it silently rolls back to 0 — there is no error, no exception, just a small number where a huge one belonged.

So count * size for big enough operands produces a tiny product. malloc happily returns a tiny buffer; the code 'knows' it asked for room for count items and writes all of them. The allocator and the loop disagree about how big the request was.

47. Integer overflow → under-allocation

Concept

malloc(count * size) computes the product in fixed-width arithmetic. If count * size overflows past 2^32, it wraps to a small number — so malloc returns a tiny buffer, but the following loop still writes count full elements.

// 32-bit: count * size can wrap around 2^32
void *p = malloc(count * size);
for (unsigned i = 0; i < count; i++)
    p[i] = read_element();   // writes count elements -> heap overflow

malloc allocates the wrapped (tiny) size; the loop writes the true (huge) count of elements. The surplus spills past the allocation — a heap overflow (CWE-190) that feeds the heap exploits of Lesson 10.

48. Plan first: Worked: count * size overflow, step by step

Step zero

49. Worked: count * size overflow, step by step

Worked example

unsigned count = 0x10000001;   // attacker-chosen
unsigned size  = 16;
int *p = malloc(count * size);  // 0x10000001 * 16
for (unsigned i = 0; i < count; i++)
    p[i] = 0;                   // writes count ints

50. Where negative lengths come from

Concept

Attackers rarely type '-1'. Negative or huge lengths arise naturally: a header field read as a signed int, a subtraction like end - start that goes negative, or atoi on attacker text returning a negative number — all then flow into a size_t parameter.

int len = end - start;     // if start > end, len < 0
if (len > MAX) return;     // negative passes
memcpy(dst, src, len);     // len -> huge size_t

51. Truncation on assignment

Concept

Assigning a wider integer into a narrower type drops the high bytes. A size_t or int stored into a short (2 bytes) or char (1 byte) keeps only the low bits — the validated 'big' value becomes a small one the rest of the code trusts.

size_t big = 0x10000;        // 65536
short  small = big;          // short is 2 bytes
// small now holds 0x0000 = 0  (the 0x1 high byte is dropped)

A length checked as a large size_t can be truncated to a tiny short used for allocation, while the original large value still drives the copy — another size mismatch.

52. Teach it back: Truncation on assignment

Explain it

53. Something is wrong here: 'I checked count < MAX, so malloc is safe'

Anomaly

54. Trap: 'I checked count < MAX, so malloc is safe'

Trap

55. Break it on purpose: 'I checked count < MAX, so malloc is safe'

Break the constraint

56. Trap: signed int length vs unsigned size_t

Trap

57. Off-by-One

Section

Part C · §3.5

58. The fence-post error

Concept

A fence-post (off-by-one) bug writes exactly one element too many — almost always a <= where it should be <. A buffer of N slots has valid indices 0…N−1; index N is one past the end.

char a[N];
for (int i = 0; i <= N; i++)   // BUG: should be i < N
    a[i] = src[i];             // a[N] writes one past the buffer

One extra byte sounds harmless — the next slide shows why, on the stack, that single byte can be exploitable (CWE-193).

59. By analogy: The fence-post error

Analogy

60. Intuition — counting fence posts vs fence panels

Intuition

A fence with N panels has N+1 posts. Mixing up 'panels' and 'posts' is the original off-by-one. An array a[N] has N slots but its highest valid index is N−1 — the index is a post, the count is a panel.

So the safe loop bound is i < N, never i <= N. The <= counts one post too many and writes a[N], the slot that does not exist.

61. What has to happen first: Worked: the classic <= fence-post trace

Ranking

62. Worked: the classic <= fence-post trace

Worked example

char a[4];
char src[] = "WXYZ";          // 4 chars
for (int i = 0; i <= 4; i++)   // BUG: <= instead of <
    a[i] = src[i];

63. Where does each piece belong: L09 · Format Strings, Integer Conversion &…

Sorting

64. Intuition — the one byte you wrote lands on the sfp

Intuition

Locals sit below ebp, and the saved frame pointer (sfp) sits at ebp+0 — right above the local buffer. A buffer that ends just below the sfp has its first out-of-bounds byte land exactly on the sfp's lowest address byte.

Because x86 is little-endian, that lowest-address byte is the least-significant byte of the sfp. Overwriting it shifts the saved frame pointer by up to 255 bytes — and when the caller restores ebp from that corrupted sfp, the next function's whole frame is relocated to attacker-influenced ground.

65. Plan first: Worked: the single-null-byte overflow

Step zero

66. Worked: the single-null-byte overflow

Worked example

void f(char *src) {
    char buf[8];                 // buf occupies ebp-8 .. ebp-1
    for (int i = 0; i <= 8; i++) // off-by-one: writes buf[0..8]
        buf[i] = src[i];         // buf[8] is at ebp+0 = sfp low byte
}

67. Draw the shape of it: Worked: the single-null-byte overflow

Blank canvas

68. Off-by-one also hides in length math

Concept

Not every off-by-one is a <= loop. A classic is forgetting the +1 for the terminator: allocating strlen(s) bytes instead of strlen(s) + 1, then strcpy-ing — the '\0' lands one byte past the allocation.

char *d = malloc(strlen(s));   // BUG: missing + 1 for '\0'
strcpy(d, s);                  // writes strlen(s)+1 bytes

Fix: malloc(strlen(s) + 1). The terminator is real storage that the size arithmetic must account for — a single forgotten +1 is a heap off-by-one (CWE-193).

69. Break it if you can: Off-by-one also hides in length math

Counterexample

70. strncpy does NOT always null-terminate

Concept

strncpy(dst, src, n) copies at most n bytes. If src is shorter than n, it pads the rest with NUL — terminated. But if src is exactly n bytes or longer, strncpy copies n bytes and stops — with no terminating NUL.

char buf[8];
strncpy(buf, src, sizeof(buf));  // n = 8
// if strlen(src) >= 8, buf has NO '\0' terminator
printf("%s", buf);               // reads PAST buf until it finds a 0

An un-terminated string is a time bomb: the next strlen/%s/strcpy keeps reading past buf until it stumbles on a zero byte — leaking or corrupting adjacent memory (CWE-193 / out-of-bounds read).

71. What each one costs: strncpy does NOT always null-terminate

Trade off

72. Intuition — strncpy is a copy budget, not a terminator

Intuition

Read strncpy(dst, src, n) as 'spend a budget of n bytes'. If the source runs out early, the leftover budget is spent on NUL padding. If the budget runs out first, copying just stops — and a terminator was never in the budget.

The '\0' is a side effect of padding, not a guarantee of the function. People remember 'strncpy is the safe strcpy' and forget the safety only holds when the source is shorter than the buffer.

73. Fill in: Budget spent on for Intuition — strncpy is a copy budget, not a…

Comparison

74. What has to happen first: Worked: strncpy when src shorter vs src == bufsize

Ranking

75. Worked: strncpy when src shorter vs src == bufsize

Worked example

char buf[4];
// case 1: src = "hi"   (len 2)
strncpy(buf, "hi", 4);   // -> 'h','i','\0','\0'
// case 2: src = "data" (len 4)
strncpy(buf, "data", 4); // -> 'd','a','t','a'  (NO terminator!)

76. Inspect it line by line: Worked: strncpy when src shorter vs src ==…

Error analysis

77. Something is wrong here: 'strncpy always null-terminates'

Anomaly

78. Trap: 'strncpy always null-terminates'

Trap

79. Something is wrong here: 'off-by-one is only one byte, so it's harmless'

Anomaly

80. Trap: 'off-by-one is only one byte, so it's harmless'

Trap

81. Which of these survive contact with L09 · Format Strings, Integer Conversion &…?

Two truths and a lie

82. Without one step: Spotting all three classes — a checklist

Constraint

83. Spotting all three classes — a checklist

Pattern

1. Format string: is any user data used AS a format string (printf(buf), fprintf, syslog(buf))? Force it into a %s argument.
2. Read vs write: remember %x leaks the stack, %n writes it — argptr starts at rip+8 and walks up 4 bytes per modifier.
3. Signedness: does a length live as signed int then meet an unsigned size_t API? Make it size_t end-to-end.
4. Multiplication: does malloc(count*size) or similar risk wrapping past 2^32? Check for overflow before allocating.
5. Narrowing: is a wide value assigned into a short/char and then trusted? Watch the dropped high bytes.
6. Bounds loops: is it <= where it should be <? One byte past a stack buffer hits the sfp low byte.
7. Termination: does strncpy/snprintf actually leave a '\0'? Reserve a byte and set it by hand.

84. Where does it stop working: Spotting all three classes — a checklist

Edge cases

85. Rule out three: Checkpoint — the format-string mechanism

Elimination

86. Checkpoint — the format-string mechanism

Check

printf("%d %d", x) is called with only ONE argument supplied. Trace where each modifier reads before you click.

87. Misconceptions to drop now

Concept

• 'printf(buf) is fine if buf is just text' — if buf holds %x/%n, printf interprets it; pass user data as a %s argument.
• 'The compiler catches printf mismatches' — printf is variadic; the count/type mismatch is invisible until runtime.
• '%x and %n do the same thing' — %x reads/leaks a stack word; %n WRITES the running count to a pointer.
• 'Signed/unsigned comparisons are safe' — a negative signed length becomes a huge unsigned size at memcpy/malloc.
• 'strncpy always null-terminates' — it does NOT when strlen(src) >= n; reserve a byte and terminate by hand.
• 'Off-by-one is only one byte, so it's harmless' — that byte can be the sfp's low byte, relocating the next frame.

88. Synthesis — a second path to the rip

Concept

• Format strings are a second route to the rip alongside the L8 stack overflow: they can both LEAK (%x defeats ASLR, L15) and WRITE (%n is write-what-where).
• Stack canaries do NOT stop a %n write — %n writes to an arbitrary address, skipping straight over the canary instead of overwriting through it.
• Integer bugs feed heap overflows (L10): a wrapped count*size under-allocates, then the loop writes the true count past the allocation.
• Off-by-one turns a single byte into a frame-pointer hijack — exploitable despite its tiny size.
• Together these motivate the Week-4 defenses: avoid non-literal formats, use unsigned sizes with overflow checks, and bounds-safe string APIs.

89. Primary sources & where to read more

Concept

• Textbook §3.3–3.5 — format-string, integer-conversion, and off-by-one vulnerabilities.
• scut / team teso, "Exploiting Format String Vulnerabilities" (2001) — the original %x stack-read and %n write write-up.
• CWE-134 (externally-controlled format string), CWE-190 (integer overflow/wraparound), CWE-193 (off-by-one) — MITRE's weakness catalog.
• ISO C standard — printf is variadic and relies on default argument promotions; the language cannot type-check a runtime format against its arguments.
• Lab: compile printf(buf) with -Wformat-security, feed it %08x %08x %08x, and watch live stack words appear (toy, authorized targets only).

90. Connect it up: L09 · Format Strings, Integer Conversion & Off-by-One Bugs

Connect it up

91. Recap — Lesson 9

Recap

You can explain why printf(user_input) is exploitable, trace printf's argptr from rip+8 upward, tell %x (leak) from %n (write), show how a signed length and a wrapped count*size corrupt memory, and locate the off-by-one byte on the saved frame pointer.