[Bug] Unexpected results from heap commands when debugging 32 bit binaries. #961
Comments
Fruerlund
changed the title
|
@Fruerlund I'd like to look into this bug. Can you upload those binaries to this issue? |
|
@Fruerlund Ping? |
|
Hello, I happened to come across a similar issue and I think I've repeated / solved what @Fruerlund came across. I'm on Ubuntu 22.04 64-bit base and 32-bit cross, both libc symbols installed. I've built a basic hello world binary for both 32 and 64 bit. The "unexpected results", at least to me, is that on my 64 bit binary I have about 4 chunks listed in I found the fix was as simple as removing the zero chunk size stop condition in the GlibcChunk iterator. By commenting out the below two lines, it 'just worked'. if current_chunk.size == 0:
break I wonder if the assumption that the first chunk always contains a size isn't entirely accurate, at least on 32-bit? Before commenting out those lines: After: I'm happy to chuck in a PR but it's not much of a patch really, if that is the case! |
|
I don't remember my glibc malloc well anymore... Are chunks of size 0 legitimate? |
|
While I've seen it crash some older systems, I believe glibc allows it. See https://github.com/lattera/glibc/blob/master/malloc/malloc.c#L116
|
|
And in your repro, did you explicitly allocate a 0 byte buffer? If you break main, then log all malloc calls, do you see that size 0 buffer being allocated? With the check removed, it seems that I believe it may be true that we should not stop when we find a zero-sized chunk, but it's strange that we are seeing it only on 32 bit libc. Obviously, in the context of CTFs and heap bugs we are going to see heap corruption, but when that happens we obviously cannot expect to properly parse a corrupted heap, but I wonder if you were able to reproduce it legitimately. |
GEF+GDB version
Operating System
Linux 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 GNU/Linux
Describe the issue you encountered
Target binary:
Fusion VM:
Host VM:
During examination of heap chunks the heap commands works unexpectially and doesn't recognize any allocated chunks.
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.
Provide a step-by-step to reproduce your issue.
REMOTE ENVIRONMENT (32 BIT):
1. Setup environment.
Fusion VM:
fusion@fusion:~$ sudo gdbserver :1234 --attach 1424 [sudo] password for fusion: Attached; pid = 1424 Listening on port 1234Host VM:
2. Interact with code
3. Examine heap
LOCAL ENVIRONMENT (32 BIT):
In this setup I've ported the source code made the nessecary code adjusements and compiled the source code on my host VM using a newer versions of LIBC.
In this setup the binary is running locally on the host VM with the specifications shown earlier.
The same GDB setup is used, however skipping remote debug and attaching directly to the running binary using its PID. The interaction with the binary is identical to that of the remote.
Target binary:
LOCAL ENVIRONMENT (64 BIT)
Reproduce the previous setup steps for LOCAL ENVIRONMENT 32 BIT.
Instead targeting a 64-bit compiled version.
Target binary:
The same commands are sent and the heap output works as expected.
Minimalist test case
Use this field for a minimal code to compile and spot the issue:
You can also provide a Dockerfile if you prefer
Additional context?
Challenge found here: http://exploit.education/fusion/level05/
Image for fusion found here: http://exploit.education/downloads/
The text was updated successfully, but these errors were encountered: