CVE-2016-8339: Security: CONFIG SET client-output-buffer-limit overflow fixed. · redis/redis@6d9f8e2

Permalink

Browse files

Security: CONFIG SET client-output-buffer-limit overflow fixed.

This commit fixes a vunlerability reported by Cory Duplantis of Cisco Talos, see TALOS-2016-0206 for reference.

CONFIG SET client-output-buffer-limit accepts as client class “master” which is actually only used to implement CLIENT KILL. The “master” class has ID 3. What happens is that the global structure:

server.client\_obuf\_limits\[class\]

Is accessed with class = 3. However it is a 3 elements array, so writing the 4th element means to write up to 24 bytes of memory *after* the end of the array, since the structure is defined as:

typedef struct clientBufferLimitsConfig {
    unsigned long long hard\_limit\_bytes;
    unsigned long long soft\_limit\_bytes;
    time\_t soft\_limit\_seconds;
} clientBufferLimitsConfig;

EVALUATION OF IMPACT:

Checking what’s past the boundaries of the array in the global ‘server’ structure, we find AOF state fields:

clientBufferLimitsConfig client\_obuf\_limits\[CLIENT\_TYPE\_OBUF\_COUNT\];
/\* AOF persistence \*/
int aof\_state;                  /\* AOF\_(ON|OFF|WAIT\_REWRITE) \*/
int aof\_fsync;                  /\* Kind of fsync() policy \*/
char \*aof\_filename;             /\* Name of the AOF file \*/
int aof\_no\_fsync\_on\_rewrite;    /\* Don't fsync if a rewrite is in prog. \*/
int aof\_rewrite\_perc;           /\* Rewrite AOF if % growth is > M and... \*/
off\_t aof\_rewrite\_min\_size;     /\* the AOF file is at least N bytes. \*/
off\_t aof\_rewrite\_base\_size;    /\* AOF size on latest startup or rewrite. \*/
off\_t aof\_current\_size;         /\* AOF current size. \*/

Writing to most of these fields should be harmless and only cause problems in Redis persistence that should not escalate to security problems. However unfortunately writing to “aof_filename” could be potentially a security issue depending on the access pattern.

Searching for “aof.filename” accesses in the source code returns many different usages of the field, including using it as input for open(), logging to the Redis log file or syslog, and calling the rename() syscall.

It looks possible that attacks could lead at least to informations disclosure of the state and data inside Redis. However note that the attacker must already have access to the server. But, worse than that, it looks possible that being able to change the AOF filename can be used to mount more powerful attacks: like overwriting random files with AOF data (easily a potential security issue as demostrated here: http://antirez.com/news/96), or even more subtle attacks where the AOF filename is changed to a path were a malicious AOF file is loaded in order to exploit other potential issues when the AOF parser is fed with untrusted input (no known issue known currently).

The fix checks the places where the ‘master’ class is specifiedf in order to access configuration data structures, and return an error in this cases.

WHO IS AT RISK?

The “master” client class was introduced in Redis in Jul 28 2015. Every Redis instance released past this date is not vulnerable while all the releases after this date are. Notably:

Redis 3.0.x is NOT vunlerable.
Redis 3.2.x IS vulnerable.
Redis unstable is vulnerable.

In order for the instance to be at risk, at least one of the following conditions must be true:

1. The attacker can access Redis remotely and is able to send
   the CONFIG SET command (often banned in managed Redis instances).

2. The attacker is able to control the "redis.conf" file and
   can wait or trigger a server restart.

The problem was fixed 26th September 2016 in all the releases affected.

• Loading branch information