Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

LibreDWG "read_2004_compressed_section" function heap overflow vulnerability #249

Closed
yangjiageng opened this issue Jul 18, 2020 · 5 comments
Labels
fuzzing Intentional illegal input need info

Comments

@yangjiageng
Copy link

yangjiageng commented Jul 18, 2020

LibreDWG "read_2004_compressed_section" function heap overflow vulnerability
Description:
There is a heap overflow bug in "read_2004_compressed_section" function at libredwg-0.10.1/src/decode.c:2379:11
An attacker can exploit this bug to cause a Denial of Service (DoS) by submitting a dwg file.
This bug is caused by the following dangerous memcpy calling in read_2004_compressed_section function : line 2379
memcpy (&decomp[i * info->size], &dat->chain[address + es.fields.address + 32], info->size);
We used AddressSanitizer instrumented in LibreDWG and triggered this bug, the asan output as follows:
=================================================================
==1349==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x611000034440 at pc 0x0000004e80ac bp 0x7ffdbb939850 sp 0x7ffdbb939000
WRITE of size 192 at 0x611000034440 thread T0
#0 0x4e80ab in __asan_memcpy /root/Download/llvm-8.0.0.src/projects/compiler-rt-8.0.0.src/lib/asan/asan_interceptors_memintrinsics.cc:23
#1 0x7f84c6f4dbee in read_2004_compressed_section /root/libredwg-0.10.1/src/decode.c:2379:11
#2 0x7f84c6ea713d in read_2004_section_preview /root/libredwg-0.10.1/src/decode.c:2778:11
#3 0x7f84c6ea713d in decode_R2004 /root/libredwg-0.10.1/src/decode.c:2965
#4 0x7f84c6e80d4d in dwg_decode /root/libredwg-0.10.1/src/decode.c
#5 0x7f84c6e6122f in dwg_read_file /root/libredwg-0.10.1/src/dwg.c:211:11
#6 0x52c2fd in main /root/libredwg-0.10.1/programs/dwg2SVG.c:568:11
#7 0x7f84c5c89b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#8 0x41b209 in _start (/root/libredwg-0.10.1/programs/.libs/dwg2SVG+0x41b209)
 
0x611000034440 is located 0 bytes to the right of 256-byte region [0x611000034340,0x611000034440)
allocated by thread T0 here:
#0 0x4e97ff in calloc /root/Download/llvm-8.0.0.src/projects/compiler-rt-8.0.0.src/lib/asan/asan_malloc_linux.cc:155
#1 0x7f84c6f4ce62 in read_2004_compressed_section /root/libredwg-0.10.1/src/decode.c:2289:26
#2 0x7f84c6ea713d in read_2004_section_preview /root/libredwg-0.10.1/src/decode.c:2778:11
#3 0x7f84c6ea713d in decode_R2004 /root/libredwg-0.10.1/src/decode.c:2965
#4 0x7f84c6e80d4d in dwg_decode /root/libredwg-0.10.1/src/decode.c
#5 0x7f84c6e6122f in dwg_read_file /root/libredwg-0.10.1/src/dwg.c:211:11
#6 0x52c2fd in main /root/libredwg-0.10.1/programs/dwg2SVG.c:568:11
#7 0x7f84c5c89b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
 
SUMMARY: AddressSanitizer: heap-buffer-overflow /root/Download/llvm-8.0.0.src/projects/compiler-rt-8.0.0.src/lib/asan/asan_interceptors_memintrinsics.cc:23 in __asan_memcpy
Shadow bytes around the buggy address:
0x0c227fffe830: 00 00 00 00 00 fa fa fa fa fa fa fa fa fa fa fa
0x0c227fffe840: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c227fffe850: 00 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa
0x0c227fffe860: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
0x0c227fffe870: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c227fffe880: 00 00 00 00 00 00 00 00[fa]fa fa fa fa fa fa fa
0x0c227fffe890: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c227fffe8a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c227fffe8b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c227fffe8c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c227fffe8d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==1349==ABORTING

