Security Model and Features in Redict #

This document provides an introduction to the topic of security from the point of view of Redict. It covers the access control provided by Redict, code security concerns, attacks that can be triggered from the outside by selecting malicious inputs, and other similar topics.

For security-related contacts, open an issue on GitHub, or when you feel it is really important to preserve the security of the communication, use the GPG key at the end of this document.

Security model #

Redict is designed to be accessed by trusted clients inside trusted environments. This means that usually it is not a good idea to expose the Redict instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redict TCP port or UNIX socket.

For instance, in the common context of a web application implemented using Redict as a database, cache, or messaging system, the clients inside the front-end (web side) of the application will query Redict to generate pages or to perform operations requested or triggered by the web application user.

In this case, the web application mediates access between Redict and untrusted clients (the user browsers accessing the web application).

In general, untrusted access to Redict should always be mediated by a layer implementing ACLs, validating user input, and deciding what operations to perform against the Redict instance.

Network security #

Access to the Redict port should be denied to everybody but trusted clients in the network, so the servers running Redict should be directly accessible only by the computers implementing the application using Redict.

In the common case of a single computer directly exposed to the internet, such as a virtualized Linux instance (Linode, EC2, …), the Redict port should be firewalled to prevent access from the outside. Clients will still be able to access Redict using the loopback interface.

Note that it is possible to bind Redict to a single interface by adding a line like the following to the redict.conf file:

bind 127.0.0.1

Failing to protect the Redict port from the outside can have a big security impact because of the nature of Redict. For instance, a single FLUSHALL command can be used by an external attacker to delete the whole data set.

Protected mode #

Unfortunately, many users fail to protect Redict instances from being accessed from external networks. Many instances are simply left exposed on the internet with public IPs. Redict enters a special mode called protected mode when it is executed with the default configuration (binding all the interfaces) and without any password in order to access it. In this mode, Redict only replies to queries from the loopback interfaces, and replies to clients connecting from other addresses with an error that explains the problem and how to configure Redict properly.

We expect protected mode to seriously decrease the security issues caused by unprotected Redict instances executed without proper administration. However, the system administrator can still ignore the error given by Redict and disable protected mode or manually bind all the interfaces.

Authentication #

Redict provides two ways to authenticate clients. The recommended authentication method is via Access Control Lists, allowing named users to be created and assigned fine-grained permissions. Read more about Access Control Lists.

TLS support #

Redict has optional support for TLS on all communication channels, including client connections, replication links, and the Redict Cluster bus protocol.

Disallowing specific commands #

It is possible to disallow commands in Redict or to rename them as an unguessable name, so that normal clients are limited to a specified set of commands.

For instance, a virtualized server provider may offer a managed Redict instance service. In this context, normal users should probably not be able to call the Redict CONFIG command to alter the configuration of the instance, but the systems that provide and remove instances should be able to do so.

In this case, it is possible to either rename or completely shadow commands from the command table. This feature is available as a statement that can be used inside the redict.conf configuration file. For example:

rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52

In the above example, the CONFIG command was renamed into an unguessable name. It is also possible to completely disallow it (or any other command) by renaming it to the empty string, like in the following example:

rename-command CONFIG ""

Attacks triggered by malicious inputs from external clients #

There is a class of attacks that an attacker can trigger from the outside even without external access to the instance. For example, an attacker might insert data into Redict that triggers pathological (worst case) algorithm complexity on data structures implemented inside Redict internals.

An attacker could supply, via a web form, a set of strings that are known to hash to the same bucket in a hash table in order to turn the O(1) expected time (the average time) to the O(N) worst case. This can consume more CPU than expected and ultimately cause a Denial of Service.

To prevent this specific attack, Redict uses a per-execution, pseudo-random seed to the hash function.

Redict implements the SORT command using the qsort algorithm. Currently, the algorithm is not randomized, so it is possible to trigger a quadratic worst-case behavior by carefully selecting the right set of inputs.

String escaping and NoSQL injection #

The Redict protocol has no concept of string escaping, so injection is impossible under normal circumstances using a normal client library. The protocol uses prefixed-length strings and is completely binary safe.

Since Lua scripts executed by the EVAL and EVALSHA commands follow the same rules, those commands are also safe.

While it would be a strange use case, the application should avoid composing the body of the Lua script from strings obtained from untrusted sources.

Code security #

In a classical Redict setup, clients are allowed full access to the command set, but accessing the instance should never result in the ability to control the system where Redict is running.

Internally, Redict uses all the well-known practices for writing secure code to prevent buffer overflows, format bugs, and other memory corruption issues. However, the ability to control the server configuration using the CONFIG command allows the client to change the working directory of the program and the name of the dump file. This allows clients to write RDB Redict files to random paths. This is a security issue that may lead to the ability to compromise the system and/or run untrusted code as the same user as Redict is running.

Redict does not require root privileges to run. It is recommended to run it as an unprivileged redict user that is only used for this purpose.

GPG key #