1

I'm trying to understand heap exploitation better. Therefore, I compiled the following file: https://github.com/shellphish/how2heap/blob/master/glibc_2.25/fastbin_dup_into_stack.c

I have the newest libc. How can I debug the following file with an older version? I know I can try to compile it an older one, but it seems to me like a very daunting task. I tried to load an older libc by downloading one from libc.blukat.me with pwntools, but it doesn't see it.

edit: the target cpu arch is x86 64bit. Thank you!

3
  • Well, this is a tough one and you don't even mention the target CPU. Suppose you can find the original media for Fedora 26, that might work. A chroot and building glibc yourself could also be an option, but you seem reluctant to do that. If you are ready to tinker this could be worth a shot.
    – 0xC0000022L
    Sep 28 '20 at 19:59
  • Hi @0xC0000022L, I added the info, thanks. I'm quite surprised that it's so complicated. How do researchers inspect older versions?
    – anon
    Sep 28 '20 at 20:32
  • Researchers will usually not be afraid to build it from scratch. See, the issue is that even though you may be able to get a version that formally carries the version number 2.25, it stands to reason that - unless you happen to get the earliest available package for that distro - you will get something that is patched somehow. So building stuff from scratch is typically the easiest with your requirements. Projects like LFS, Yocto and Buildroot make it almost trivial to build complete systems (suitable for chroot) tailored to your needs.
    – 0xC0000022L
    Sep 28 '20 at 20:55
0

You probably want to set LD_LIBRARY_PATH to point to where you have the other libc version.

You may also need to rename it to be e.g. 'libc.so.6'. You can see the exact name that your binary loads with ldd.

$ ldd /bin/sh
    linux-vdso.so.1 =>  (0x00007fff107d8000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fde26974000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fde26f66000)

You can verify that your environment variable worked in the same way. For example, if you copy libc to /home/pwntools, you might see this:

$ LD_LIBRARY_PATH="$PWD" ldd /bin/sh
    linux-vdso.so.1 =>  (0x00007ffda30f5000)
    libc.so.6 => /home/pwntools/libc.so.6 (0x00007f7b26225000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f7b26817000)
1
  • Hi! thanks. I downloaded the ld of that version (2.44 9) and put it into the directory as well. When executing LD_LIBRARY_PATH="$PWD" ldd foo I receive a seg fault. Both of the files have necessary permissions. Do you have any idea why?
    – anon
    Sep 29 '20 at 12:49
0

libc versions are tied to the corresponding ld.so (dynamic linker) versions. You have a few options:

  • Run the program in a Docker container with an OS that corresponds to the target libc. (For example, docker run -it -v $(pwd):/run ubuntu:20.04 /run/binary). This has the advantage that if your binary depends on any other system libraries, you can get the right versions via apt or similar.
  • Extract both ld.so and libc.so from a compatible version or libc package (e.g. https://packages.ubuntu.com/focal/amd64/libc6/download) and run a command like LD_PRELOAD=./libc.so ./ld.so ./binary.

Note that if you use a libc without using the corresponding ld.so (for example, if you do LD_LIBRARY_PATH=. ./binary and the libc in the directory does not match your system ld.so), you will probably get segfaults or unexpected behaviour, as libc and ld.so use shared data structures that change between versions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.