On 2/15/08, Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx> wrote: > Wow...that's a loadful of information. Thank you very much. And for vdso itself, I am now beginning to understand a little bit(or so it seemed????): First, the vdso32 is designed to prevent stack overflow. So that is why in the image map, the memory comes before the userspace stack. Stack grows toward lower memory address, but stack overflow usually grows toward higher address. So vDSO coming before the stack does not prevent overflow in that sense. But more in the sense that the vDSO slice is randomly allocated some memory address, and the stack comes after that. Therefore locating the address of the shellcode (in a stackover exploitation scenario) becomes very difficult. Take a look below to see the randomly located stack: /mnt/hd0/download>sleep 1000 & [1] 31867 /mnt/hd0/download>cat /proc/31867/maps 00541000-0055a000 r-xp 00000000 08:05 9540262 /lib/ld-2.5.so 0055a000-0055b000 r--p 00019000 08:05 9540262 /lib/ld-2.5.so 0055b000-0055c000 rw-p 0001a000 08:05 9540262 /lib/ld-2.5.so 0055e000-00698000 r-xp 00000000 08:05 9540263 /lib/libc-2.5.so 00698000-0069a000 r--p 0013a000 08:05 9540263 /lib/libc-2.5.so 0069a000-0069b000 rw-p 0013c000 08:05 9540263 /lib/libc-2.5.so 0069b000-0069e000 rw-p 0069b000 00:00 0 08048000-0804c000 r-xp 00000000 08:05 3071278 /bin/sleep 0804c000-0804e000 rw-p 00003000 08:05 3071278 /bin/sleep 0804e000-0806f000 rw-p 0804e000 00:00 0 [heap] b7d70000-b7f70000 r--p 00000000 08:05 7782483 /usr/lib/locale/locale-archive b7f70000-b7f72000 rw-p b7f70000 00:00 0 b7f87000-b7f88000 r-xp b7f87000 00:00 0 [vdso] bfa72000-bfa87000 rw-p bffeb000 00:00 0 [stack] /mnt/hd0/download>sleep 1000 & [2] 12133 /mnt/hd0/download>cat /proc/12133/maps 00541000-0055a000 r-xp 00000000 08:05 9540262 /lib/ld-2.5.so 0055a000-0055b000 r--p 00019000 08:05 9540262 /lib/ld-2.5.so 0055b000-0055c000 rw-p 0001a000 08:05 9540262 /lib/ld-2.5.so 0055e000-00698000 r-xp 00000000 08:05 9540263 /lib/libc-2.5.so 00698000-0069a000 r--p 0013a000 08:05 9540263 /lib/libc-2.5.so 0069a000-0069b000 rw-p 0013c000 08:05 9540263 /lib/libc-2.5.so 0069b000-0069e000 rw-p 0069b000 00:00 0 08048000-0804c000 r-xp 00000000 08:05 3071278 /bin/sleep 0804c000-0804e000 rw-p 00003000 08:05 3071278 /bin/sleep 0804e000-0806f000 rw-p 0804e000 00:00 0 [heap] b7cf6000-b7ef6000 r--p 00000000 08:05 7782483 /usr/lib/locale/locale-archive b7ef6000-b7ef8000 rw-p b7ef6000 00:00 0 b7f0d000-b7f0e000 r-xp b7f0d000 00:00 0 [vdso] bfaf9000-bfb0e000 rw-p bffeb000 00:00 0 [stack] But the libc is still fixed, so vuln like return-to-libc exploits can still worked. Solving it is via other method - http://lwn.net/Articles/190139/ is an alternative. Another type of problem is function recursion - it will then force the stack to grow towards the smaller mem region, but ultimately it will be block by the vdso, which is not editable, readonly from userspace. Is this vDSO readonly by userspace program, or is it not visible to them? WHen gdb is attach to the process, it indicated not accessible. It has to be readonly, so that it can host dangerous operation like sysenter, or int 80 etc. Is this correct? As for the functions inside vgetcpu.c and vclock_gettime.c, I cannot understand their purpose. Are they visible from userspace as well? -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
