[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-inetutils] "echo" dgram service in *inetd and UDP packets with
Re: [bug-inetutils] "echo" dgram service in *inetd and UDP packets with source port 7
Sat, 29 Nov 2014 19:56:40 +0000
2014-11-27 16:55:52 -0500, Alfred M. Szmidt:
> Then upon receiving that packet, HOSTB will send the same packet
> reversed to HOSTA and we'll start a ping-pong game that will only
> stop when someone drops the ball (tested on Debian with
> inetutils-inetd and openbsd-inetd, not xinetd but I assume it's the
> Which version?
Any version. That's not an issue with the inetd implementations,
but with the protocols.
> The echo protocol is a debugging and measurement tool, it is not
> supposed to be used for security sensetive tools. It would also be a
> violation of RFC 862 to change the behaviour in this format, where it
> is allowed to induce this kinda of a loop.
Yes, but I don't think RFC conformance is good enough a reason
to not fix a vulnerability.
Anyway, the proposed "hardening" would not be sufficient as
chargen and daytime at least have the same issue. So we'd need
to also not reply to packets with the corresponding source port
(7, 13, 19) for all 3 services which I'd agree is not the right
way to address the problem.
At least nowadays, those services are not enabled by default at
least in the opensource implementations. I think a good step
further would be to clearly document that enabling those
services have security implications and that they should not be
exposed to the internet.
I've just come across
which you might want to read for more information, which shows
it's been a known problem for a very long time. CERT
as far as recommending those services be disabled.
2014-11-27 16:55:57 -0500, Alfred M. Szmidt:
> I know. Yet, that "builtin" service is still there in the 2014
> implementations of inetd and people ask about them:
> Please redirect them here for a dicussion, bug-inetutils@ is the right
> place to discuss these things.
Well that question was not specifically about any particular
implementation of inetd. And my initial email was to the
maintainers of inetutils', xinetd, and openbsd-inetd debian
I'd also argue that unix.stackexchange.com have better
visibility that the bug-inetutils archives. And redirecting
question askers to mailing lists is not how those sites work.