Web lists-archives.com

Re: Reducing the attack surface caused by Berkeley DB...

On Thursday, January 25, 2018 11:59:06 PM Lionel Debroux wrote:
> Hi,
> 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
> away from it in Debian (which is hard). So here's a post :)
> Please keep me CC'ed, I'm not subscribed to debian-devel.
> Oracle Berkeley DB [1] "is a family of embedded key-value database
> libraries providing scalable high-performance data management services
> to applications. The Berkeley DB products use simple function-call APIs
> for data access and management.".
> In practice, Berkeley DB is a core component of most *nix distros.
> Debian popcon indicates that libdb5.3 is installed on ~80% of the
> computers which report to popcon.
> Two generations of Berkeley DB are relevant here:
> * BDB < 6.0 are under the original Sleepycat license; they're
> unmaintained, and unfixed security issues have been known for years
> (e.g. [2]: the library can corrupt a DB in such a way that salvaging it
> yields an infinite loop; disk corruption can also cause infinite loops);
> * the 6.x series contains fixes for 44 security issues with CVE numbers
> since 2015 [3][4][5] (most are complete DoS); however, the license was
> switched to AGPLv3, so it's unsuitable for broadly replacing the 5.x
> series (clearly, most projects are not going to switch to a compatible
> license) or backporting security fixes to the 5.x series.
> We can see that we've got a problem here. Absent an unlikely change of
> heart from Oracle, reducing the attack surface (which is arguably a
> worthwhile goal in general) caused by libdb 5.x would seem to require
> reducing, and eventually eliminating, usage of that library...
> While there might be a bit of low-hanging fruit, e.g. packages which
> * enable BDB support despite hardly anybody using it (so it might go
> away without too many complaints ?);
> * depend on BDB but are unmaintained upstream and hardly used downstream
> (so they might be removed from the archive without annoying users ?);
> * will switch to an AGPLv3-compatible license and be able to depend on
> (and require packaging of) libdb 6.x without undesirable side effects on
> the ecosystem
> the vast majority of the ~170 reverse dependencies of libdb5.3 listed by
> `apt-cache rdepends libdb5.3` on sid will require (much) more work to
> get rid of that dependency, with impact on backwards compatibility...
> Among those packages are:
> libperl* libpython2.7* libpython3.* php5-cli
> libsvn* libaprutil*
> reprepro apt-utils librpm*
> postfix exim4-base opensmtpd sendmail-bin claws-mail*
> libpam-modules 389-ds-base slapd
> memcachedb squid sks
> Headaches for both upstreams (e.g. making libdb usage more optional,
> finding and adding support for replacements, making upgrade code) and
> distros (e.g. adjusting packaging and maybe policy, coping with
> upgrades) will ensue... even without attempting backports to older
> upstream releases or older distros.
> The fact that many FLOSS developers and packagers do it on their spare
> time won't help.
> ---
> Do you think we should start the journey of getting rid of libdb5.3 at a
> wide scale ? And if so, how to optimize resource usage in general ? :)
> ---

Ultimately BDB is a dead end for non-AGPL projects.  So my answer to your 
first question is a definite yes.

I'd like to know what the preferred replacement is.  I maintain a few less 
heavily used packages that use libdb5.3 and I need to know what to tell 
upstream they should port to.  I don't know enough to have a real technical 
opinion.  Is lmdb the general solution?

As far as postfix goes (which I also co-maintain) that is a two release cycle 
project (it's complicated, but upgrades don't work otherwise - if anyone cares 
see what we did for postfix-sqlite.  It's no problem to switch to a difference 
default map type, but it'd be nice if we could switch it once to something 
that was otherwise already likely to be installed.

Scott K

Attachment: signature.asc
Description: This is a digitally signed message part.