hugsy / gef

GEF (GDB Enhanced Features) - a modern experience for GDB with advanced debugging capabilities for exploit devs & reverse engineers on Linux
https://hugsy.github.io/gef
MIT License
6.82k stars 721 forks source link

[Bug] Missing update of local `/proc/{pid}/maps` in remote session when new shared library is loaded #1057

Open MrNbaYoh opened 7 months ago

MrNbaYoh commented 7 months ago

GEF+GDB version

GDB: 13.2
GDB-Python: 3.11

Operating System

Manjaro Linux

Describe the issue you encountered

When a program in a remote session loads additional shared library after it started, the remote_objfile_event_handler: https://github.com/hugsy/gef/blob/570cc039c2ca258e7e49e0ad3d076132e8fc0444/gef.py#L11246-L11258 downloads the shared library from the remote and store it in the local folder. However, it does not update the local /proc/{pid}/maps file, leading to wrong vmmap outputs (and maybe other erroneous results).

Do you read the docs and look at previously closed issues/PRs for similar cases?

Yes

Architecture impacted

Describe your issue. Without a proper reproduction step-by-step, your issue will be ignored.

  1. Start a remote debugging session on a program that loads additional shared libraries with dlopen for example.
  2. Run the program and tries vmmap, the additional shared library won't show in the output.

Minimalist test case

No response

Additional context?

No response

hugsy commented 7 months ago

Which gef version are you using?

I cannot reproduce: it works well with this

cat meh.c << EOF
#include <stdio.h>
#include <dlfcn.h>
int main()
{
        __asm__("int3");
        void** handle = dlopen("/usr/local/lib/libkeystone.so.0", RTLD_NOW);
        printf("handle = %p -> %p\n", handle, *handle);
        __asm__("int3");
        dlclose(handle);
        __asm__("int3");
        return 0;
}
EOF

and

make meh
gdbserver localhost:1234 ./meh

on start, no libkeystone image

but on the 2nd int3 libkeystone shows image

If you think there is a bug, provide a detail step-by-step.

pnck commented 7 months ago

@hugsy Hi, I might encounter a similar problem, but I'm not sure whether it is a bug. Have you tried printing the vmmap for a remote process attached by gdbserver? I'm wondering if gef updates the mapping when the remote target is loading new libs.

hugsy commented 7 months ago

@pnck See the comment above. It works well. Provide a step-by-step to reproduce reliably from the main version if you think there's a bug. Otherwise I'll close the issue.

pnck commented 7 months ago

@hugsy Sorry I didn't read carefully.

I tried a couple of versions and see it seems fixed on the main branch.

I can reproduce with docker on the 2024.01 tagged version, which is likely the version I downloaded. (I remember I manually downloaded it from somewhere, probably the release page.)

reproduce on the older version:

  • docker run --rm -it --privileged -p1234:1234 --name tmp ubuntu:22.04
  • (inside docker) apt update && apt install build-essential gdbserver
  • build a minimal program: printf '#include<stdio.h>\nmain(){return 0;}' | gcc -xc -
  • attach: gdbserver :1234 a.out
  • connect the gdbserver from outside docker
  • tb main; c
  • vmmap doesn't show libc
hugsy commented 7 months ago

Thanks @pnck that's much more useful! I can reproduce the bug now on 2024.01, and I'm fairly sure this bug was killed with many others in #1046 Since I can reproduce it, I'll be adding some non-regression tests so we're able to catch those in the future.

Since it's fixed in main and already many more bugs were fixed in there too, we will probably create another release very soon, including those changes. So for now please keep using main.

Cheers!