Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 28 Jul 2016 12:22:20 -0400 (EDT)
Subject: Re: CVE Request: redis: World readable .rediscli_history

Hash: SHA256


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


> 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. 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, 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 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 ]
Version: GnuPG v1


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.