bug-inetutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [BUG][PATCH] Someone described a remote DoS Vulnerability in telnetd


From: Erik Auerswald
Subject: Re: [BUG][PATCH] Someone described a remote DoS Vulnerability in telnetd (dereference NULL pointer ---> SEGV)
Date: Wed, 31 Aug 2022 09:04:43 +0200

Hello Simon,

On Tue, Aug 30, 2022 at 10:46:08PM +0200, Simon Josefsson wrote:
> Erik Auerswald <auerswal@unix-ag.uni-kl.de> writes:
> 
> >> 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.
> 
> Thanks -- looks good to me, would you like to commit it?  Please add a
> suitable NEWS entry.

I'll look into this.  I do not expect to find time before the weekend.

> Do you see any way to check for regressions that doesn't involve running
> telnetd/telnet on the command line?  I'm thinking a automake C check
> that links to relevant internals.

No idea.  I have not really looked at the code, I just read the blog
post, reproduced dereferencing a NULL pointer, and verified that adding
the suggested checks prevents this.

As I understand the blog post, the problem lies in using the table before
it has been filled with (possibly connection specific?) information, such
that it is still filled with NUL bytes.  I tried to provoke the crash by
adding "send ec" and "send el" to $HOME/.telnetrc, but that did not work.
This could mean that "normally" this data structure is filled in before
use, or that the telnet client did not send the byte sequence 0xff 0xf7
(IAC EC) or 0xff 0xf8 (IAC EL) to the server (I did not verify).

It would be good to have a way toautomatically test the bug fix,
of course.

> A new release would be nice, maybe we can throw in some other
> improvement as well.

I think that there are still a few crashes found via fuzzing in the code.

Thanks,
Erik



reply via email to

[Prev in Thread] Current Thread [Next in Thread]