[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [BUG][PATCH] Someone described a remote DoS Vulnerability in telnetd
Re: [BUG][PATCH] Someone described a remote DoS Vulnerability in telnetd (dereference NULL pointer ---> SEGV)
Sun, 28 Aug 2022 14:40:44 +0200
On Sat, Aug 27, 2022 at 07:37:15PM +0200, Erik Auerswald wrote:
> someone has described a remote DoS vulnerability in
> many telnetd implementations that I just happened to
> stumble over:
> The vulnerability is a NULL pointer dereference when
> reading either of two two byte sequences:
> 1: 0xff 0xf7
> 2: 0xff 0xf8
> The blog shows GNU Inetutils' telnetd as vulnerable:
I have confirmed that sending either of the above two byte
sequences to telnetd spawned via inetd results in a NULL
pointer dereference in telnetd.
One way to send the byte sequence is to use xxd and netcat:
$ # inetd listening on 127.0.0.1:4711 starts telnetd
$ xxd -r -p <<<'fff7' | nc 127.0.0.1 4711 >/dev/null
$ xxd -r -p <<<'fff8' | nc 127.0.0.1 4711 >/dev/null
In debug mode, inetd reports "<PID> reaped, status 0x8b".
At least on my GNU/Linux system, "dmesg" reports the NULL
[<Timestamp>] telnetd[<PID>]: segfault at 0 [...]
I could not trigger this problem with the "telnet" client.
The blog post describes that after 256 crashes "inetd" no
longer starts telnetd, resulting in a DoS. With my simple
inetd test configuration (just one line to start telnetd
on 127.0.0.1:4711) and inetd running in debug mode ("-d"),
I could not reproduce this.
> In GNU Inetutils, the code lines to dereference table
> entries without first checking for NULL are in lines
> 321 and 323 of file "telnetd/state.c". The variable
> "ch" declared in line 315 of this file needs to be
> initialized to "(cc_t) (_POSIX_VDISABLE)", because it
> may not be assigned any value if the table is not yet
> line 315:
> line 321:
> line 323:
> I have attached a completely untested, not even compile
> tested, patch to do this (just the code changes, no NEWS
> or commit log or anything). Please test before committing.
I have tested the patch now, it compiles and prevents the
crash by preventing the NULL pointer dereference.