Note: This issue is being discussed about a year late, as it was sitting forgotten in my blog post queue for some time. However, I have decided to post it now as it is still very much relevant. The attack explained below appears to still work on version 3.2.1 of Redis (tested on OS X and installed via brew). If the PoC fails and your inputrc file isn’t written to, it’s likely a directory permissions issue. Perhaps Redis is running as its own user, as it should?
The moral of the story is that even services on your own laptop that only listen on the loopback interface still need to be locked down.
Well, I don’t have a lua sandbox escape 0day. And developer machines don’t typically run SSH exposed to the Internet, so dropping keys into a user’s authorized_keys file like antirez explains in his post isn’t all that relevant.
Am I out of luck?
The Readline Init File
When I think back to the attack on users’ authorized_keys files, I am reminded that there may be other sensitive files on Linux filesystems which can be abused. An ideal file would be parsed by a service which doesn’t care if 99% of the file is garbage. This is important because rdb files contain a bunch of data at the beginning of the file we don’t care about.
The readline init file comes to mind. Programs which use readline can be customized with keybindings. Bash uses readline. Hey, maybe there’s something there! Now this isn’t nearly as cool as benmmurphy’s lua PoC, and it requires that whatever user Redis is running as have write permissions to your home directory. However, the readline init file parser does seems to ignore lines that aren’t valid entries, and if it works I could use keybindings to force you to execute malicious code when you type something in your terminal.
Proof of Concept
Click here for a proof of concept. Note that the source must be HTTP for this to work, due to issues with mixed content.
Typing z triggers the payload in the terminal. It even includes a new line at the end so the command automatically executes.