Hi Marco, On 1/26/18 1:46 AM, Marco d'Itri wrote: > On Jan 25, Lionel Debroux <lionel_debr...@yahoo.fr> wrote: > > Several days ago, jmm from the security team suggested that I start > > a discussion on debian-devel about Berkeley DB, which has known > > security issues, because doing so may enable finding a consensus on > > how to move > Can you clarify the threat model? I'll try to; admittedly, the threat model is less clear to me than the number of publicly known weaknesses in a source package unmaintained upstream (at least publicly), the ease of hanging or crashing the code with corrupted input, and to some extent, the mild ease of creating such corrupted input in non-fuzzing conditions (though it would probably have been somewhat fixed earlier if it were frequent enough) :)
> E.g. is libdb attackable by user-supplied data from the program using > it or do attacks require write access to the db files? Most attacks I can imagine require write access to the DB files, but I'm not convinced that most of the programs / libraries which use BDBs do it in a read-only fashion, if that is possible. As shown by the original reporter of #652036, BDB can (or could, at some point) be programmatically caused to corrupt a DB file in such a way that later opens, by e.g. a repair tool such as db_dump, causes an infinite loop. I'm obviously unqualified to tell whether any of the many callers of libdb can be locally, or remotely, caused to trigger such data corruption. Later, what got me interested in BDB as my first fuzzing target was DoS following external data corruption caused by forced power off on a laptop (<=> power outage for desktops, in theory), when launching `mocp` from the package of the same name. External data corruption could also infrequently occur on aging mass storage (non-backup transfers of BDBs are probably infrequent), and bite when restoring data, e.g. archived SVN repositories from the era before FSFS became recommended. I got that thought because having a peek at data from old backup tapes is relevant, once in every while, to some people I know. I'll grant that the data sets these persons are interested in are likely too old to be in a SVN in the first place, but you get the idea. Bye, Lionel.
