During last August I made a security audit to an interesting embedded library I have found in Github: libcsp:
Cubesat Space Protocol – A small network-layer delivery protocol designed for Cubesats
This blog post will describe my findings, CVE 2016-8596, CVE 2016-8597, CVE 2016-8598, will publicly disclose the vulnerabilities and will elaborate on the lessons that can be learned from them.
CVE 2016-8596
The satellite’s inner communication bus, shared between all of it’s components, is the CAN bus. Since the bus has a ridiculously short MTU (8 payload bytes), the CSP protocol defines a fragmentation to support messages of up to 256 bytes. As is usually the case with this high-risk network feature, the CSP library suffered from a security vulnerability. Here is the canbus interface’s code:
switch (CFP_TYPE(id)) {
case CFP_BEGIN:
/* Discard packet if DLC is less than CSP id + CSP length fields */
if (frame->dlc < sizeof(csp_id_t) + sizeof(uint16_t)) {
csp_log_warn("Short BEGIN frame received");
csp_if_can.frame++;
csp_can_pbuf_free(buf);
break;
}
/* Check for incomplete frame */
if (buf->packet != NULL) {
/* Reuse the buffer */
csp_log_warn("Incomplete frame");
csp_if_can.frame++;
} else {
/* Allocate memory for frame */
buf->packet = csp_buffer_get(CSP_CAN_MTU);
if (buf->packet == NULL) {
csp_log_error("Failed to get buffer for CSP_BEGIN packet");
csp_if_can.frame++;
csp_can_pbuf_free(buf);
break;
}
}
/* Copy CSP identifier and length*/
memcpy(&(buf->packet->id), frame->data, sizeof(csp_id_t));
buf->packet->id.ext = csp_ntoh32(buf->packet->id.ext);
// EI-Explanation: packet->length is controllable -1-
memcpy(&(buf->packet->length), frame->data + sizeof(csp_id_t), sizeof(uint16_t));
buf->packet->length = csp_ntoh16(buf->packet->length);
/* Reset RX count */
buf->rx_count = 0;
/* Set offset to prevent CSP header from being copied to CSP data */
offset = sizeof(csp_id_t) + sizeof(uint16_t);
/* Set remain field - increment to include begin packet */
buf->remain = CFP_REMAIN(id) + 1;
/* FALLTHROUGH */
case CFP_MORE:
/* Check 'remain' field match */
if (CFP_REMAIN(id) != buf->remain - 1) {
csp_log_error("CAN frame lost in CSP packet");
csp_can_pbuf_free(buf);
csp_if_can.frame++;
break;
}
/* Decrement remaining frames */
buf->remain--;
/* Check for overflow */
// EI-Explanation: This check has no meaning, because length is controllable, see -1-.
// The actual buffer's size is 256, and is NOT being checked... -2-
if ((buf->rx_count + frame->dlc - offset) > buf->packet->length) {
csp_log_error("RX buffer overflow");
csp_if_can.frame++;
csp_can_pbuf_free(buf);
break;
}
/* Copy dlc bytes into buffer */
// EI-Explanation: Simple bof, sizes are checked incorrectly, see -2-.
memcpy(&buf->packet->data[buf->rx_count], frame->data + offset, frame->dlc - offset);
buf->rx_count += frame->dlc - offset;
/* Check if more data is expected */
if (buf->rx_count != buf->packet->length)
break;
/* Data is available */
csp_new_packet(buf->packet, &csp_if_can, NULL);
/* Drop packet buffer reference */
buf->packet = NULL;
/* Free packet buffer */
csp_can_pbuf_free(buf);
break;
default:
csp_log_warn("Received unknown CFP message type");
csp_can_pbuf_free(buf);
break;
}
And as we can see in the code, the drivers suffers from a Buffer-Overflow vulnerability due to confused length checks. This is a typical fragmentation vulnerability: sizes are validated against a controllable length field, instead of comparing against the actual allocated buffer’s size.
Meaning: a hostile component in the cubesat can spread over the inner CAN bus, and take over the rest of the components.
CVE 2016-8597
The Small Fragmentation Protocol (SFP) was introduces as an experimental protocol, and was originally designed as a full-featured fragmentation protocol. Here is the SFP’s receive code:
/* Get first packet from user, or from connection */
csp_packet_t * packet = NULL;
if (first_packet == NULL) {
packet = csp_read(conn, timeout);
if (packet == NULL)
return -1;
} else {
packet = first_packet;
}
do {
/* Check that SFP header is present */
if ((packet->id.flags & CSP_FFRAG) == 0) {
csp_debug(CSP_ERROR, "Missing SFP header");
return -1;
}
/* Read SFP header */
// EI-Vuln: no minimal size check to include this header -1-
sfp_header_t * sfp_header = csp_sfp_header_remove(packet);
sfp_header->offset = csp_ntoh32(sfp_header->offset);
sfp_header->totalsize = csp_ntoh32(sfp_header->totalsize);
csp_debug(CSP_PROTOCOL, "SFP fragment %u/%u", sfp_header->offset + packet->length, sfp_header->totalsize);
if (sfp_header->offset > last_byte + 1) {
csp_debug(CSP_ERROR, "SFP missing %u bytes", sfp_header->offset - last_byte);
csp_buffer_free(packet);
return -1;
} else {
last_byte = sfp_header->offset + packet->length;
}
/* Allocate memory */
if (*dataout == NULL)
*dataout = csp_malloc(sfp_header->totalsize);
if (*dataout == NULL) {
csp_debug(CSP_ERROR, "No dyn-memory for SFP fragment");
csp_buffer_free(packet);
return -1;
}
/* Copy data to output */
*datasize = sfp_header->totalsize;
// EI-Vuln: allocation of 0, copying of packet>length => BOF -2-
memcpy(*dataout + sfp_header->offset, packet->data, packet->length);
if (sfp_header->offset + packet->length >= sfp_header->totalsize) {
csp_debug(CSP_PROTOCOL, "SFP complete");
csp_buffer_free(packet);
return 0;
} else {
csp_buffer_free(packet);
}
} while((packet = csp_read(conn, timeout)) != NULL);
And again, there are simply too many length fields, and while the allocation is done using the overall totalsize, the copy is done using the actual length, resulting in a Buffer-Overflow in a single fragment.
Meaning: an adversary that is accessible to the underlying network layers of the SFP protocol, can triggers this vulnerability to execute arbitrary code over the vulnerable module.
CVE 2016-8598
The libcsp library includes support for ZMQ, using an additional interface. Let’s look on the interface’s code:
/* Create new csp packet */
csp_packet_t * packet = csp_buffer_get(256);
if (packet == NULL) {
zmq_msg_close(&msg);
continue;
}
/* Copy the data from zmq to csp */
char * satidptr = ((char *) &packet->id) - 1;
// EI-Vuln: seems like a pretty neat BOF -1-
memcpy(satidptr, zmq_msg_data(&msg), datalen);
packet->length = datalen - 4 - 1;
And this time it’s the most simple Buffer-Overflow one can see in a C code: lack of checks on the length field that is used for the actual memcpy.
Meaning: an adversary that is accessible to the ZMQ interface can execute arbitrary code over the vulnerable component using that interface.
Conclusion
The libcsp library is a classic example of an embedded C code in which “lightweight” network utilities are often translated into “lack of checks” over the incoming packets. An important lesson to be learned from a researcher’s point of view, is that there is a tight connection between the amount of length fields and the chance of finding a security vulnerability.
Soon to come: after the next CVE publication (soon to come), I will post a fragmentation-dedicated post, that will include several important lessons that can aid the beginner researcher.
