Date: Thu, 28 Jul 2016 12:22:20 -0400 (EDT) From: cve-assign@...re.org To: carnil@...ian.org Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE Request: redis: World readable .rediscli_history -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > https://bugs.debian.org/832460 >> redis-cli stores its history in ~/.rediscli_history, this file is >> created with permissions 0644. Home folders are world readable as well >> in debian, so any user can access other users' redis history, including >> AUTH commands, which include credentials. >> >> I've contacted upstream on 2016-05-30 without any reaction at all and >> discovered this bug was first reported 3 years ago, still unfixed. >> @RedisLabs keeps referring to their paid support on twitter. >> >> Demo: `cat /home/*/.rediscli_history` > Upstream report: https://github.com/antirez/redis/issues/3284 >>> https://github.com/antirez/redis/pull/3322 >>> https://github.com/antirez/redis/pull/1418 > Could you please assign a CVE for this issue in redis? As far as we can tell, this is being presented as a vulnerability in Redis, not a vulnerability in Linenoise. https://github.com/antirez/linenoise/blob/master/README.markdown says "A minimal, zero-config, BSD licensed, readline replacement used in Redis, MongoDB, and Android." Because it has a "minimal" design goal, it seems reasonable to argue that the linenoiseHistorySave function itself should not be making umask changes, because it cannot know whether history elements are potentially sensitive information within an arbitrary application that uses Linenoise. Also, the "History" section of README.markdown says "Linenoise has direct support for persisting the history into an history file. The functions linenoiseHistorySave and linenoiseHistoryLoad do just that. Both functions return -1 on error and 0 on success." It does not offer any guidance about whether this is typically safe. Admittedly, there is a counterargument that command history is always sensitive information, and that the design of the linenoiseHistorySave function is fundamentally wrong. We are not currently using that perspective for CVE ID assignments. (Also, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832460#20 suggests that there isn't a huge amount of affected code.) Use CVE-2013-7458 for the Redis vulnerability. If there are other issues (such as in the https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832460#25 report) that also need CVE IDs, please send a message about the others. Separate CVE IDs are also useful for host-based vulnerability scanning, e.g., a vulnerability check for a readable ~/.rediscli_history file completely covers CVE-2013-7458. A check for a readable ~/.dbshell file (if that is indeed a vulnerability) would map to a different CVE ID. - -- CVE Assignment Team M/S M300, 202 Burlington Road, Bedford, MA 01730 USA [ A PGP key is available for encrypted communications at http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJXmjBnAAoJEHb/MwWLVhi2XbUP/0Hx1N1IVhL3BJH+Ja5IBWrO b7EhDkUl/31ZdT+iSJFbyt1VYLt2K+x54SwyDE3qhcXriU+kzOGJzgHep1TwAUbD /vVKaNiLS6yAM9NRNpLI/IPL2Z6Xzt54cgYxYW/d7btRctFJKza9vKCkQeuIWtEN oR9Gfq3901wPxskRSKgzo6n5run1SfvRQ+icx8QO/7pqtPXfWiwweZXQYH/vIENe VdG5Hc/BFiJoPaWBQnP9z/Wmp1e9vtJjxzVZmFSWI8mq7MLCZgXqsBTpuxgrR+uB SUg5RexMz9zIfUmCZJ966SuDzc7Pg2FcmknrZcWmD2gZORZxRFJ4PXpya6znRaCU HCwh7dn+956EVs+UqOS0z1zBPKA3iOyVBSV7P4uwZ9X17UF2rVnVUTW2/NnR5zaA 4hO+dtDMcHN43ESv3gakwPcvazsSkix+ACiWYJqwdR76EnAZIPtv+kscGtgq7sC/ oQts0akBLAF49ppNCoHyJx87w8aOJ2jzcM7D41Yr8y0nVDFwux8zniw51N7i0/LX r27waQaRkrGSGCTPyovCAVrN9sh3qK/8TKGHpvN9z4wO4fi89PK/ZadixWpDTZFd neI9zWY1h/AMuT1oPay2lWy5Kj3G5Px253wX7DPDJTgreCbZN2Iupac7hULA28oG qEIvs2HrpjkHZZxW5NMN =Xa5w -----END PGP SIGNATURE-----
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.