CVE-2015-4335/DSA-3279 – Redis Lua Sandbox Escape

What happened? Last week, in a post titled “Redis EVAL Lua Sandbox Escape”, security researcher Ben Murphy unveiled the details of a known Lua exploit that can be used for breaking out of Redis’ sandbox. Mr. Murphy was also kind enough to provide a patch that addresses said issue, which in turn was immediately included in new releases for Redis v2.8.21 and v3.0.2 from antirez, a.k.a. Salvatore Sanfilippo (as reported in last week’s Redis Watch newsletter).

How serious is this? Any security vulnerability is serious business, but while a malicious person can indeed exploit vulnerability to wreck havoc, it does require a non-trivial amount of skill do so. For example, refer to this sample code that’s designed to attack Lua 5.1 on a Windows 32-bit platform: https://gist.github.com/corsix/6575486. Furthermore, the exploit itself is but one step in a process that would involve attacking additional components of the compromised system. The bottom line is that while you should definitely take steps to protect your Redis servers against this exploit, keep in mind that the risk isn’t considered high.

How can you protect yourself? There are several steps you can take to protect your Redis from would-be-hackers’ pwnage. Here they are in order of importance:

1. Use password authentication – If you’re not using it, anyone can connect to it and pimp your Redis.
2. Use password authentication – Seriously, use a password.
3. Moar security – If you’re using Redis Cloud or Redis Enterprise Cluster (RLEC), consider using the access control lists provided from your dashboard to restrict access by security group and/or IP addresses or subnets. If you’re running your own Redis servers, a firewall with some hard-and-sane policies can get you the same effect.
4. SSL authentication and encryption – Protect yourself further by switching to a Redis Cloud or RLEC SSL-enabled database. Do-it-yourselfers can use stunnel to secure their servers in the same manner.

Upgrade your Redis. The new versions of open source Redis include the fix so you should be all good once you upgrade (if you’re running your own). RLEC users only need to install the newest software update in order apply the patch to their databases. We’ve also backported the patch to our cloud service, so new databases are immune to the vulnerability and we’re applying it online to existing instances.

Hot patch the exploit using itself. Mr. Ben Murphy outdid himself today (June 15th, 2015) and had published a hot patch that uses the vulnerability he himself had exposed to patch Redis and be done with it. Ideation by antirez, full details at: http://benmmurphy.github.io/blog/2015/06/09/redis-hot-patch/

Quick n’ dirty n’ awesome tip: here’s a little nugget from geocar – rename QUIT to POST to deal with that SSRF threat <- lovely!

Redis Trivia: AFAIK, this is the first Redis vulnerability that was registered in the MITRE Common Vulnerabilities and Exposures Directory (CVE-2015-4335 which is no longer up for some reason, did it escape too?) and at the Debian Security Advisory (DSA-3279) so double yay! Also note how, by sheer conspicuous coincidence, the DSA’s ID for the vulnerability is given by the following formulae:

I’m still working on cracking the logic behind the CVE ID though… Any Suggestions? Questions? Feedback? Email or tweet at me – I’m highly available 🙂