nrpe bugs

[e9925248]

1) receive_paket reads a int32_t from network and passes it to calloc. So youi can force a memory allocation up to 2 GB by sending a V3 paket header with a large buffer length. You just need a few connections to allocate lots of GB to trigger OOM conditions.

There is no check for negative buffer length, but this should be safe because of side effects: On 64 bit user space, you would allocate > 2^63 bytes, which will fail on current hardware. On 32 bit user space, if allocating up to 4 GB succeeds, recvall would read 0 bytes and therefore fail.

2) check_nrpe / receive_paket SSL path sets v3>buffer[v3->buffer_length] to zero - The allocation size is size(v3) - 1 + buffer_length, so it writes beyond the buffer.

3) check_nrpe / read_response uses v3->buffer as string - there is no forced NULL termination on the non SSL code.

4) my_system: the forked child writes data from the child process to the pipe without checking the returned length. It is unlikely, but write may only write parts of the data - in that case, the remaining part of that block is ignored and the next block will be written to the pipe - resulting in gaps.

[hedenface]

Thanks!

[e9925248]

The code would be better reviewable, if

• strncat and the following buf[buffe-size - 1 ] = 0 (as well as for other variants like strncpy, snprintf) would be refactored to functions
• create a abstract read/write function which calls the ssl/non-ssl read/write functions - any other highlevel code (like receive_packet) would just uses these IO functions and therefore there wouldn't be any differences (which usually means "bugs") between the SSL/non-SSL code.