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 ;-)
@jieyongma Could you tell me what is the procedure to assign severity levels to CVEs? This vulnerability, for example, has high severity score in NVD. I cannot agree, as the real security impact of this bug is low. The worst scenario I can think of is crashing user application. You must also force the user to use crafted file. Without address sanitizer there will not even be a crash in such case. How can it be considered high severity problem?
@bfabiszewski Please check the following URL: CVE: https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures NVD: https://en.wikipedia.org/wiki/National_Vulnerability_Database
As NVD mentioned on there website: "NVD Analysts use publicly available information to associate vector strings and CVSS scores. We also display any CVSS information provided within the CVE List from the CNA."
I believe there is someone in NVD(NVD Analysts) assign severity levels to CVEs in their database (NVD). And it's widely used by other parties.
For this vulnerability, their detail assessment information could be found at following URL:
https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?name=CVE-2022-1534&vector=AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H&version=3.1&source=NIST
@bfabiszewski You are welcome :-） Don't take the severity level too seriously. Maybe at the hacker's point of view, they could cause some serious problem by using this type of vulnerability (Buffer Over-read).
@jieyongma I always took it seriously. :) Now I see that the system is not reliable and misleading.