On one hand it is good to be able to mitigate a CVE like this across broad swaths of the Internet via a T1 filtering it, but on the other hand I really don't like middleboxes touching anything other than the IP headers...
This is really interesting, I just wish they got a human to write the article.
The bug sounds really familiar. I swear there was some other piece of software with this exact bug, but I can't find it right now.
Is this sort of filtering precedented? You shouldn't be using telnet over the internet anyways, but this feels like an overstep...
Also, why would AS701 only filter out 79% of the connections? This feels like the obvious question, but they just say "represent paths that don’t transit the filtered links". Yeah, no shit. There's no actual investigation behind this, I'd guess they just pasted the traffic data they already had into an LLM and told it to work with it.
(It's not just the classic LLM tells - the way they present the data twice without really acknowledging it is really odd.)
Basically every residential ISP filters out port 25 to mitigate spam from botnets, so blocking ports and protocols isn't anything new. Lots of ISPs started dropping ICMP Ping once "Ping of Death" became a thing as well, and it took ages until they started unblocking it.
You shouldn't be using telnet over the internet anyways, but this feels like an overstep...
Eh, in a way, it's a niche protocol, of which a major implementation has a "instant root shell" issue, and whose official recommendation is "please stop using this". It's probably better for everyone if the default port used by it is blocked, so you very intentionally have to expose it. Plenty of the ones exposed are embedded devices of one sort or another, so updating them isn't really an option.
(It's not just the classic LLM tells - the way they present the data twice without really acknowledging it is really odd.)
It's a fairly common tell, they get stuck on some pieces of data, and just repeat it to reach a requested amount of paragraphs or words. It's one of the most common things I need to clean up when editing my coworkers' documentation...
There's a difference between an ISP filtering at the edge of their network, and filtering packets that they're routing for different networks.
If my ISP filters something I depend on, I have a contract with them. I can call them up and ask them to unblock SMTP or Telnet or whatever. If they're filtering inbounds packets then maybe you could even sell that as a feature (not that I'd agree that it's one).
If an ISP that's further along the way to my destination filters something out, well, I'm kinda fucked? I don't think there's a reliable way to route around this - I don't think BGP lets you say "hi, I won't route ports X,Y,Z for these prefixes"? (I'm not much of a networking guy, I might be wrong). If you run an AS and want telnet to continue to work, you're up for a bunch of manual work.
Back to the consumer perspective: if someone further along the route blocks a port I'm using, I can't really just call them up. I'm not a customer, I don't have any leverage.
Also, if I call up my ISP and ask for a port to be unlocked, then (hopefully) it's unlocked for good. Here, I'm at the whims of whoever happens to be passing my traffic along at this particular moment.
If my ISP filters something I depend on, I have a contract with them. I can call them up and ask them to unblock SMTP or Telnet or whatever.
I mean maybe if you're a big enough business that losing the account is something they actually care about. Otherwise this seems hopelessly optimistic from my experience with any individual or small business ISP account.
More likely you'd get someone who has no idea what a port is and walks you through rebooting your router 12 times before they can refer you to someone else. Then you get bounced around various contacts none of whom have the knowledge or ability to change anything, until you finally get the one person left who can actually answer the question, but their response is that it's policy and they aren't allowed to make an exception.
Is this sort of filtering precedented? You shouldn't be using telnet over the internet anyways, but this feels like an overstep...
NetBIOS over TCP/IP. Well, at least that's one of the examples I had years ago and now I can't find a good source for that as the topic is swamped by tech advices to disable it on the machine.
It's generated, and then edited by a human (or other sentient being).
If you read a lot of LLM text, or use one, you learn how their output looks, and this contains a lot of common tells ("not A, not B, not C, but D" for various amounts of nots, weird formatting, weird tables, weird rhythm, forced rule of three) but also contains some rewritten portions and extra sentences that have a different style.
Thanks for the hint. Honestly I'm a bit embarrassed, I find the practice really disrespectful to readers' time and wouldn't have shared it if I knew beforehand.
…and another bug is added to the list of completely avoidable bugs if we stopped using shell for calling external processes and instead just passed an argument array.
How are we still seriously using system? Even in APIs that expect an argument list people will just go on ahead and write [“/bin/sh”, “-c”, “…”]! Why do we keep going out of our way to shoot ourselves in the foot?!
Someone upstream of a significant chunk of the internet’s transit infrastructure apparently decided telnet traffic isn’t worth carrying anymore. That’s probably the right call.
I'm struggling to understand how this is the right call. Yes it'll prevent vulnerable systems getting pwned. But people still use telnet for (fun, trivial) things. I'm uncomfortable with the idea that someone unilaterally decided to block it.
OTOH, it does look like they're just blocking port 23, so the easy workaround would be ... use another port.
I don't like it; I mean -- of course such nasty bug should be mitigated, but this is way too heavy-handed. I do get that telnet is more niche every year, but technically axing /all/ telnet access is as if someone turned off http/https ports because reddit presents malware on its front page, and chrome is susceptible to the attack.
pmc | 18 hours ago
On one hand it is good to be able to mitigate a CVE like this across broad swaths of the Internet via a T1 filtering it, but on the other hand I really don't like middleboxes touching anything other than the IP headers...
gerikson | 14 hours ago
What an absolutely amazing bug
https://lists.gnu.org/archive/html/bug-inetutils/2026-01/msg00004.html
The fact no-one found out about it in almost 11 years is probably due to no-one seriously running telnet over the open internet.
lorddimwit | 5 hours ago
What’s hilarious is that the exact same issue was prevalent in the late 90’s (and before). Basically all the commercial Unices were hit.
franta | 13 hours ago
However, fixing such bug through „sanitization“ is a dirty workaround rather than a proper fix.
gerikson | 13 hours ago
Garbi | 2 hours ago
Something like this has got to be right there in the source code. Or, if obfuscated, entirely intentional.
gerikson | 2 hours ago
The patches are linked, along with the discussion from 2015.
dzwdz | 14 hours ago
This is really interesting, I just wish they got a human to write the article.
The bug sounds really familiar. I swear there was some other piece of software with this exact bug, but I can't find it right now.
Is this sort of filtering precedented? You shouldn't be using telnet over the internet anyways, but this feels like an overstep...
Also, why would AS701 only filter out 79% of the connections? This feels like the obvious question, but they just say "represent paths that don’t transit the filtered links". Yeah, no shit. There's no actual investigation behind this, I'd guess they just pasted the traffic data they already had into an LLM and told it to work with it.
(It's not just the classic LLM tells - the way they present the data twice without really acknowledging it is really odd.)
DustyFuzzy | 10 hours ago
Basically every residential ISP filters out port 25 to mitigate spam from botnets, so blocking ports and protocols isn't anything new. Lots of ISPs started dropping ICMP Ping once "Ping of Death" became a thing as well, and it took ages until they started unblocking it.
Eh, in a way, it's a niche protocol, of which a major implementation has a "instant root shell" issue, and whose official recommendation is "please stop using this". It's probably better for everyone if the default port used by it is blocked, so you very intentionally have to expose it. Plenty of the ones exposed are embedded devices of one sort or another, so updating them isn't really an option.
It's a fairly common tell, they get stuck on some pieces of data, and just repeat it to reach a requested amount of paragraphs or words. It's one of the most common things I need to clean up when editing my coworkers' documentation...
dzwdz | 7 hours ago
There's a difference between an ISP filtering at the edge of their network, and filtering packets that they're routing for different networks.
If my ISP filters something I depend on, I have a contract with them. I can call them up and ask them to unblock SMTP or Telnet or whatever. If they're filtering inbounds packets then maybe you could even sell that as a feature (not that I'd agree that it's one).
If an ISP that's further along the way to my destination filters something out, well, I'm kinda fucked? I don't think there's a reliable way to route around this - I don't think BGP lets you say "hi, I won't route ports X,Y,Z for these prefixes"? (I'm not much of a networking guy, I might be wrong). If you run an AS and want telnet to continue to work, you're up for a bunch of manual work.
Back to the consumer perspective: if someone further along the route blocks a port I'm using, I can't really just call them up. I'm not a customer, I don't have any leverage.
Also, if I call up my ISP and ask for a port to be unlocked, then (hopefully) it's unlocked for good. Here, I'm at the whims of whoever happens to be passing my traffic along at this particular moment.
abeyer | an hour ago
I mean maybe if you're a big enough business that losing the account is something they actually care about. Otherwise this seems hopelessly optimistic from my experience with any individual or small business ISP account.
More likely you'd get someone who has no idea what a port is and walks you through rebooting your router 12 times before they can refer you to someone else. Then you get bounced around various contacts none of whom have the knowledge or ability to change anything, until you finally get the one person left who can actually answer the question, but their response is that it's policy and they aren't allowed to make an exception.
adrien | 13 hours ago
NetBIOS over TCP/IP. Well, at least that's one of the examples I had years ago and now I can't find a good source for that as the topic is swamped by tech advices to disable it on the machine.
[OP] addison | 10 hours ago
Wait, this is generated? I didn't get that impression at all, just thought it was a short article presenting an interesting network event.
DustyFuzzy | 10 hours ago
It's generated, and then edited by a human (or other sentient being).
If you read a lot of LLM text, or use one, you learn how their output looks, and this contains a lot of common tells ("not A, not B, not C, but D" for various amounts of nots, weird formatting, weird tables, weird rhythm, forced rule of three) but also contains some rewritten portions and extra sentences that have a different style.
[OP] addison | 9 hours ago
Thanks for the hint. Honestly I'm a bit embarrassed, I find the practice really disrespectful to readers' time and wouldn't have shared it if I knew beforehand.
pta2002 | 12 hours ago
…and another bug is added to the list of completely avoidable bugs if we stopped using shell for calling external processes and instead just passed an argument array.
How are we still seriously using
system? Even in APIs that expect an argument list people will just go on ahead and write[“/bin/sh”, “-c”, “…”]! Why do we keep going out of our way to shoot ourselves in the foot?!duncan_bayne | 17 hours ago
I'm struggling to understand how this is the right call. Yes it'll prevent vulnerable systems getting pwned. But people still use telnet for (fun, trivial) things. I'm uncomfortable with the idea that someone unilaterally decided to block it.
OTOH, it does look like they're just blocking port 23, so the easy workaround would be ... use another port.
sknebel | 7 hours ago
FWIW, seeing commentary from various people who'd know that they can not observe this T1-level filtering actually happening.
jackdaniel | 10 hours ago
I don't like it; I mean -- of course such nasty bug should be mitigated, but this is way too heavy-handed. I do get that telnet is more niche every year, but technically axing /all/ telnet access is as if someone turned off http/https ports because reddit presents malware on its front page, and chrome is susceptible to the attack.