Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CANO=Ty3puYF=K=ZicQvBiVyXVUgt7UM5FBqLF_KZGNk+op42sQ@mail.gmail.com>
Date: Sat, 10 Sep 2016 21:00:11 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security <oss-security@...ts.openwall.com>
Subject: Possible CVE request for Redis docker container

So we have this:

https://github.com/dxa4481/Damn-Vulnerable-Redis-Container

I wanted to run it by the OSS-Security community first to gather other
points of view/feedback before going to the CVE board.

So:

1) Currently services that don't require auth don't get a CVE for that
specifically (e/g. memcached), so as long as it is clearly stated as such
(no auth supported, use something else to control access), however what
about implementations of these services (e.g. VM appliances, docker
containers) that don't explicitly warn, and fail to implement any
protection, should they continue to not get CVEs?

I'm inclined to say "it depends", e.g. if the appliance/container only
includes a vulnerable service (say a memcached container) and nothing else
then no CVE, but if a container/appliance is part of a larger composed
product (e.g. a webserver, web app and memcached), and it can result in a
security vulnerability then I would expect a CVE to be issued.


2) Services that are capable of authentication but do not have it enabled.
Same reasoning as above. On it's own you're expected to set it up properly.
If it's part of a larger composed product I would expect it to be setup
properly.

So in the case of https://github.com/dxa4481/Damn-Vulnerable-Redis-Container
 I'm inclined to say no CVE for the redis only container, but if a product
uses this container then it may be getting a CVE if it exposes it.

But then practically speaking we end up with N+1 CVEs for "X uses redis
container in insecure manner" rather then a single blanket CVE for "redis
container is insecure". So like I said, I'd like to get some community
feedback before I take this to the CVE board.

-- 

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

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.