Bug 1464032 (CVE-2017-10140) - CVE-2017-10140 libdb: Reads DB_CONFIG from the current working directory
Summary: CVE-2017-10140 libdb: Reads DB_CONFIG from the current working directory
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2017-10140
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1464033 1464034 1464035 1471978
Blocks: 1464038
TreeView+ depends on / blocked
 
Reported: 2017-06-22 10:17 UTC by Andrej Nemec
Modified: 2023-09-07 18:53 UTC (History)
50 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-08 03:15:30 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:0366 0 None None None 2019-02-18 16:55:39 UTC

Description Andrej Nemec 2017-06-22 10:17:52 UTC
It was found that Berkeley DB reads the DB_CONFIG configuration file from the current working directory by default. This happens when calling db_create() with dbenv=NULL; or using the dbm_open() function. 

References:

http://seclists.org/oss-sec/2017/q2/452
http://www.postfix.org/announcements/postfix-3.2.2.html

Proposed patch:

http://seclists.org/oss-sec/2017/q2/475

Comment 1 Andrej Nemec 2017-06-22 10:18:44 UTC
Created libdb tracking bugs for this issue:

Affects: fedora-all [bug 1464033]


Created libdb4 tracking bugs for this issue:

Affects: fedora-all [bug 1464035]


Created postfix tracking bugs for this issue:

Affects: fedora-all [bug 1464034]

Comment 2 Petr Kubat 2017-06-22 12:30:18 UTC
Easy to reproduce with a simple application that creates and opens a database without explicitly specifying a database environment - a private (in-memory) environment is created instead.

The patch makes sense to me (functionality-wise, the actual change would be better located elsewhere), libdb should not try parsing DB_HOME/DB_CONFIG if DB_HOME is not set.

Will touch base with upstream first to see if they have any plans for fixing this yet.

Comment 3 Stefan Cornelius 2017-07-10 14:21:53 UTC
(In reply to Petr Kubat from comment #2)
> Easy to reproduce with a simple application that creates and opens a
> database without explicitly specifying a database environment - a private
> (in-memory) environment is created instead.
> 
> The patch makes sense to me (functionality-wise, the actual change would be
> better located elsewhere), libdb should not try parsing DB_HOME/DB_CONFIG if
> DB_HOME is not set.
> 
> Will touch base with upstream first to see if they have any plans for fixing
> this yet.

Any response so far?

Comment 4 Petr Kubat 2017-07-10 14:29:35 UTC
(In reply to Stefan Cornelius from comment #3)
> Any response so far?

Nothing other that they see it as an issue themselves and that they will sent us the patch once they have it fixed.

I have provided them with the reproducer I used and the downstream patch I have hotfixed the issue with so hopefully this should not take long.

Comment 9 Petr Kubat 2017-08-17 06:03:29 UTC
libdb upstream got back to me today saying they are ok with the patch I sent them (and use for our version of libdb) and that we should keep on using it.

Comment 12 Andrej Nemec 2018-05-14 11:59:05 UTC
Statement:

This issue affects the versions of libdb as shipped with Red Hat Satellite 6.0, 6.1 and 6.2. This package no longer ships with Satellite 6.3. Red Hat Product Security has rated this issue as having security impact of Moderate. A future update may address this issue. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.

Comment 13 errata-xmlrpc 2019-02-18 16:55:37 UTC
This issue has been addressed in the following products:

  Red Hat JBoss Core Services

Via RHSA-2019:0366 https://access.redhat.com/errata/RHSA-2019:0366

Comment 16 Stefan Cornelius 2020-04-14 10:38:15 UTC
Mitigation:

Do not use an application using libdb if an untrusted user can create a DB_CONFIG file in its working directory.


Note You need to log in before you can comment on or make changes to this bug.