Re: Reducing the attack surface caused by Berkeley DB...
Time to reply to myself again :)
I went silent in this thread since the end of January because I spent
time fuzzing 8 libraries + CLI front-ends of the DBM family, starting
with LMDB:
> > liblmdb* or libleveldb* are much less popular in popcon by_inst than
> > libdb, yeah...
> >
> >
> > Do we know whether LMDB, and other candidate databases for replacing
> > BDB, have received suitable hardening against data corruption and
> > fuzzing ?
> Well, now I know: some parts of LMDB have not received the appropriate
> amount of hardening against data corruption.
>
> A direct LMDB translation of the simple BDB fuzzing run I posted in
> Debian BTS #652036:
>
> # apt install lmdb-utils
> $ rm -f input*
> $ echo -e "key\nvalue" | mdb_load -T -n input
> $ zzuf -qcs 0:1000 -C 10 -U 3 mdb_dump -n -l input
> $ zzuf -qcs 0:1000 -C 10 -U 3 mdb_dump -n -a input
> $ zzuf -qcs 0:1000 -C 10 -U 3 mdb_stat -n -e -fff -r -a input
>
> yields an interesting assortment of SIGFPE, SIGABRT and SIGSEGV...
> That's under sid amd64, with lmdb-utils / liblmdb0 0.9.21-1, which
> packages the latest upstream release.
> I replaced the sources with the latest ones from
> https://github.com/LMDB/lmdb , since the commit logs mention e.g. "fix
> FIRST_DUP/LAST_DUP cursor bounds check". AFAICS, it changes the set of
> symbols, but not the outcome of zzuf... and unsurprisingly, afl-fuzz
> following a build with afl-clang-fast destroys both mdb_dump and
> mdb_stat within 2 seconds.
>
> Oh well... time to report the issues, after letting afl run for a
> little while longer, probably until tomorrow morning.
Last week-end, I published on oss-sec the fuzzer findings, subsequent
interaction (or lack thereof) with upstream maintainers, and fixes:
http://www.openwall.com/lists/oss-security/2018/06/17/1
Being closer to BDB and more scalable than the other DBs, and
maintained, LMDB is part of the solution to the insecurity of the
outdated versions of BDB everyone uses... despite being far from robust
against offline data corruption, at least for now.
Also, I started diving into BDB -> LMDB conversion for C/C++ code, using
lmdb.h, db.h and http://www.lmdb.tech/doc/starting.html .
I had a glance at the mocp TUI music player (moc package): it's not
popular, but it's the one which made me aware of BDB's intolerance to
data corruption, and also, the use of BDB in moc happens to be limited
to the single tags_cache.c file and the main BDB API functions (no
complex batching or fancy stuff), so moc should make for a gentle
BDB/LMDB learning curve. Of course, the devil might be in the details.
Bye,
Lionel.
Reply to: