Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Day the Telnet Died

labs.greynoise.io

Post reply on HN
Print view View original

391–400 of 414 posts

Re: The Day the Telnet Died

#391

Post by ycombinatrix »

naniwaduni wrote: post #206
digitalPhonix wrote: post #189

The CVE referenced is caused by this commit: https://codeberg.org/inetutils/inetutils/commit/fa3245ac8c28... One of the changes is: - getterminaltype (char *user_name, size_t len) + getterminaltype (char *uname, size_t len) What is the reason for a rename these days? If I saw that in a code review I’d immediately get annoyed (and probably pay more attention)

From ChangeLog: * telnetd/utility.c (getterminaltype): Change the name `user_name' to `uname', as the former shadows a precious and global variable name.

global variables are public enemy number one

Re: The Day the Telnet Died

#392

Post by acdha »

icedchai wrote: post #387
acdha wrote: post #386

Earlier quoted context omitted.

This is quite untrue as a blanket statement. The problem is that there was massive cultural variation: if you installed a Perl module from CPAN you probably ran hundreds of tests. If you ran a C program, it ranged from nothing to “run this one input and don’t crash” to exhaustive suites. PHP tended towards nothing with a handful of surprises. As a data point, my first tech job was QA for a COBOL compiler vendor. They…

True, it is colored by my own personal experienced. I remember CPAN, perl, and installing modules with tests. I also remember my day job: a 500,000 line C and C++ code base with literally 5 automated tests that nobody ever ran!

Yeah, I think it’s really hard to understand how much more cultural variation there was without first the internet and open source, and then services like GitHub, GitLab, BitBucket, etc. converging people onto similar practices and expectations.

Re: The Day the Telnet Died

#393

Post by FabHK »

nomel wrote: post #164
FabHK wrote: post #75

Earlier quoted context omitted.

Traffic could be tampered as well.

Sometimes that doesn't matter either. That is the valid use case of a plain-text protocol like telnet: doesn't matter.

Sure. But, contrary to what some people seem to think, "it's nothing secret" is not a sufficient justification to use an unencrypted plain-text protocol.

Re: The Day the Telnet Died

#394

Post by 1718627440 »

Twisol wrote: post #390
1718627440 wrote: post #247

Earlier quoted context omitted.

Using netcat results in showing Unicode replacement symbols, instead of answering to telnet options. I doubt it implements telnet at all, because this is just not its job.

I agree in principle, but actually, according to the netcat website [0]: > If netcat is compiled with -DTELNET, the -t argument enables it to respond to telnet option negotiation [always in the negative, i.e. DONT or WONT]. This allows it to connect to a telnetd and get past the initial negotiation far enough to get a login prompt from the server. Since this feature has the potential to modify the data stream, it is…

So it supports enough to tell others that it doesn't support it. That's more than I expected, but still don't serves me when I actually want to use telnet.

Re: The Day the Telnet Died

#395

Post by tokyobreakfast »

RupertSalt wrote: post #293
its_magic wrote: post #204

Earlier quoted context omitted.

Because I go long periods of time without internet access, and I don't want to have to "sudo apt install" a fucking thing, ever. Especially not a tiny utility that is all of 172k in size, that I might need for something. Understand? I want EVERYTHING that I might use installed AT ALL TIMES, FROM DAY ONE, so that I can IMMEDIATELY USE IT when required. This is only one of many reasons why I abandoned the giant dumpste…

I would never ever install your distro for this reason alone. Someone has already pointed out that old/deprecated/obsolete software like a telnet client represent tech debt. Removing the telnet client was, in part, a recognition that its complementary server was deprecated and unsafe. If everyone was transitioned to ssh and nc, [and custom MUD clients], why keep telnet around? Any software like this represents tech d…

> Furthermore, ask the maintainers of OpenBSD or any hardened OS about attack surfaces.

OpenBSD still ships with telnet.

