Crashes during parsing of malformed OSMX files

[retpoline]

Hi there,

During fuzz testing of the OSMX parsing there were a couple crashes discovered. Although these files only crash the apps, they could potentially be crafted further into security issues where a malformed OSMX file would be able compromise the process's memory through memory corruption, so hardening the code to prevent these kinds of bugs would be great.

You can download the crashing files in a zip from Ufile to debug and understand where the code is crashing.

Here's a snip of one of the crash logs.

Program received signal SIGSEGV, Segmentation fault.
mdb_xcursor_init1 (mc=0x7fffffffdd00, node=0x7efff767ffda) at mdb.c:7507
7507			mx->mx_db.md_pad = 0;

#0  mdb_xcursor_init1 (mc=0x7fffffffdd00, node=0x7efff767ffda) at mdb.c:7507
#1  mdb_cursor_set (mc=0x7fffffffdd00, key=0x7fffffffe0b0, 
    data=0x7fffffffe0a0, op=MDB_SET, exactp=0x7fffffffdcfc) at mdb.c:6142
#2  0x00000000005aceb5 in mdb_get (txn=<optimized out>, dbi=<optimized out>, 
    key=0x7fffffffe0b0, data=0x7fffffffe0a0) at mdb.c:5762
#3  0x000000000040fb30 in osmx::db::Metadata::get(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
#4  0x000000000040da0b in main ()

rax            0x0                 0
rbx            0x7fffffffdd00      140737488346368
rcx            0x7efff767ffff      139637832548351
rdx            0x1d                29
rsi            0x1000000000000     281474976710656
rdi            0x7efff767ffda      139637832548314
rbp            0x7fffffffdcfc      0x7fffffffdcfc
rsp            0x7fffffffdc90      0x7fffffffdc90
r8             0x7fffffffdcfc      140737488346364
r9             0x6c9a73            7117427
r10            0x6c9828            7116840
r11            0x7ffff7872be0      140737346218976
r12            0x7fffffffe0b0      140737488347312
r13            0x7efff767f000      139637832544256
r14            0xf                 15
r15            0x7fffffffe0a0      140737488347296
rip            0x5ad1ba            0x5ad1ba <mdb_cursor_set+762>
eflags         0x10206             [ PF IF RF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0

=> 0x5ad1ba <mdb_cursor_set+762>:	mov    %rsi,0x188(%rax)
   0x5ad1c1 <mdb_cursor_set+769>:	
    movaps 0x9aa78(%rip),%xmm0        # 0x647c40
   0x5ad1c8 <mdb_cursor_set+776>:	movups %xmm0,0x190(%rax)
   0x5ad1cf <mdb_cursor_set+783>:	movq   $0x0,0x1a0(%rax)

'exploitable' version 1.32
Linux ubuntu 5.4.0-48-generic #52-Ubuntu SMP Thu Sep 10 10:58:49 UTC 2020 x86_64
Signal si_signo: 11 Signal si_addr: 392
Nearby code:
   0x00000000005ad19e <+734>:	jne    0x5ad284 <mdb_cursor_set+964>
   0x00000000005ad1a4 <+740>:	movzx  edx,WORD PTR [rdi+0x6]
   0x00000000005ad1a8 <+744>:	lea    rcx,[rdi+rdx*1]
   0x00000000005ad1ac <+748>:	add    rcx,0x8
   0x00000000005ad1b0 <+752>:	movabs rsi,0x1000000000000
=> 0x00000000005ad1ba <+762>:	mov    QWORD PTR [rax+0x188],rsi
   0x00000000005ad1c1 <+769>:	movaps xmm0,XMMWORD PTR [rip+0x9aa78]        # 0x647c40
   0x00000000005ad1c8 <+776>:	movups XMMWORD PTR [rax+0x190],xmm0
   0x00000000005ad1cf <+783>:	mov    QWORD PTR [rax+0x1a0],0x0
   0x00000000005ad1da <+794>:	movzx  esi,WORD PTR [rdi+rdx*1+0x14]

Stack trace:
#  0 mdb_xcursor_init1 at 0x5ad1ba in OSMExpress/osmx
#  1 mdb_cursor_set at 0x5ad1ba in OSMExpress/osmx
#  2 mdb_get at 0x5aceb5 in OSMExpress/osmx
#  3 osmx::db::Metadata::get(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) at 0x40fb30 in OSMExpress/osmx
#  4 main at 0x40da0b in OSMExpress/osmx

Faulting frame: #  0 mdb_xcursor_init1 at 0x5ad1ba in OSMExpress/osmx
Description: Access violation near NULL on destination operand
Short description: DestAvNearNull (15/22)
Hash: 474dceedaab021c3f42b9dc0bd4ed041.474dceedaab021c3f42b9dc0bd4ed041
Exploitability Classification: PROBABLY_EXPLOITABLE
Explanation: The target crashed on an access violation at an address matching the destination operand of the instruction. This likely indicates a write access violation, which means the attacker may control write address and/or value. However, it there is a chance it could be a NULL dereference.
Other tags: AccessViolation (21/22)

Thanks!

[bdon]

@retpoline running osmx on untrusted .osmx file input seems like a nonstandard use case. Can you explain how the fuzz tester works? Considering an .osmx file is just an LMDB database, it seems like this parsing issue is relevant to any LMDB database? https://bugs.openldap.org/buglist.cgi?component=liblmdb&product=LMDB&resolution=---

[retpoline]

@bdon thanks for looking into this.

Well, in general file parsers should not crash on malformed filed and ideally should handle error conditions that would otherwise cause them to crash gracefully instead. The fuzz testing performed was to check if the parser would handle invalid files or crash when parsing them.

As far as parsing an untrusted file as a nonstandard use case, I'd say although osmx files are different file types than doc, jpeg or other types of files, we still expect to be able to open a word document and if it contains errors, Word says eg. "Invalid file content" instead of crashing or allowing the file contents to dictate control over process memory. So that's why its a good idea to fix crashes in such scenarios.

Hmm other parses that operate on LMDB databases may crash on malformed input as well and if so, should be hardened to gracefully exit with an error message instead of allowing memory to get corrupted as well.