You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
user@LAPTOP-M65IV45R:~/binaryexploitation/level05_d$ file level05
level05: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.15, BuildID[sha1]=2cf47809a1a841f6990910071c09e6053e9f57ac, with debug_info, not stripped
Fusion VM:
fusion@fusion:~$ uname -a
Linux fusion 3.0.0-13-generic-pae #22-Ubuntu SMP Wed Nov 2 15:17:35 UTC 2011 i686 i686 i386 GNU/Linux
fusion@fusion:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 11.10
Release: 11.10
Codename: oneiric
fusion@fusion:~$ ldd --version
ldd (Ubuntu EGLIBC 2.13-20ubuntu5) 2.13
Host VM:
user@LAPTOP-M65IV45R:~/binaryexploitation/level05_d$ uname -a
Linux LAPTOP-M65IV45R 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 GNU/Linux
user@LAPTOP-M65IV45R:~/binaryexploitation/level05_d$ ldd --version
ldd (Debian GLIBC 2.31-13+deb11u5) 2.31
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
X86
X64
ARM
ARM64
MIPS
MIPS64
PPC
PPC64
RISCV
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 1234
Host VM:
user@LAPTOP-M65IV45R:~/binaryexploitation/level05_d$ gdb
0.00ms using Python engine 3.9
gef➤ file level05
Reading symbols from level05...
gef➤ gef-remote 192.168.56.113 1234
Reading /lib/i386-linux-gnu/libc.so.6 from remote target...
[... snip ... ]
Code:
0xb777c421 <__kernel_vsyscall+13> nop
0xb777c422 <__kernel_vsyscall+14> int 0x80
→ 0xb777c424 <__kernel_vsyscall+16> pop ebp
0xb777c425 <__kernel_vsyscall+17> pop edx
0xb777c426 <__kernel_vsyscall+18> pop ecx
0xb777c427 <__kernel_vsyscall+19> ret
0xb777c428 add BYTE PTR [esi], ch
0xb777c42a jae 0xb777c494
Threads:
[#0] Id 1, stopped 0xb777c424 in __kernel_vsyscall (), reason: SIGTRAP
Trace:
[#0] 0xb777c424 → __kernel_vsyscall()
[#1] 0xb76b73ce → poll()
[#2] 0xb779fa8d → fdtask(v=0x0)
[#3] 0xb77a1396 → taskstart(y=0xb9746110, x=0x0)
[#4] 0xb76315ab → makecontext()
[#5] 0xb9746110 → data16 fs je 0xb9746175
2. Interact with code
Connect to target binary and perform two commands which uses calloc and strdup to allocate memory. Perform this a couple of times
user@LAPTOP-M65IV45R:~$ nc 192.168.56.113 20005
** welcome to level05 **
isup CHUNK1garbagedata
isup CHUNK2garbagedata
isup CHUNK3garbagedata
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:
user@LAPTOP-M65IV45R:~/binaryexploitation/level05_d$ file a.out
a.out: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=84c2e6f3ea4145a586430172545fbc1d750c1af6, for GNU/Linux 3.2.0, with debug_info, not stripped
Reproduce the previous setup steps for LOCAL ENVIRONMENT 32 BIT.
Instead targeting a 64-bit compiled version.
Target binary:
user@LAPTOP-M65IV45R:~/binaryexploitation/level05_d$ file a64.out
a64.out: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=9efa6c2233190407fb27aefef0e577652c8a3fc1, for GNU/Linux 3.2.0, with debug_info, not stripped
The same commands are sent and the heap output works as expected.
Fruerlund
changed the title
[Bug] Unexpected results from heap commands when debugging.
[Bug] Unexpected results from heap commands when debugging 32 bit binaries.
Jul 13, 2023
@Fruerlund I'd like to look into this bug. Can you upload those binaries to this issue?
Also do you have the libc symbol installed? If not, you need to set the main_arena address using heap set-arena. Then gef should be able to recover the heap chunks. If you don't know the address you can try this
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 1234
Host 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: