In-Class Lab: Heap

0. How this lab runs

Seven puzzles on the same local machine, in two blocks that match the lecture: Block A shows you how the heap behaves; Block B turns that behaviour into control. Most tasks print a marker when you get it right, and the first two in Block B are pure demonstrations. Nothing in class is handed in.

A1. The Chunk Header

cd ~/ierg4851/week6/in-class-lab/A1-chunk-header
./chunk

# to read the header yourself:
./dbg
#   it stops right after the malloc and prints the chunk header
#   then try:   p/x p      x/4gx p-16      continue

A1b. The Next Chunk’s prev_size Is Yours

cd ~/ierg4851/week6/in-class-lab/A1b-prev-size
./prevsize

# to watch the header word change:
./dbg
#   it stops before and after the write; the next chunk's prev_size
#   ends up holding your 0xA5 pattern while its size field is untouched

A2. Which Freed Chunk Comes Back

cd ~/ierg4851/week6/in-class-lab/A2-tcache-lifo
./lifo

# to see the free list before you answer:
./dbg
#   it stops just after the two frees and prints both chunks
#   the first user qword of a freed chunk is its forward pointer

A3. What a Stale Pointer Reads

cd ~/ierg4851/week6/in-class-lab/A3-uaf-read
./uaf

# to watch the stale pointer follow the memory:
./dbg
#   it stops after the new allocation and prints n, m and what n reads

B1. The Same Chunk, Twice on the Free List

cd ~/ierg4851/week6/in-class-lab/B1-double-free
./twice demo     # the whole sequence, done for you
./dbg            # the same, printing both chunks and the 0x30 free list at every step

#   note 0 A ; note 1 B       two 0x30 chunks, one after the other
#   free 0 ; free 1 ; free 0  chunk a goes on the list a second time

B2. A Write Through a Pointer the Program Already Freed

cd ~/ierg4851/week6/in-class-lab/B2-uaf-write
./dangle demo
./dbg

#   login alice      a session: a 0x30 chunk, level = "user"
#   logout           free()s it -- and does NOT clear the pointer
#   msg BBBB...      same 0x30 chunk, so the message lands on the session
#   show             current = 0x…260  level="BBBB"

B3. Escalate an Ordinary Account to root

cd ~/ierg4851/week6/in-class-lab/B3-double-free-exploit
./escalate demo

# the account is root when uid == 0xdeadbeef -- a magic value, not 0
#   acct bob            a normal account: uid = 1000 (0x3e8), name "bob"
#   free ; free         the same chunk, twice -- 2.27 does not stop you
#   acct bob            sign in again: the SAME chunk comes back
#   note deadbeef root  the note's id and text land on uid and name
#   whoami              uid = 0xdeadbeef -> root
#   check               uid and name both changed; the program wrote neither

./dbg                # the chunk and the 0x30 free list at every step

After class — two exercises to submit on Blackboard

Everything above is done in class and is not submitted. These two you do at home and submit — required, but not graded. They are reproduction exercises: the programs are short, the steps are exact, and you are not asked to develop an exploit — run each one, watch what happens, and explain what you saw.

Both are already on the lab machine, next to the in-class material:

cd ~/ierg4851/week6/after-class
ls      #  01-int-truncation/   and   02-off-by-null/   -- each has a Makefile

Neither exercise needs glibc 2.27, and a normal gcc on any Linux behaves the same way — that is the point: these are bug classes, not version-specific tricks.

E1. An integer check you can walk around

The program takes a length on the command line, checks it, and then copies that many bytes from stdin into a 32-byte array. A tag field sits immediately after the array:

struct msg { char data[32]; unsigned long tag; };   /* tag sits right after data */

checked = (unsigned short)len;      /* only the low 16 bits survive   */
if (checked > sizeof m.data) { reject; }
read(0, m.data, len);               /* the copy uses len, not checked */

Do this. Three commands, exactly as written — the printf sends the letters into the program’s stdin:

cd ~/ierg4851/week6/after-class/01-int-truncation && make

printf 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA' | ./trunc 32
printf 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA' | ./trunc 65568
printf 'A' | ./trunc 65569

What you will see. The first two are both accepted, because the check only ever sees 32. The last line of each run is the tag field — watch it:

# ./trunc 32     -- 32 bytes copied: exactly fits, tag untouched
  len     = 32  (0x00000020)
  checked = 32  (0x0020)   <- this is the value the check sees
  accepted
  tag     = 0x1122334455667788   (started at 0x1122334455667788)

# ./trunc 65568  -- 40 bytes copied into a 32-byte array
  len     = 65568  (0x00010020)
  checked = 32  (0x0020)   <- this is the value the check sees
  accepted
  tag     = 0x4141414141414141   (started at 0x1122334455667788)

# ./trunc 65569  -- the low 16 bits are 33, so this one is caught
  len     = 65569  (0x00010021)
  checked = 33  (0x0021)   <- this is the value the check sees
  rejected

0x41 is 'A', and 0x4141414141414141 is eight of them. Your letters walked past the end of the 32-byte array and became the tag field. The check never saw them coming, because the check was looking at a 16-bit value while the copy used a 32-bit one.

E2. One NUL byte, one chunk header

The same kind of integer mistake, inside the heap. Two 0x20 chunks, one after the other. The buffer is exactly the usable size of its chunk — 24 bytes — and the guard permits a length of 24:

struct blk { char data[24]; };          /* sizeof 24 -> malloc(24) -> a 0x20 chunk */

if (len > sizeof a->data) { reject; }   /* 24 is allowed          */
memcpy(a->data, text, len);
a->data[len] = 0;                       /* ... but this needs 25  */

Do this. One command, one line of input:

cd ~/ierg4851/week6/after-class/02-off-by-null && make
printf '24\nABCDEFGHIJKLMNOPQRSTUVWX\n' | ./offby

What you will see. The program prints the next chunk’s header straight out of memory, before and after. (Your addresses will differ; the values are the point.)

a = 0x...2a0   (a's payload; usable size is 24)
b = 0x...2c0   (b's header starts at 0x...2b0 = b - 16)
  before:  b's header:  prev_size = 0x4141414141414141   size = 0x0000000000000021
  accepted: len = 24
  after:   b's header:  prev_size = 0x5857565554535251   size = 0x0000000000000000
  b's first bytes are now: "BBBBBBBB"

Three things to look at:

• size went from 0x21 to 0x0. The terminating NUL was written one byte past the end of a->data, and that byte is the first byte of the next chunk’s size field. Zeroing it zeroed the whole size. Chunk b no longer tells the allocator how big it is.
• 0x21 was two things. 0x20 is the chunk’s size, and the 1 was the PREV_INUSE flag from A1. The NUL destroyed both at once.
• prev_size changed too. It was 0x4141414141414141 before your input — those are a’s filler 'A's. That is allowed, because a was allocated 24 bytes but only 16 of them are a’s own payload; the other 8 are b’s prev_size. That is exactly the usable == chunksize - 8 idea from A1b, seen from the other side.