{"id":16661,"date":"2021-07-08T11:48:27","date_gmt":"2021-07-08T09:48:27","guid":{"rendered":"https:\/\/herolab-usd.formwandler.rocks\/security-advisories\/usd-2020-0003\/"},"modified":"2021-07-19T14:14:27","modified_gmt":"2021-07-19T12:14:27","slug":"usd-2020-0003","status":"publish","type":"page","link":"https:\/\/herolab.usd.de\/en\/security-advisories\/usd-2020-0003\/","title":{"rendered":"usd-2020-0003"},"content":{"rendered":"

[et_pb_section fb_built=\"1\" _builder_version=\"4.9.4\" _module_preset=\"default\" background_color=\"#2E353D\" custom_padding=\"||0px|||\"][et_pb_row _builder_version=\"4.9.4\" _module_preset=\"default\"][et_pb_column type=\"4_4\" _builder_version=\"4.9.4\" _module_preset=\"default\"][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"cc5ac6f4-ebbd-4b3f-bc92-4dfc1f15fe2c\"]<\/p>\n

usd-2020-0003 | Nagios NRPE v.3.2.1<\/span><\/h1>\n

<\/span>
Advisory ID<\/strong>: usd-2020-0003<\/span>
Affected Product<\/strong>: Nagios NRPE<\/span>
Affected Version<\/strong>: v.3.2.1<\/span>
Vulnerability Type<\/strong>: Wrong Packet Size Computation<\/span>
Security Risk<\/strong>: Low<\/span>
Vendor URL<\/strong>: https:\/\/www.nagios.org\/<\/a><\/span>
Vendor Status<\/strong>: Fixed in v4.0.0 (not verified)<\/span><\/p>\n

<\/h3>\n

Proof of Concept (PoC)<\/h3>\n
\n

NRPE currently allows two different packet versions that can be used to communicate with the NRPE server: v2 and v3. The v3 packet structure is defined like this:<\/p>\n<\/div>\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

The member <\/span>buffer<\/strong>\u00a0is only a placeholder that gets replaced by the actual packet contents during processing. Therefore, only a length of<\/span>
1 byte is assigned to it, since it has not to carry any meaningful data. The NRPE source code calculates the length of a v3 packet 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\"] int32_t pkt_size = sizeof(v3_packet) - 1 + buffer_length;<\/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

As one can see, the previously used length of the placeholder <\/span>buffer<\/strong>\u00a0is substracted from the size of the structure, since it will be replaced<\/span>
by the real payload. However, the code does not respect the padding length that is applied by the compiler. Structures that do not end on a boundary<\/span>
of 4 bytes are usually padded to match that requirement. Therefore, the size of the <\/span>buffer<\/strong>\u00a0member will actually be 4, not 1. One can easily confirm this<\/span>
by using the following C code:<\/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\"] #include
\n#include<\/p>\n

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;<\/p>\n

int main() {
\nv3_packet test;
\nprintf(\"%d\\n\", sizeof(test));
\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\"]The output will be 20, since the structure contains the following lengths:[\/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\"]typedef struct _v3_packet {
\nint16_t packet_version; \/\/ 2
\nint16_t packet_type; \/\/ 2
\nu_int32_t crc32_value; \/\/ 4
\nint16_t result_code; \/\/ 2
\nint16_t alignment; \/\/ 2
\nint32_t buffer_length; \/\/ 4
\nchar buffer[1]; \/\/ 4
\n} v3_packet; <\/code><\/pre>\n

[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"default\" custom_margin=\"||27px||false|false\"]One can also observe this wrong calculation of the packet size when communicating with the NRPE server. Messages transmitted over the network often contain three additional null bytes, since the buffer size is three bytes longer than the actual packet. Hexdump of a NRPE server response:[\/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\"] 00000000 00 03 00 02 34 22 6d cc 00 00 00 00 00 00 00 10 ....4\"m. ........
\n00000010 5b 2b 5d 20 50 4f 43 20 66 69 6e 69 73 68 65 64 [+] POC finished
\n00000020 00 00 00 <\/code><\/pre>\n

[\/et_pb_text][et_pb_text _builder_version=\"4.9.4\" _module_preset=\"cc5ac6f4-ebbd-4b3f-bc92-4dfc1f15fe2c\"]<\/p>\n

\n
\n

Our short research did not identify a vulnerability resulting from this incorrect length calculation. However, such bugs often<\/span>
lead to security relevant issues and should be fixed.<\/span><\/p>\n

<\/h3>\n

Fix<\/h3>\n

Respect structure padding during packet length calculations.<\/span><\/p>\n

<\/h3>\n

Timeline<\/h3>\n