Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 29 May 2014 02:56:42 -0400 (EDT)
Subject: Re: CVE-2014-0234 Installer: OpenShift Enterprise: default password creation

Hash: SHA1

> This is to notify the community that Red Hat has fixed  CVE-2014-0234
> Installer: OpenShift Enterprise: default password creation.

Can you clarify the scope of this CVE? says:

  CVE-2014-0234 OpenShift Enterprise openshift-origin-broker: default password creation

  The OpenShift Enterprise openshift-origin-broker configures a default password:


  Please note that the optional installer also did this previously:

For the script, we think you might mean something like
(this isn't really the right branch):

in which, possibly, the scope of the CVE is both:




but not


which has a different type of issue?

Possibly a more important question is the status of
MONGO_PASSWORD="mooo" - there's no "mooo" anywhere in
4339020c62e43fa16f2145d46636f7dc0e26327f. Instead, "mooo" apparently
comes from:

and is not yet fixed in that copy of the code.

So, we could potentially model this as:

  1. "different affected versions" in the sense that if someone wasn't
     using Red Hat's RPMs and instead updated everything from after seeing RHSA-2014:0487-1, they would have the
     4339020c62e43fa16f2145d46636f7dc0e26327f patches but would still
     have "mooo"


  2. "different affected products" in the sense that "mooo" is a
     vulnerability affecting the OpenShift Enterprise product (or
     specifically the openshift/origin-server package), whereas
     4339020c62e43fa16f2145d46636f7dc0e26327f is a non-identical
     vulnerability in the openshift/openshift-extras package

In other words, we don't know the interpretation in which "mooo" and
4339020c62e43fa16f2145d46636f7dc0e26327f end up with the same CVE ID.

(We didn't try to determine why your quoted broker.conf has two
MONGO_PASSWORD= lines, but
has only one MONGO_PASSWORD= line.)

> I also wanted to open up a discussion as well, what counts as shipped
> software, e.g. more and more projects have a bash script linked off
> the front page/install page, my take on this is if it's "officially"
> endorsed by the project and prominent it should probably count as
> "shipped" software and get a CVE (assuming it has a security flaw),
> but we shouldn't assign CVE's to every instance of install scripts

The pre-4339020c62e43fa16f2145d46636f7dc0e26327f unpatched code such as
contained this comment:

  # While this script serves as a good example script for installing a
  # single host, it is not comprehensive nor robust enough to be considered
  # a proper enterprise installer on its own. Production installations will
  # typically require significant adaptations or an entirely different
  # method of installation. Please adapt it to your needs.

Typically, if a piece of code is simply not intended to be used as-is,
it can't have CVE assignments for its vulnerabilities. The situation
would be different if (for example) any Linux distribution shipped with conflicting documentation, or executed

This might mean that the best scope of CVE-2014-0234 is only the
default broker.conf file (because that issue is known to actually
affect the Red Hat OpenShift Enterprise 2 product).

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.