TL;DR – “White hats, do a CONFIG SET requirepass "Hey There, I reset your password because I found it open on the Internet xk8382akdka" followed by a CONFIG REWRITE for all the open redis instances out there, instead of me designing a real security model for redis.”
CONFIG SET requirepass "Hey There, I reset your password because I found it open on the Internet xk8382akdka"
A security system for Redis is orthogonal to setting up a secure network. Even if Redis had a great security system, you still shouldn’t be allowing connections from the open internet.
That may be true, but redis, by default (I just verified as of 3.0.5), binds to all network interfaces, not just 127.0.0.1. That means that a default install with a misconfigured firewall (all too common), your machine is completely open to the world, and there’s not even a password preventing someone from accessing it.
And, even in this day and age, redis doesn’t support TLS, which is often troubling for compliance stories, some of which require encryption on the wire.
Or simply an unconfigured firewall, the default pretty much everywhere.
with a misconfigured firewall (all too common)
Why is Redis the problem and not your misconfigured firewall?
Both are problematic, but there is a simple fix. Bind only to 127.0.0.1 out of the box. Let someone else (the user) decide that they need to bind to a external interface, and ensure that their firewall rules are correct.
Useful command too see what services are listening on which IPs (v4 and v6):
lsof -nP -iTCP -sTCP:LISTEN
lsof -nP -iUDP
Personally I’m not a great fan of firewalling when services can also be configured to listen on specific IPs. My rule of thumb is never bind a service to the wildcard interface (*) Unfortunately not all services support this (looking at you, NFS), or they only support ‘listen on one or listen on all’ (mysql).
It seems like Redis could have sensible defaults in less time than it took to write all that.
Even if they release a fixed version there will still be a a lot of out-of-date redis server out there.
This is true of every vulnerability. We still at least try to fix it.
There is no fix. It is the job of the administrator to set up the system correctly. Why is it so unreasonable to expect people to understand how to configure the software they are using?
Sure, users should configure things properly. But why do you feel it’s unreasonable to expect that software should be secure by default? At any rate, it’s in Redis' best interest, because it is what receives the bad press, not all the users getting caught out.
I mean, I sympathise–I really do. Years ago I upgraded an open-source Objective-C library I have to use Automatic Reference Counting (ARC), and despite that being the main focus of the release so many people were complaining about the library having terrible memory leaks, so I had to litter every source file with this shit to stop it compiling if you didn’t compile it with ARC:
#error "This source file must be compiled with ARC enabled!"
I hated having to do it at the time, but you know what? I sucked it up and added it, and it really helped my users. And it helped me because it reduced my support burden: I didn’t have to constantly explain to users that no, there’s no memory leak, you just have to compile the library with ARC.
While I don’t agree that it is unreasonable, history has shown time and again that users simply do not. Being responsible is having secure defaults; even if that means not entirely “working” out of the box. Binding to localhost and having a password are simple, time tested solutions to the problem these Redis instances are facing.
I’m a little surprised that no one’s taken up the position that modifying other people’s systems is wrong, period.