gef icon indicating copy to clipboard operation
gef copied to clipboard

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

Open MrNbaYoh opened this issue 1 year ago • 5 comments

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

  • [ ] X86
  • [ ] X64
  • [ ] ARM
  • [ ] ARM64
  • [ ] MIPS
  • [ ] MIPS64
  • [ ] PPC
  • [ ] PPC64
  • [ ] RISCV

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

MrNbaYoh avatar Jan 25 '24 17:01 MrNbaYoh

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.

hugsy avatar Jan 26 '24 22:01 hugsy

@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.

pnck avatar Feb 04 '24 12:02 pnck

@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.

hugsy avatar Feb 04 '24 22:02 hugsy

@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

pnck avatar Feb 05 '24 06:02 pnck

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!

hugsy avatar Feb 05 '24 17:02 hugsy