[Toybox] [PATCH] telnetd: handle TIME_WAIT better.

[enh]

On Mon, Apr 26, 2021 at 11:43 PM Rob Landley <rob at landley.net> wrote:

>
>
> On 4/26/21 11:28 AM, enh wrote:
> >
> >
> > On Sat, Apr 24, 2021 at 2:37 AM Rob Landley <rob at landley.net
> > <mailto:rob at landley.net>> wrote:
> >
> >     On 4/22/21 9:00 PM, enh via Toybox wrote:
> >     > After a network outage, a long-running telnetd was spinning trying
> to
> >     > read from a socket that was in TIME_WAIT. It's easy to reproduce
> this by
> >     > using the regular telnet client and typing ^]^D to exit abruptly.
> >
> >     Doesn't apply without the previous one. I'll apply the whole stack
> on the theory
> >     it's in pending so I don't have a strong attachment to what's there,
> and you've
> >     just put a lot more effort into understanding it than I have so far.
> >
> >     But I don't think telnet should depend on having access to a DNS
> server
> >     describing any of the machines involved...
> >
> >
> > this is telnet*d*, not telnet. but, yeah, it's unclear to me whether --
> despite
> > the fact that the login argument is called "hostname" -- we're really
> supposed
> > to supply the name or just the address[1].
>
> The address has more information than the name. (In theory you can have
> multiple
> addresses map to the same name...)
>
> > that said, BSD telnetd even has an
> > option to disallow connections from addresses it can't do a reverse
> lookup on
> > (https://www.freebsd.org/cgi/man.cgi?query=telnetd&sektion=8).
> >
> > they were different times :-)
>
> This is only really safe to use in a LAN or through a VPN these days, and
> I'm
> uncomfortable sending reverse DNS lookups out to the internet every time
> your
> test bench behind the firewall sends scripted result data to 10.243.37.5.
> (Not
> to mention the failing lookup potentially causing multiple seconds of
> latency in
> configurations I've hit repeatedly over the years.)
>
> I just added an NI_NUMERICHOST in there to squelch the DNS lookups. (And no
> I didn't re-wordwrap it, because this command still needs cleanup: making
> forkpty() nommu aware is a largeish TODO item that hits other commands
> too, and
> I've vaguely pondered trying to merge this with netcat and tcpsvd.c which
> is
> where pollinate() came from in lib/net.c but I'd need to work out a proper
> design before coding anything and haven't yet...)
>
> > 1. the present code will supply the address rather than the name anyway,
> in the
> > case that there's no DNS entry. so unless your objection is "shouldn't
> even
> > _try_ DNS", i don't think this makes any practical difference.
>
> That's what I was uncomfortable about, yes. The data exfiltration and
> potential
> 15 second hang on a misconfigured system that I KEEP HITTING at various
> employers over the years.
>

yeah, makes sense[1]. lgtm.


> Rob
>

____
1. to the extent that anyone running telnetd in 2021 makes sense :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20210428/4e8ad378/attachment-0001.htm>