“The SLC response is built in a fixed 108-byte buffer, slcbuf, with only 104 bytes used for data after a 4-byte header. The function add_slc() (lines 162-175) appends 3 bytes per SLC triplet but never checks whether the buffer is full. The pointer slcptr is just incremented each time,” the company told the maintainers, according to a message to a GNU mailing list.
“After about 35 triplets […], the 104-byte space is exceeded and the code writes past the end of slcbuf. That corrupts whatever lies after it in BSS (including the slcptr pointer). Later, end_slc() uses the corrupted slcptr to write the suboption end marker, which gives the attacker an arbitrary write in memory. So the bug is a classic buffer overflow with no bounds check,” the message continued.
The maintainers prepared a patch the next day, making plans to release it by April 1, according to a timeline in Dream’s advisory.
Vulnerable systems include embedded systems and IoT devices with an exposed Telnet interface; servers and appliances that listen on TCP port 23 and use the vulnerable codebase, and Linux distributions that ship inetutils and leave telnetd enabled or installable, including Debian, Ubutnu, RHEL and SUSE, Dream said.
“A single network connection to port 23 is sufficient to trigger the vulnerability. No credentials, no user interaction, and no special network position are required,” it said.
Dream advised a number of immediate workarounds until the software can be patched, including migrating to secure alternatives such as SSH and disabling telnetd or running it without root privileges. Where that’s not possible, it advised blocking port 23 at the network perimeter and restricting its use to trusted hosts.