Then, we used GDB to debug this bug, the GDB outputs:
GDB
[----------------------------------registers-----------------------------------]
RAX: 0xffffffffc46 --> 0x0
RBX: 0x7fffffffd840 --> 0x62c000010200 --> 0x17022e0255800001
RCX: 0x7ffff6cd0ba4 (<read_2004_compressed_section+5060>: dec DWORD PTR [rbx+rcx*4+0x73])
RDX: 0xc0
RSI: 0x7ffff7e1ce60 --> 0x4164550000075130
RDI: 0x611000034400 --> 0x0
RBP: 0x7fffffffd9b0 --> 0x7fffffffdf90 --> 0x7fffffffe130 --> 0x7fffffffe350 --> 0x7fffffffe450 --> 0x532570 (<__libc_csu_init>: push r15)
RSP: 0x7fffffffd7e0 --> 0x41b58ab3
RIP: 0x7ffff6cd0bea (<read_2004_compressed_section+5130>: call 0x7ffff6be3460 __asan_memcpy@plt)
R8 : 0x1c37d
R9 : 0x1
R10: 0x0
R11: 0x611000034340 --> 0x666e497070410010
R12: 0x660
R13: 0xc340000026a --> 0x0
R14: 0x611000034400 --> 0x0
R15: 0x7ffff7e1ce60 --> 0x4164550000075130
EFLAGS: 0x206 (carry PARITY adjust zero sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
0x7ffff6cd0be0 <read_2004_compressed_section+5120>: mov rdi,r14
0x7ffff6cd0be3 <read_2004_compressed_section+5123>: mov rsi,r15
0x7ffff6cd0be6 <read_2004_compressed_section+5126>: mov rdx,QWORD PTR [rbx+0x68]
=> 0x7ffff6cd0bea <read_2004_compressed_section+5130>: call 0x7ffff6be3460 __asan_memcpy@plt
0x7ffff6cd0bef <read_2004_compressed_section+5135>: cmp BYTE PTR [r13+0x7fff8000],0x0
0x7ffff6cd0bf7 <read_2004_compressed_section+5143>: jne 0x7ffff6cd1377 <read_2004_compressed_section+7063>
0x7ffff6cd0bfd <read_2004_compressed_section+5149>: mov rdi,QWORD PTR [rbx+0xb8]
0x7ffff6cd0c04 <read_2004_compressed_section+5156>: mov rax,rdi
Guessed arguments:
arg[0]: 0x611000034400 --> 0x0
arg[1]: 0x7ffff7e1ce60 --> 0x4164550000075130
arg[2]: 0xc0
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffd7e0 --> 0x41b58ab3
0008| 0x7fffffffd7e8 --> 0x7ffff78e4d61 ("1 32 32 7 es:2253")
0016| 0x7fffffffd7f0 --> 0x7ffff6ccf7e0 (<read_2004_compressed_section>: push rbp)
0024| 0x7fffffffd7f8 --> 0x7fffffffdac0 --> 0x110c
0032| 0x7fffffffd800 --> 0xa4163043b --> 0x0
0040| 0x7fffffffd808 --> 0xa000000080 --> 0x0
0048| 0x7fffffffd810 --> 0x80
0056| 0x7fffffffd818 --> 0x7a9012f11adc178b
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
 
Breakpoint 3, 0x00007ffff6cd0bea in read_2004_compressed_section (dat=0x7fffffffe230, dwg=, sec_dat=0x7fffffffd9e0, section_type=0x1) at decode.c:2379
2379 memcpy (&decomp[i * info->size],
gdb-peda$ c
Continuing.
=================================================================
==3250==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x611000034440 at pc 0x0000004e80ac bp 0x7fffffffd7d0 sp 0x7fffffffcf80
WRITE of size 192 at 0x611000034440 thread T0
[New process 3276]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
process 3276 is executing new program: /opt/llvm/bin/llvm-symbolizer
Error in re-setting breakpoint 2: No symbol table is loaded. Use the "file" command.
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x52c2f9
Cannot insert breakpoint 3.
Cannot access memory at address 0x7ffff6cd0bea

We ensured there is a heap overflow vulnerability because of the dangerous using of memcpy function, attacker can use this bug to finish a DoS attack.

You can reproduce this heap overflow vulnerability by the follow step:
./dwg2SVG PoC_libreDWG_heapoverflow_read_2004_compressed_section_line2379

@rurban
Copy link
Contributor

rurban commented Jul 18, 2020

See my comments on #248.
Only interesting would by fuzzer cases with master, as this will be released soon.

@rurban rurban added the fuzzing Intentional illegal input label Jul 18, 2020
@attritionorg
Copy link

Dupe to #183 I believe.

@rurban
Copy link
Contributor

rurban commented Jul 20, 2020

Hi @yangjiageng, Is there a reproducer PoC or should we close it?

@yangjiageng
Copy link
Author

This is the PoC.
PoC
But this bug has been fixed in master.

@rurban
Copy link
Contributor

rurban commented Jul 21, 2020

Thanks, I'll add it to my fuzzing testcases

@rurban rurban closed this as completed Jul 21, 2020
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
fuzzing Intentional illegal input need info
Projects
None yet
Development

No branches or pull requests

3 participants