Description: Read the flag from /home/orw/flag. Only open read write syscall are allowed to use. Tags:
Shellcode
Bypass SECCOMP
Reverse Engineering
1 2 3 4 5 6 7 8 9
[*] '/home/alter/lab/pwnable.tw/orw/orw' Arch: i386-32-little RELRO: Partial RELRO Stack: Canary found NX: NX unknown - GNU_STACK missing PIE: No PIE (0x8048000) Stack: Executable RWX: Has RWX segments Stripped: No
Let’s begin by looking at the checksec result: we know that the binary is 32-bit and has an executable stack. Now, let’s analyze it using IDA.
1 2 3 4 5 6 7 8
int __cdecl main(int argc, constchar **argv, constchar **envp) { orw_seccomp(); printf("Give my your shellcode:"); read(0, &shellcode, 0xC8u); ((void (*)(void))shellcode)(); return0; }
From this pseudo-code, we can observe the following:
Seccomp Setup: The function orw_seccomp() is called at the very beginning. This function sets up seccomp filters that restrict certain system calls. Although these filters are in place to limit dangerous operations, they may not block all actions, depending on the specific rules implemented.
Prompting for Shellcode: The program then prints the message Give my your shellcode:, asking the user to supply shellcode.
Reading the Shellcode: The read(0, &shellcode, 0xC8u); call reads up to 200 bytes (0xC8 in hexadecimal) from the standard input (file descriptor 0) and stores it in the buffer pointed to by shellcode.
Executing the Shellcode: Finally, the code casts the buffer to a function pointer and calls it - ((void (*)(void))shellcode)();. This means that if the supplied shellcode is valid, the program will jump to and execute that code.
Exploit Development
Using seccomp-tools, we can inspect the seccomp rules applied to the binary and determine which syscalls are allowed or blocked.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
$ seccomp-tools dump ./orw line CODE JT JF K ================================= 0000: 0x20 0x00 0x00 0x00000004 A = arch 0001: 0x15 0x00 0x09 0x40000003 if (A != ARCH_I386) goto 0011 0002: 0x20 0x00 0x00 0x00000000 A = sys_number 0003: 0x15 0x07 0x00 0x000000ad if (A == rt_sigreturn) goto 0011 0004: 0x15 0x06 0x00 0x00000077 if (A == sigreturn) goto 0011 0005: 0x15 0x05 0x00 0x000000fc if (A == exit_group) goto 0011 0006: 0x15 0x04 0x00 0x00000001 if (A == exit) goto 0011 0007: 0x15 0x03 0x00 0x00000005 if (A == open) goto 0011 0008: 0x15 0x02 0x00 0x00000003 if (A == read) goto 0011 0009: 0x15 0x01 0x00 0x00000004 if (A == write) goto 0011 0010: 0x06 0x00 0x00 0x00050026 return ERRNO(38) 0011: 0x06 0x00 0x00 0x7fff0000 return ALLOW
By analyzing this output, we can understand how seccomp is filtering system calls:
Architecture Check: The first two instructions verify that the binary is running on the ARCH_I386 (x86 32-bit) architecture. If the architecture does not match, execution jumps to instruction 0011, which allows the syscall.
Allowed Syscalls: The following syscalls are explicitly permitted:
rt_sigreturn (0xad)
sigreturn (0x77)
exit_group (0xfc)
exit (0x01)
open (0x05)
read (0x03)
write (0x04) If any of these syscalls are invoked, execution jumps to instruction 0011, which allows them.
From this, we can conclude that only basic file operations (open, read, and write) along with exit-related syscalls (exit, exit_group) are permitted. Syscalls such as mprotect, execve, or dup2 are blocked, which significantly limits our ability to perform certain types of privilege escalation or shell spawning via standard techniques.
Given these constraints, the most viable approach is to craft a shellcode that adheres to the seccomp rules. Since we can open a file, read its contents, and write the output, we can design our shellcode to read the contents of a target file (e.g., a flag) and print it to stdout.
Now, let’s write the shellcode that accomplishes this.
We encountered a SIGSEGV (Segmentation Fault) despite our shellcode appearing to be correct. The root cause of this issue lies in the memory protection settings—specifically, the address 0x804a060 does not have execution permissions.
As seen in the memory map, the region 0x804a000 - 0x804b000 is marked as rw-p (read-write), but it lacks execution (x) permissions. This means that while we can write shellcode to this address, we cannot execute it, resulting in a segmentation fault.
This issue often arises due to differences in kernel versions between our local machine and the target server. Some kernel versions enforce stricter memory protections by default, which may cause unexpected behavior during exploitation.
To resolve this and continue debugging, we can manually grant execution permissions to this memory region using the following command in GDB:
1
call (int)mprotect(0x804a000, 0x1000, 7)
Here, mprotect is used to change the permissions of the memory at 0x804a000 with a size of 0x1000 (one memory page) to 7 (PROT_READ | PROT_WRITE | PROT_EXEC). This allows our shellcode to execute properly.
Important: We must issue this command before orw_seccomp is called. Once orw_seccomp is executed, it will enforce seccomp filters that block the mprotect syscall, making it impossible to modify memory permissions later.
alter ^ Sol in ~/lab/pwnable.tw/orw $ ./xpl.py REMOTE chall.pwnable.tw 10001 [*] '/usr/lib/i386-linux-gnu/libc.so.6' Arch: i386-32-little RELRO: Partial RELRO Stack: Canary found NX: NX enabled PIE: PIE enabled SHSTK: Enabled IBT: Enabled [+] Opening connection to chall.pwnable.tw on port 10001: Done [*] Switching to interactive mode FLAG{sh3llc0ding_w1th_op3n_r34d_writ3}
