The Sins of the Past
Duck and David take an informed and entertaining look at “the sins of the past” – long-standing bugs and blunders that we could so easily have avoided, but didn’t
If the media player above doesn’t work in your browser,
try clicking here to listen in a new browser tab.
Find TALES FROM THE SOC on Apple Podcasts, Audible, Spotify, Podbean, or via our RSS feed if you use your own audio app. Or download this episode as an MP3 file and listen offline in any audio or video player.
[FX: PHONE DIALS]
[FX: PHONE RINGS, PICKS UP]
ETHEREAL VOICE. Hello, caller.
Get ready for TALES FROM THE SOC.
[FX: DRAMATIC CHORD]
DUCK. Welcome back, everybody, to TALES FROM THE SOC.
I am Paul Ducklin, joined as usual by David Emerson, CTO and Head of Operations at SolCyber.
Hi there, David.
DAVID. Hey there.
DUCK. This episode’s topic is THE SINS OF THE PAST.
And what minded me to choose that topic is an article that we just published on solcyber.com/blog with the exciting-sounding title: Now THAT’S what you call a bug! Root with no password․․․
But the real problem with this is not just sloppy programming that is essentially a good old command-injection attack.
The problem is that the software involved isn’t getting any attention, and isn’t getting patched.
Because anybody who’s anybody should have stopped using this protocol․․․ 25 years ago, perhaps?
Because the bug is in the GNU InetUtils project, in the telnetd server for the TELNET protocol, which dates back to 1983 and was essentially superseded by SSH (secure shell), in 1995.
All the things that you used to do with TELNET, SSH is designed to do with a layer of security, and OpenSSH is free in all senses of free.
Every Linux distro includes it; every BSD distro includes it.
Windows 11 includes it; macOS includes it, client and server.
Yet we still have TELNET, which is basically, “Hey, let me send my username, my password and all my data back and forth across the network, entirely open and in the clear for everyone to read.”
DAVID. It’s pretty crazy.
Legacy protocols like this, and legacies in general, persist because they work, or they did at one time.
DUCK. Yes.
DAVID. They persist because of inertia.
And in some cases, I think especially something like TELNET, they persist because of an “internal network” fallacy.
DUCK. Indeed.
DAVID. The fallacy that there is a perimeter.
The persistence of this bug, if anyone knew about it in 1998, let’s say, assumes that the perimeter holds.
It assumes that you don’t have access to the ability to exploit this unless you’re already in a position of having compromised the network.
I don’t think that was a good assumption then, and it sure as heck isn’t one now.
I think those are the reasons that legacy protocols persist.
They work; they have inertia; and there’s an internal network fallacy.
And those are not acceptable reasons in 2026.
DUCK. But that’s only true if no one compromises your network, or you don’t get malware on any of the computers that are already plugged in, right? [LAUGHS]
DAVID. Right.
I think it’s more when people logically attempt to employ this, I think it’s more the latter, which is they’ll often justify not taking a measure because if someone has the ability to exploit a particular known vulnerability, they may already be so deep in your network as to be able to exploit other things, which would be more unstoppable or more critical.
I agree with that premise, but it has to be employed very carefully.
And I what I don’t agree with is that that is alone your sufficient defense.
In 2026, in an age where zero-trust exists, it may be true that you are screwed in 10 other ways if someone already has the ability to plug a device into your network.
But it isn’t true that they need to have that ability in 2026.
That is really, I think, the intellectually lazy part of that kind of analysis.
DUCK. Because the problem with this bug, basically, the telnet client lets you say, “Log me in, but I don’t want to be myself; I want to be some other user.”
And it turns out, in this case [LAUGHING], that if you pass across a username which consists of your username, followed by a space, followed by the magic command-line option that means “ignore all requests for authentication,” then the other end will obey, and it will let you in.
So you just go telnet -l 'root -f', and you’re straight in.
And that means that even a tiny blunder on one part of the network where network traffic can be created turns into a root level compromise on some other computer, which is probably a server.
That’s the problem with still believing in the idea of a perimeter.
DAVID. The other problem with still believing in the idea of a perimeter is that in 2026 it’s unnecessary.
DUCK. Yes.
DAVID. I’ve spent some time in the zero-trust world, and my favorite thing about the zero-trust world is that you can make almost anything a “network of one” today.
Your ability to exploit the machines around you drastically drops.
You go into an office with a zero-trust network, and you decide to exploit their printer.
And you’ve compromised their printer, because that’s what you had access to as a guest, let’s say.
Well, in an office with a zero-trust network, I guess you’re just being a jerk, because․․․
․․․great, you’ve exploited the printer, but that’s it.
You’re not going anywhere; you’re not pivoting to another machine.
You’re not exploiting some neighboring segment – you’re in a segment of one.
And that is how a properly functioning zero-trust network works.
And that’s also how a properly functioning security architecture deflects attacks that rely on this kind of systemic vulnerability.
You just don’t need to put up with that in 2026.
It’s not necessary to deflect it logically by saying, “Well, we’re screwed if they have physical access anyway.”
No!
Everything is in its own segment in a world that is properly architected.
Everything is a segment of one, and you don’t have this kind of “coincident exploit.”
DUCK. So essentially, you’re doing in what you might call virtual terms, with firewall-style software, firmware and rules, what you used to do by not plugging this cable into that port in some switch or rack in a server room?
DAVID. Essentially, yes.
The flexibility we have in designing architectures which are resilient in the face of that kind of attack is so much greater.
SSH in 1995 was computationally expensive.
SSH in 2026?
It’s not even noticeable – you don’t notice the slowdown, because it’s passed to hardware to actually do the encrypt/decrypt operation.
DUCK. It’s funny you mention that!
OpenSSL, the very widely-used crypto library, yesterday as we’re recording this, pushed out an update to 3.6.1.
They ironically have a bug in some modes of operation of the AES cipher where, if you’re using hardware acceleration, the code may leave anywhere from 1 to 15 bytes at the end of a chunk of data both unencrypted and unauthenticated.
DAVID. Oh, weird.
Oh, that’s very weird. [LAUGHS]
DUCK. It is very weird!
Fortunately (although that’s not specifically relevant to this podcast, but I thought I’d mention it because it’s interesting), the cipher that’s affected is one that is not supported by TLS, or what some people still call SSL.
DAVID. Yes.
DUCK. So you can’t have the problem if you’re using OpenSSL to manage an encrypted network connection.
It’s only if you’ve got some custom encryption code.
DAVID. In some ways, though, actually that anecdote does kind of relate back to the TELNET vulnerability, and why legacy protocols can be a problem, and also why, I think more to the point in this case, “clever tricks” can be a problem.
DUCK. Yes!
“Hey, let’s do this slightly differently, in a way that has not got much attention in the past because nobody’s really doing it.”
DAVID. Right, yes.
DUCK. “So let’s use this weird cipher mode just to be cool, just to be different.”
DAVID. In TELNET’s case, you know, it was demi-shell parsing, or whatever it’s called.
DUCK. Yes. [LAUGHS]
DAVID. You had a clever trick, and it seemed like it was sensible, but boring but safe would have been a better approach.
Because boring but safe would have been upgraded into the modern era.
I do see that all the time in designs.
Designs of systems are frequently ignorant of the ways in which they’re going to age poorly.
DUCK. Absolutely.
DAVID. Maybe you thought it was absolutely crucial to use that algorithm, but if you didn’t have a good reason․․․
․․․fast-forward 20 years, and now you’ve got a vulnerability on your hands.
DUCK. Well, that’s reflected in the TLS protocol standards, isn’t it?
For example, TLS 1.2 had a dizzying matrix of allowable combinations of cipher, and hash, and public-key algorithm.
So when we went forwards to TLS 1.3, we deliberately took numerous steps backwards in complexity to reduce the number of allowable combinations.
With the aim of making it less likely that people will choose outlier weirdnesses, and of making it feasible, practicable, useful to be able to test all possible combinations.
Which just isn’t possible if you have a zillion exceptions, is it?
DAVID. No, it really isn’t.
And even in the TELNET vulnerability you see what I would call a code review blind spot.
There was a stack overflow of one byte that was found – probably not exploitable, but nonetheless interesting and should be fixed.
But meanwhile, here we are in 2026, and there’s a logic bug missed.
A massive hole.
DUCK. That bug was put in just over 10 years ago, and it hasn’t been removed.
But you can’t really blame the GNU project or anybody who’s put effort into InetUtils in recent years.
Because (A) which contemporary programmer would want to invest their time and effort in what is essentially seen as a dead end?
And (B), who’s paying any attention, even to the point of the most modest sponsorship or recognition, for people who are doing that?
Why should they take the trouble to review these thousands and thousands of lines of code when the real solution is that the rest of us stop using that code altogether?
Because the protocol is insecure and, as you say, in 2026 entirely unnecessary.
DAVID. Yes, I don’t blame the project.
I think the two problems are distinct.
The problem of companies continuing to use TELNET is really a problem of how do you escape technical debt without breaking production, and how do you incentivize companies and users, essentially, to move on?
To change their embedded devices, and to update their protocols and the services that are being run to something more modern.
DUCK. You mean that people are afraid that if they change anything, even a tiny bit on some ancient systems, they might break unrecoverably?
DAVID. Yes.
DUCK. And then they’ll be in a worse spot than maybe getting compromised by crooks sometime in the next few years?
DAVID. Particularly the systems that TELNET is used on.
DUCK. Yes. [LAUGHTER]
DAVID. Just to give an example of which I’m aware, TELNET is used in Lutron RadioRA.
It’s a commercial light control system.
So, if you have control systems in a hotel that you want to run for the amenities, or the lights, or the temperature, or whatnot, Radio RA is by default running over TELNET.
It’s frightening, and it’s effective, and it’s worked for 30 years now.
That is a crazy situation that is extremely typical of industrial control systems, and embedded systems, and systems that probably have a lot of installed legacy.
And even if they are under active development, which it is, probably aren’t so free to pivot without breaking compatibility with the past.
DUCK. Yes, because with something like TELNET, if it’s different vendors at each end of that link, both of them have to change.
If one of them goes ahead and the other doesn’t, they’ve kind of cut themselves off from one another.
So I guess the temptation is, “Let’s do nothing.”
It’s cheaper, quicker, and guess what?
It actually works.
DAVID. Right.
DUCK. In a way.
DAVID. And then, on the code review side of things, the point that I’m mostly making is that QA, regression testing, fuzzing, actual practical logic testing, is seen as a luxury activity.
That isn’t always appropriate – there are some systems that it is appropriate to do rigorous actual logic testing, or rigorous actual regression testing on.
And it might reveal bugs that aren’t as simple as, “Let’s fix everything in the dependabot, and that’ll take care of all of our static problems, or our stack overflows, or whatever.”
It isn’t as simple as that.
And it’s really lost on a lot of the budgetary authorities.
When you propose something like that for almost any product, no matter how critical, the answer is, “Naaah, we can’t afford QA; we can’t spend the time.”
There really do have to be systems for which it’s worth the effort.
And TELNET, or more broadly remote access, is one of those systems.
DUCK. It’s intriguing when you’re talking about radio systems, say as used in hotels, that rely on TELNET.
The fascinating thing there is that I bet that if you just do some completely random fuzzing against the system, what will happen is clients and servers will crash and restart.
The system will probably feel as though every time something goes wrong, it will fail safe and restart.
And it’s almost as though what would be more interesting is, “How hard can you fuzz this thing and yet somehow it still seems to work?”
Because when that’s happening, it probably means that it’s working for the wrong reasons, and that there are side-effects that are happening that you haven’t noticed because the rest of the system seems OK.
Would you agree with that?
DAVID. Oh, of course.
DUCK. And you can’t just expect people to volunteer when there’s very little in it for them, particularly if you think about something like this InetUtils project.
The people who are most likely to care about it are the people who are also most likely to think, “We shouldn’t waste our time on that.”
There are more important things to do, given that the correct solution is to stop using this protocol altogether, rather than trying to fix software that still supports it.
DAVID. I imagine someone at Lutron right now, in their commercial RadioRA division․․․
DUCK. [LAUGHS]
DAVID. ․․․is thinking real hard about “the sin of the past,” so to speak, and considering what it means.
DUCK. I suspect they probably didn’t use this particular implementation, because of the way it’s done.
It assumes a fully-fledged Unix system, so they probably have a very stripped-down version of their own.
DAVID. Perhaps. [LAUGHS]
You know, you say “fully-fledged Unix system” as though that’s something unachievable at scale.
But the reality is I can get a Pi Pico Elite running what would be considered fully-fledged Unix for $13.
DUCK. Yes.
DAVID. You can really get some very inexpensive, so-called fully-fledged systems at this point.
DUCK. And if I remember correctly, because I set this up on Windows Subsystem for Linux for myself recently, the basic root file system that you need for Alpine Linux is․․․ [LAUGHING] 3 megabytes of stuff?
DAVID. Exactly.
DUCK. It’s like a busybox program and a few scripts.
DAVID. We’ve seen that for years, though.
I remember when Radware load balancers went from VXWorks to Linux, and I remember the reaction back then was, “Why?”
Because VXWorks is a real-time operating system; it’s minimalistic, high throughput, very high performance.
But the fact of the matter is, somewhere around 2012 or 2013, hardware had gotten so cheap, and VXWorks was no longer a massive advantage over Linux on inexpensive hardware that was commodity.
Companies like Radware were no longer basing their load balancers on VXWorks and instead expanding to this inexpensive, general-purpose compute model that happened to do load balancing.
That mentality is rife with surface area that probably didn’t exist previously.
What would not have been a vulnerability in VXWorks because it didn’t exist can absolutely exist in Linux.
Because it’s a whole OS sitting on your on your disk, and can absolutely exist in your thermostat nowadays.
$13 later, someone has a fully-fledged Unix system in your thermostat now.
There are real downsides to increased functionality, and many of them are increased risk profile.
DUCK. Yes, and more and more dependencies, and, “Hey, this project’s been out there for years and years and years. Loads of people have used it. Let’s just suck it in with loads of other things and hope it’s all going to be right.”
Now, David, I’m conscious of time, so perhaps we can finish up with you summarizing what people can do so that they minimize their exposure to what we’ve called “the sins of the past.”
Obviously in the article, I spoke very passionately about, “Get rid of TELNET – you don’t need it.”
But that’s a very, very specific thing that probably doesn’t apply to many people because they’re not using TELNET anyway.
So, as a general rule, what should you do to look at your environment, to classify your risk, and to make the most useful changes?
DAVID. At a high level, I would explain to yourself why legacy protocols persist.
The biggest reasons are: inertia; “it works”; and the internal network fallacy.
DUCK. Yes.
DAVID. Think about, in your environment, why legacy protocols are persisting.
Those may be good reasons; those may be bad reasons.
But that will be informed by your risk profile.
Up-level your activities when it comes to code review; when it comes to security review.
Don’t get caught in the weeds looking for a stack overflow when what you’re missing is something way more fundamental.
DUCK. [LAUGHS] Yes.
Sometimes less is an awful lot more, isn’t it?
DAVID. Yes, less is absolutely more; it’s easier to review.
But just generally speaking, don’t get in the weeds about really esoteric exploits, because a lot of times it’s obvious stuff, nine levels up from a stack overflow, that is killing the day for you.
And then the last thing would be the danger of clever tricks.
I think that is really common.
I think it’s part of why legacy protocols persist, but it’s also part of why infrastructures age poorly, or designs age poorly.
Clever tricks sound cool at the moment, or seem necessary at the moment.
Fast-forward 20 years, and how maintainable and how standards-based is the thing you’re building?
Make sure it gets dragged naturally into the future, rather than awkwardly or not at all.
That’s an important design consideration.
DUCK. And that can actually tie you to legacy protocols, can’t it?
DAVID. Yes.
DUCK. Some of those tricks may quite deliberately have been excluded from more modern protocols because of the risk they posed.
DAVID. Yep.
DUCK. And if you’ve baked that into your infrastructure, then it’s much, much harder to get rid of
it later.
DAVID. I’m not going to say “never,” because there are clever tricks that are justified.
But justify them, with a neutral eye toward good design and minimalism.
Don’t just do a thing, like pin a cipher, because you make the assumption that that cipher is forever good.
Almost nothing is forever.
DUCK. [LAUGHTER]
DAVID. A decision like that will likely age poorly.
DUCK. So David, if I can finish up by summarizing everything into two words, would these two
work?
“Intentional design.”
DAVID. Yes.
It’s a meta-reason – your reason will quickly become to fix the thing that you had no reason for.
DUCK. [LAUGHTER]
Or perhaps I should say, “When in a hole, do not continue digging.” [LAUGHTER]
“Seek ladders.”
DAVID. Right.
DUCK. David, thanks so much for your time.
I had great fun with this episode because we got to talk about some things that we don’t normally get to talk about.
I hope you enjoyed yourself.
I hope everybody enjoyed tuning in and listening, for which we thank you very much.
If you enjoy this podcast, please subscribe; that way you’ll know when every new episode drops.
Please like and share us on social media – that helps us a lot.
Please recommend us to your friends, your family, your colleagues, and especially to your boss.
Please take a look at solcyber.com/blog, where we have some excellent, human-centered, community-oriented advice that’s useful both at work and at home.
And don’t forget․․․
Until next time, stay secure.
DAVID. Bye all.
[FX: CALL ENDS]
Catch up now, or subscribe to find out about new episodes as soon as they come out. Find us on Apple Podcasts, Audible, Spotify, Podbean, or via our RSS feed if you use your own audio app.
Learn more about our mobile security solution that goes beyond traditional MDM (mobile device management) software, and offers active on-device protection that’s more like the EDR (endpoint detection and response) tools you are used to on laptops, desktops and servers:
By subscribing you agree to our Privacy Policy and provide consent to receive updates from our company.
