heap commands no longer works properly when remote debugging
#646
Comments
|
Using gef's latest from dev, with a simple bin: $ cat > a.c << EOF
void main()
{
printf("main=%p\n", &main);
char *a = malloc(0x20);
char *b = malloc(0x20);
char *c = malloc(0x20);
memcpy(a, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", 0x20);
printf("a=%s\n", a);
__asm__("int3");
}
EOFgef works as expected: |
|
Sorry for taking so long with this. Finally getting back it. It seems this is only an issue when the binary is compiled for x86. |
|
@amlamarra @hugsy EDIT: I would suggest closing this issue. EDIT2: |
|
I'm still seeing the issue. I did get the latest version. All I'm doing to update is this: Does that look right? Same thing with other binaries, not just I also confirmed that going back to the 2021.01 release works as intended. |
|
Wow, there are two very weird things going on:
EDIT: sorry my mistake. you ARE on the newest commit EDIT2: also with the 2021.01 I get the same behaviour: sometimes it works, sometimes it doesn't. This is hard to figure out. I already tried different GEF commits, I tried three different host machines (ubuntu, arch linux and fedora), I tried changing the VM's |
|
What, exactly, is it that sometimes works and sometimes doesn't? I haven't noticed any other problems other than with the heap commands. I've also tried other versions of |
I think there are a few bugs I'm triggering in GEF combined with something fishy in the VM and I didn't consider them in the test setup I used for trying to understand your issue. The ones that are related to this issue are
I am not sure if you even used |
|
Here is my test setup for the not-working all of this is done inside the GEF working directory (so in the dir that is tracked with git): heap.c#include<stdlib.h>
#include<stdio.h>
int main() {
int* ptr = malloc(0x100);
printf("%p\n", ptr);
return 0;
}compile with gcc -m32 -oheap32 heap.cfind malloc manuallydebug file manually once to find first instruction after gdbscriptbisect.shgdb -q -x ./gdbscript ./heap32 | grep -i "chunk"start bisectinggit bisect start dev b93c1bd
git bisect run ./bisect.shThis works because |
|
I think here is the problem with x86 Lines 799 to 810 in 48a9fd7 If I'm not mistaken (but I very well could be) on x86 line 803 should be self.address = addr + 4 * self.ptrsize instead
|
|
I love What was the culprit commit? |
|
so, as I mentioned, I couldn't find a culprit commit for two reasons:
|
But it has. I was using it to work on the Fusion challenges. Then one day, I updated GEF and it stops working. |
|
Hm, then I don't understand. If i change the |
|
@amlamarra You could try to follow along my EDIT: i mean the whole post starting with
Also: If release |
|
I'm starting to run through your test setup, but one thing I noticed that I wanted to mention. Using According to the official docs, I expect to see something like this: However, what I'm seeing is: |
|
yes, this part of the other issue I talked about above (I opened issue #685 for it). It should be fixed soon. For now just use |
|
Another oddity. When debugging (locally) your Edit: |
|
Yes, for me on x86 , so 32bit, the What do you mean by this?
Does it also work for remotely debugging x86 binaries? on |
|
no, you can just leave your EDIT: |
|
This sort of discussion would be better done on our discord. |
|
ok, so the culprit commit for your issue is 55c4a6c I could only reproduce the issue with the Fusion 2 VM from exploit.education. This is my test setup to find that commit: SetupOn the Fusion 2 VMThe VM can be downloaded here. This script is used to automatically restart the gdbserver when it exits. # filename: gdbserver.sh
#!/bin/bash
while true; do
gdbserver --attach :1337 `pidof level05`BTW: I would recommend to use a host-only network for the VM so it is not exposed to the network. On the gdb machineCopy the Obviously replace the capitalized parts to match your environment. HOST:PORT should point to the fusion VM and the network should be setup so such a route does exist. PATH_TO_LOCAL_LEVEL05 should point to the previously download Now add this script (and make it executable with # filename: bisect.sh
#!/bin/bash
gdb -q -x ./gdbscript | grep -i "chunk"And finally you can start with the bisection: git bisect start dev 2021.01
git bisect run ./bisect.shResultThe resulting culprit commit is 55c4a6c Now we need to find out what in that commit caused the issue. EDIT: reverting just that single commit on |
|
In this specific testcase an exception is raised at self.nfree = int(self.next_free)T-he exception gets raised when trying to access either |
|
Lines 739 to 759 in 77889d8 Changing the class GlibcArena:
"""Glibc arena class
Ref: https://github.com/sploitfun/lsploits/blob/master/glibc/malloc/malloc.c#L1671"""
def __init__(self, addr, name=None):
self.__name = name or __gef_default_main_arena__
try:
arena = gdb.parse_and_eval(addr)
malloc_state_t = cached_lookup_type("struct malloc_state")
self.__arena = arena.cast(malloc_state_t)
self.__addr = int(arena.address)
except:
self.__arena = MallocStateStruct(addr)
self.__addr = self.__arena.addr
try:
self.top = int(self.top)
self.last_remainder = int(self.last_remainder)
self.sysmem = int(self.system_mem)
self.n = int(self.next)
self.nfree = int(self.next_free)
except gdb.error as e:
err(f"glibc arena: {e}")
returnI am not sure if and how that error should be handled properly so in this snippet I just print it out. Any ideas @hugsy ? This is how the error looks like at runtime: I can create a PR if this way of handling it is fine for now. (But I repeat: it does not solve all the problems with the heap command, like that EDIT: sorry, I updated the comment to include some more context without marking them as edits |
devbranch?gdb -nxthe closed ones) - and the PR?
Step 1: Describe your environment
versionin GEF.heapcommands works with the 2021.01 release.Step 2: Describe your problem
Steps to reproduce
root:godmodefor creds) and run gdbserver to attach to process:heap chunks|arenas|binscommands:heap chunkscommand works, butheap arenasdoes not:Minimalist test case
Not applicable as this is heap-related. I did, however, create my own test case.
Compiled with
gcc test.c -o test -g. This one does work.Observed Results
See above. Another thing to note is that when attaching to the "level05" process locally instead of remotely (using the latest dev version of GEF), nothing happens with the
heap chunkscommand. Thoughheap arenasseems to work.Expected results
The
heap chunksandheap arenascommands display information on the heap.Sorry, but I haven't tested this extensively with other binaries or architectures.
Traces
The text was updated successfully, but these errors were encountered: