Bug 1464032 - (CVE-2017-10140) CVE-2017-10140 libdb: Reads DB_CONFIG from the current working directory
CVE-2017-10140 libdb: Reads DB_CONFIG from the current working directory
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20170611,repor...
: Security
Depends On: 1464034 1464035 1471978 1464033
Blocks: 1464038
  Show dependency treegraph
 
Reported: 2017-06-22 06:17 EDT by Andrej Nemec
Modified: 2017-08-20 18:32 EDT (History)
52 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andrej Nemec 2017-06-22 06:17:52 EDT
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 06:18:44 EDT
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 08:30:18 EDT
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 10:21:53 EDT
(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 10:29:35 EDT
(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 02:03:29 EDT
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.

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