[QUESTION] `hole-in-bin` subject

[Betzalel75]

hole-in-bin

Hi team,
I'm having an issue with the ex06 binary. I've tried several approaches to exploit the vulnerability, but every time I perform a memory overflow, I get a segfault on .

Additionally, based on the analysis I conducted on the disassembled code, the program checks the number of arguments passed as parameters. However, the program crashes on the next if it is executed with fewer than 3 arguments. Specifically:

If no arguments are passed, it crashes on the first <strcpy>.
If one argument is passed, it crashes on the second <strcpy>, and so on.

Could you please verify whether this binary file is actually exploitable?

[EldritchGriffin]

Hello @Betzalel75
can you please provide a walkthrough of the process that you took with attachments so i can investigate further.

[Betzalel75]

Hello @EldritchGriffin,
I am sending you my detailed report on the analysis and attempts to exploit a Use-After-Free vulnerability in the bin binary located at/opt/hole-in-bin/ex06.

Analysis and Exploitation Report of a Use-After-Free Vulnerability

1. Introduction

This report presents the analysis process and exploitation attempts of a Use-After-Free vulnerability found in the binary bin located at /opt/hole-in-bin/ex06. The objective was to trigger the execution of the winner function to solve the challenge.

2. Initial Analysis

./bin A B C D
dynamite failed?
./bin A B C
dynamite failed?
./bin A B
Segmentation fault
./bin A
Segmentation fault
./bin 
Segmentation fault

If the number of arguments is less than three, a segmentation fault occurs.

2.1 Binary Disassembly

After disassembling the binary, I identified key elements to solve the challenge. The main function at address 0x08048889:

1. Allocates three 0x20-byte buffers using malloc
2. Copies command-line arguments into these buffers using strcpy (which is vulnerable as it does not check boundaries)
3. Frees these buffers in reverse order of allocation

I also identified an interesting function named winner at address 0x08048864, which seems to be the target function to execute.

This binary is vulnerable to a "use-after-free" attack or "heap exploitation" due to the following reasons:

• It allocates three memory regions
• It copies data without verifying boundaries
• It frees these regions in reverse order

To further analyze, I searched for the winner function within the binary:

objdump -d ./bin | grep -A 20 "<winner>:"

Output:

08048864 <winner>:
 8048864:55                   push   %ebp
 8048865:89 e5                mov    %esp,%ebp
 8048867:83 ec 18             sub    $0x18,%esp
 804886a:c7 04 24 00 00 00 00 movl   $0x0,(%esp)
 8048871:e8 0a ff ff ff       call   8048780 <time@plt>
 8048876:ba 00 ac 04 08       mov    $0x804ac00,%edx
 804887b:89 44 24 04          mov    %eax,0x4(%esp)
 804887f:89 14 24             mov    %edx,(%esp)
 8048882:e8 d9 fe ff ff       call   8048760 <printf@plt>
 8048887:c9                   leave  
 8048888:c3                   ret    

2.2 Main Function Analysis

Examining the main function to understand program logic:

objdump -d ./bin | grep -A 50 "804889e:"

Findings:

• The program allocates three 32-byte memory blocks
• It copies command-line arguments into these blocks using strcpy
• It frees these blocks in reverse order
• A potential use-after-free vulnerability exists

2.3 Important String Analysis

strings ./bin | grep -i "that wasn"
strings ./bin | grep -i "failed"

Results:

that wasn't too bad now, was it?
dynamite failed?

2.4 Debugging with GDB

To further analyze the vulnerability, I used GDB to inspect the crash:

gdb -q --ex="set pagination off" --ex="run $(python -c 'print "A"*40') $(python -c 'print "B"*40') $(python -c 'print "C"*40')" --ex="x/16xw \$esp" --ex="bt" --ex="info registers" --ex=quit ./bin

Output:

Program received signal SIGSEGV, Segmentation fault.
0x080498b9 in free (mem=0x8be0030) at common/malloc.c:3631
3631    common/malloc.c: No such file or directory.
0xbfb510c0: 0xc67bbe0e  0x84848482  0x08be0050  0x00000fb0
0xbfb510d0: 0x0804b160  0x08be0028  0x41414140  0x00000004
0xbfb510e0: 0x49ff4168  0xb77be000  0x00000000  0x00000000
0xbfb510f0: 0xbfb51138  0xb77de500  0xffffffff  0x42424242

Registers analysis:

eax            0x49ff4168    1241465192
edx            0x8be0028     146669608
ebp            0xbfb51108    0xbfb51108
eip            0x80498b9     0x80498b9 <free+149>

The crash happens inside free() due to corrupted heap metadata. The presence of 0x41414140 suggests an overflow overwriting critical heap structures.

3. Understanding the Vulnerability

A use-after-free vulnerability occurs when:

• The program frees memory (free())
• The freed memory contains heap management metadata, including pointers
• These pointers can be overwritten with specific inputs
• By manipulating these metadata, execution flow can be redirected

4. Exploitation Attempts

4.1 First Attempt: Direct Address Injection

./bin $(python -c 'print "\x64\x88\x04\x08"') $(python -c 'print "\x64\x88\x04\x08"') $(python -c 'print "\x64\x88\x04\x08"')

4.2 Exploitation with Padding and Address Repetition

./bin $(python -c 'print "A"*16') $(python -c 'print "\x64\x88\x04\x08"*4') $(python -c 'print "C"*16')

5. Conclusion

Despite multiple exploitation attempts using different techniques, none successfully redirected execution to the winner function. The vulnerability remains challenging to exploit due to the specific heap management and execution flow constraints.

[EldritchGriffin]

hello @Betzalel75.
We thank you for your detailed report, it will help our team fix the issue.
we will update the exercise with an appropriate fix.

thanks !