Their developers don't entertain nonsense virtue signaling about things that are "unsafe" and they know their users are not idiots that need to be coddled.

Hammers and matches are unsafe if you use them wrong.

Re: The Day the Telnet Died

#396

Post by antonvs »

RupertSalt wrote: post #285
Kim_Bruning wrote: post #280

Earlier quoted context omitted.

They're remote terminal applications? Remote interactive text sessions. Over TELetype NETworking? You're saying that connecting my tty (emulator), to a remote host is not the purpose of telnet? Though ... I suppose by now a switch to port 22 could make sense.

No. MUDs should never have adopted port 23 or port 22 or any pre-assigned ports. There is no "well-known port assignment" from IANA for MUD-type games or servers. The end of RFC854, the very last paragraph, states: https://datatracker.ietf.org/doc/html/rfc854 Port Assignment When used for remote user access to service hosts (i.e., remote terminal access) this protocol is assigned server port 23 (27 octal). That is L=…

> I would say that by the letter of the law, and by longstanding convention,

Those are two different things, and you're confusing or conflating them.

"By the letter of the law", certainly if we're just talking about RFC 854, there's no mention of shells, or some of the other constraints you're projecting onto it.

"Remote user access to service hosts (i.e., remote terminal access)" is perfectly consistent with someone accessing a MUD.

When it comes to convention, though, which is influenced by pragmatic issues such as security constraints, you have more of a case.

Re: The Day the Telnet Died

#397

Post by gerdesj »

Twisol wrote: post #11
gerdesj wrote: post #9

telnet isn't just for ... telnet. $ telnet smtp.example.co.uk 25 HELO me MAIL FROM: gerdesj@example2.co.uk RCPT TO: gerdesj@example.co.uk DATA .. or you can use SWAKS! For some odd reason telnet is becoming rare as an installed binary.

The difference between "telnet" the program and "telnet" the protocol is especially important in this discussion, I think. A more "proper" tool for that is netcat -- I doubt SMTP supports the Telnet option negotiations subsystem. (I also doubt SMTP servers can interpret the full suite of Network Virtual Terminal (NVT) commands that the Telnet protocol supports.) There's clearly enough similarity between the two proto…

When I find nc on a customer's Windows box, I'll be sure to use it 8)

Re: The Day the Telnet Died

#398

Post by nedt »

oaiey wrote: post #213
virgulino wrote: post #169

Never mind telnetd. Tier 1 transit providers doing port filtering is EXTREMELY alarming. They have partitioned the Internet, and in a way that automatic routing (BGP) can't get around.

I do not know what is more critical: the risk of censorship or stand by while hospitals, banking, nuclear power plants and other systems become compromised and go down with people dying because of it. These decision makers not only have powers but also have a responsibility

If that really affects them it's better to take them offline.

Re: The Day the Telnet Died

#399

Post by acdha »

charcircuit wrote: post #365
direwolf20 wrote: post #255

Earlier quoted context omitted.

How does that service get launched with the privilege to switch to any user?

The kernel can start a process with any user it wants. The user doesn't have to switch during the process's life.

Yes, but that has to happen somewhere. OpenSSH already uses privilege separation to limit the scope of the code which requests the kernel set the user for the process for the session. Can you say where precisely you think that should happen instead? If you’re saying it should delegate to login(1) it would be useful to discuss in detail what you see OpenSSH doing which is weaker because otherwise that seems like it’s just recreating chances for this CVE without meaningfully improving a hardened implementation.

Re: The Day the Telnet Died

#400

Post by nomel »

FabHK wrote: post #393
nomel wrote: post #164

Earlier quoted context omitted.

Sometimes that doesn't matter either. That is the valid use case of a plain-text protocol like telnet: doesn't matter.

Sure. But, contrary to what some people seem to think, "it's nothing secret" is not a sufficient justification to use an unencrypted plain-text protocol.

It literally is. I do not give a fuck if someone reads or fakes the wind speed from the sensor on my roof.
Post reply on HN