Yesterday, June 4th, a Redis release was done to fix a Lua vulnerability which gave those with access to a Redis server the ability to break out of Redis and run arbitrary code. Read on to learn why your ObjectRocket Redis instances are not at risk and details on the vulnerability itself.
The vulnerability
If the attacker is able to execute arbitrary commands against your Redis instance, then the attacker can send a specially crafted Lua script via the Redis EVAL command. This would allow the attacker to execute C library calls on the host. As there are C calls which provide the ability to execute system-level commands, this would give the attacker the ability to run arbitrary code and commands on the host.
Mitigating factors
No exploit is perfect – they all require certain conditions to be met – which means they are not always applicable. This exploit is no different. There are several reasons this is not a high priority exploit for you to worry about if you are using ObjectRocket’s Redis offering.
We require your instance be password protected
First, in order for any of this to work the attacker has to have authentication to your Redis instance. To succeed this attack would have to be custom crafted by adding in a Redis auth call with your instance password before it can do anything. As noted in the original post, a password protected instance is thus essentially immune to the attack. If the attacker knows your password, they already have access to your data and would not be using this exploit to get the data.
We require IP based access control lists
In addition to knowing your password, the attacker would need to be able to connect to your instance. This would require their IP to be included in your ACL listing in the control panel. Naturally if you’ve enabled any IP to connect they’d be able to gain network access – but still require your Redis password.
Your instance is isolated
The design and deployment of ObjectRocket’s Redis platform includes the use of containers to isolate every Redis instance. This isolation prevents a breached instance from breaking out of its space, and the containers have minimal tools available thus limiting the potential code to be executed.
So even if the hacker has your password, is in your acceptable IP list via ACLs, then the worst they could do to you is to crash your Redis instance. Of course if they have the first two conditions they already have the last regardless of the exploit.
Great, but what about the SSRF thing?
In his blog post, Ben talks about a means to get to a localhost running Redis via some other server running on that host. If you’re using ObjectRocket’s Redis service it isn’t running under such a condition. That said if you are running development machines with multiple internet-accessible services, with Redis among them listening on localhost you should consider switching your development Redis instance to a UNIX socket or making your development system not Internet-accessible, or password protecting your development Redis instance.