Buffer Over-read at parse_rawml.c:1416 in bfabiszewski/libmobi
Reported on
Apr 25th 2022
Description
Heap-based Buffer Overflow at parse_rawml.c:1416
Build
git clone https://github.com/bfabiszewski/libmobi.git
cd libmobi
export CFLAGS="-g -O0 -lpthread -fsanitize=address"
export CXXFLAGS="-g -O0 -lpthread -fsanitize=address"
export LDFLAGS="-fsanitize=address"
./autogen.sh
./configure --disable-shared
make
POC
./tools/mobitool -e -o ./tmp/ ./poc.mobi
Asan
Title: Libmobi sample file
Author: Bartek Fabiszewski
Subject: Dictionaries
Language: pl (utf8)
Dictionary: pl => en
__
Mobi version: 7
Creator software: kindlegen 2.9.0 (linux)
Reconstructing source resources...
=================================================================
==1088449==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x610000000160 at pc 0x0000004f8d38 bp 0x7fffffffb4f0 sp 0x7fffffffb4e8
READ of size 8 at 0x610000000160 thread T0
#0 0x4f8d37 in mobi_reconstruct_infl /home/fuzz/libmobi/src/parse_rawml.c:1416:77
#1 0x4fabbc in mobi_reconstruct_orth /home/fuzz/libmobi/src/parse_rawml.c:1578:23
#2 0x4fd1fb in mobi_reconstruct_links_kf7 /home/fuzz/libmobi/src/parse_rawml.c:1796:15
#3 0x4fd916 in mobi_reconstruct_links /home/fuzz/libmobi/src/parse_rawml.c:1845:15
#4 0x5011d3 in mobi_parse_rawml_opt /home/fuzz/libmobi/src/parse_rawml.c:2149:15
#5 0x4ff78f in mobi_parse_rawml /home/fuzz/libmobi/src/parse_rawml.c:2005:12
#6 0x4c98d4 in loadfilename /home/fuzz/libmobi/tools/mobitool.c:852:20
#7 0x4c8b36 in main /home/fuzz/libmobi/tools/mobitool.c:1051:11
#8 0x7ffff7a7a0b2 in __libc_start_main /build/glibc-sMfBJT/glibc-2.31/csu/../csu/libc-start.c:308:16
#9 0x41d57d in _start (/home/fuzz/libmobi/tools/mobitool+0x41d57d)
Address 0x610000000160 is a wild pointer.
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/fuzz/libmobi/src/parse_rawml.c:1416:77 in mobi_reconstruct_infl
Shadow bytes around the buggy address:
0x0c207fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c207fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c207fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c207fff8000: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
0x0c207fff8010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c207fff8020: fa fa fa fa fa fa fa fa fa fa fa fa[fa]fa fa fa
0x0c207fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c207fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c207fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c207fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c207fff8070: 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
==1088449==ABORTING
Impact
The bug causes the program reads data past the end of the intented buffer. Typically, this can allow attackers to read sensitive information from other memory locations or cause a crash.
@jieyongma Recently I've received multiple bug reports from different researchers fuzzing libmobi. Is there any coordinated project aiming at fuzzing the library? I am asking because I would like to know whether I should still wait for new reports to come or the fuzzing is done and I can publish new release. Do you have any idea? Thanks for your efforts to secure libmobi!
@bfabiszewski AFAIK, there is no coordinated project aiming at fuzzing the library. There is no more crash report when I fuzz the library last week. Maybe I will give it another try someday later.
@bfabiszewski It's like fishing, if I saw someone caught a fish in a pond, I will definitely gave it a try ;-)