NetX Duo: A TFTP server that answers with a short ERROR packet makes the client read up to 64 bytes past the received datagram. Each receive path checks only that the datagram is at least four bytes long
What fixes it
No source in this snapshot names a fixed version. The vendor advisories under References are the place to check.
Description
A TFTP server that answers with a short ERROR packet makes the client read up to 64 bytes past the
received datagram.
Each receive path checks only that the datagram is at least four bytes long (nxd_tftp_client.c:1229,
1521, 1984). When the opcode is NX_TFTP_CODE_ERROR the message string is copied with a loop whose
only limits are the destination buffer and a NUL byte:
/* addons/tftp/nxd_tftp_client.c:1769 */ for (i = 0; (i < (sizeof(tftp_client_ptr -> nx_tftp_client_error_string) - 1)) && (*buffer_ptr); i++)
Nothing compares buffer_ptr against nx_packet_append_ptr. An ERROR packet that carries no
terminating NUL, which a server controls completely, walks the loop off the end of the packet until
it happens to meet a zero byte or fills the 64 byte destination.
ERROR: AddressSanitizer: heap-buffer-overflow
READ of size 1 at 0x60d0000000c8 thread T4
#0 _nxd_tftp_client_file_read addons/tftp/nxd_tftp_client.c:1769
0x60d0000000c8 is 0 bytes to the right of 136-byte region
The open path has the same loop at :1327 and reports the same way. What is read lands in
nx_tftp_client_error_string, which the application is expected to display or log, so adjacent
packet pool memory ends up in whatever the device does with the error text.
Add (buffer_ptr < packet_ptr -> nx_packet_append_ptr) to the loop condition in all three paths.
Text from CVE List
Affected versions 1
- NetX Duoaffected: all versions through 6.5.1CVE List