Heap use after free in the free_element_list function
danielpyon opened this issue · 6 comments
Problem Description
Note: I am aware that this project is unmaintained. However, I am still opening this issue to follow CVE's guidelines for EOL software.
There is a heap use after free in the free_element_list function when the parser handles a specially crafted Markdown file. Here is a minimized proof-of-concept Markdown file that triggers the bug: min_heap_uaf.md. The output is as follows:
=================================================================
==400541==ERROR: AddressSanitizer: heap-use-after-free on address 0x6030000001a8 at pc 0x0000005de092 bp 0x7fffffffe100 sp 0x7fffffffe0f8
READ of size 8 at 0x6030000001a8 thread T0
#0 0x5de091 in free_element_list /home/sanic/peg-markdown/parsing_functions.c:25:21
#1 0x5ddfcb in free_element_list /home/sanic/peg-markdown/parsing_functions.c:28:13
#2 0x5ddfcb in free_element_list /home/sanic/peg-markdown/parsing_functions.c:28:13
#3 0x5dca5b in markdown_to_g_string /home/sanic/peg-markdown/markdown_lib.c:165:5
#4 0x5dce84 in markdown_to_string /home/sanic/peg-markdown/markdown_lib.c:175:11
#5 0x4c4d06 in main /home/sanic/peg-markdown/markdown.c:180:11
#6 0x7ffff7b25082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
#7 0x41c50d in _start (/home/sanic/peg-markdown/markdown+0x41c50d)
0x6030000001a8 is located 24 bytes inside of 32-byte region [0x603000000190,0x6030000001b0)
freed by thread T0 here:
#0 0x4949cd in free (/home/sanic/peg-markdown/markdown+0x4949cd)
#1 0x5ddfd3 in free_element_list /home/sanic/peg-markdown/parsing_functions.c:31:9
previously allocated by thread T0 here:
#0 0x494c4d in malloc (/home/sanic/peg-markdown/markdown+0x494c4d)
#1 0x5dd447 in mk_element /home/sanic/peg-markdown/utility_functions.c:75:23
#2 0x5dd447 in mk_str_from_list /home/sanic/peg-markdown/utility_functions.c:99:14
SUMMARY: AddressSanitizer: heap-use-after-free /home/sanic/peg-markdown/parsing_functions.c:25:21 in free_element_list
Shadow bytes around the buggy address:
0x0c067fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c067fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c067fff8000: fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa fd fd
0x0c067fff8010: fd fa fa fa fd fd fd fd fa fa fd fd fd fd fa fa
0x0c067fff8020: 00 00 00 00 fa fa fd fd fd fd fa fa fd fd fd fd
=>0x0c067fff8030: fa fa fd fd fd[fd]fa fa 00 00 00 00 fa fa 00 00
0x0c067fff8040: 00 00 fa fa fd fd fd fd fa fa 00 00 00 00 fa fa
0x0c067fff8050: 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00
0x0c067fff8060: fa fa fd fd fd fd fa fa fd fd fd fd fa fa 00 00
0x0c067fff8070: 00 00 fa fa 00 00 00 00 fa fa fd fd fd fd fa fa
0x0c067fff8080: fd fd fd fd fa fa 00 00 00 00 fa fa 00 00 00 00
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
==400541==ABORTING
Reproduction Steps
- Compile the project using ASAN (Address Sanitizer). For example,
CC=afl-clang-fast AFL_USE_ASAN=1 make. - Run
./markdown -x min_heap_uaf.md(use the proof-of-concept file attached to this report). - Observe the heap use after free in the output.
did you request a CVE ID for this @danielpyon
@attritionorg Yes, I filed for an EOL CVE last week. Unfortunately, there has been no response so far.
For third-party tracking purposes, can you please share that ID? Thanks!
@attritionorg I don't think I've been assigned an ID yet, but I will share it once I get one.
-
CVE-2023-41458 (use after free)
-
CVE-2023-41459 (stack overflow)
-
CVE-2023-41460 (heap buffer overflow)
-
CVE-2023-41461 (null pointer dereference)
Excellent, thank you @danielpyon!