|
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.