> 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. That is not how one implements network protocols, or portable implementations of clients and servers. The RFCs are there for a reason, they document what is currently used. Though, after thinking, I am partially keen to breaking the protocol in a documented fashion, and submitting new RFCs for these protocols. It would make things more useful, and the changes simply mean that a very special case stops working. Would you like to submit a patch to amend these issues? That in itself would be useful for those who do want to explicitly break the protocol for whatever reason. At least nowadays, those services are not enabled by default at least in the opensource implementations. The GNU network utilities are a free software implementation of many network protocols, and have nothing to do with open source. Please do not call our project for an open source project. 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. This is a good idea, would you like to submit a piece of text for the manual? 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. The only place to talk about these issues in inetutils is here, nobody of the maintainers reads this web site.
