Solaris Telnet 0-day vulnerability

philos writes "According to SANS ISC, there's a vulnerability in Solaris 10 and 11 telnet that allows anyone to remotely connect as any account, including root, without authentication. Remote access can be gained with nothing more than a telnet client. More information and a Snort signature can be found at riosec.com. Worse, this is almost identical to a bug in AIX and Linux rlogin from way back in 1994."

Why is this a big deal?

Who the hell even THINKS about enabling telnet on any box these days?

Re:Why is this a big deal?

Quicker than SSH? What the hell? Are you streaming video over your SSH connection or what?

I think GP is referring to the initial connect handshake. Oh no, it takes an extra 500ms to establish a secure connection. If your network is private enough to feel safe using telnet, you can certainly set up RSA/DSA keys to use SSH without a password, eliminating the time it takes to enter it.

Re:Why is this a big deal?

Vendor support for ssh is one factor. Many companies have aversions to installing software unless it's backed by FULL support from the vendor. Having to go to a third party, like F-Secure, to get vendor support is often undesirable, and unfortunately, security can lose to support requirements, service level agreements and response time. Even worse is that there's multiple and sometimes incompatible versions of SSH out there - what may come with one system isn't guaranteed to work with another.
Can you get the OS vendor to jump and have a man there within 30 minutes to fix it if a supported OS function doesn't work? Yes. Can you get the OS vendor to jump and have a man there within 30 minutes if OpenSSH doesn't work? No. Sometimes it's as simple as that, unfortunately.

That said, don't think that I believe telnet is a good substitute for ssh, but often, and especially in a turtled environment (hard on the outside, soft on the inside) where five nines are more important than internal security, it may still be a better choice, at least until all the OS vendors provide fully supported (and compatible!) versions of SSH.

Re:Why is this a big deal?

Security best practices are the same whether you're talking about securing your home network or a military network

No. It's not. The only thing those have in common is considering what you are protecting, and how much risk you wish to take versus the convenience granted. The specifics are immaterial.

The OP is right, he knows his risks and has deemed it acceptable. You and others, having no idea of the risk, deem it unacceptable and are the ignorant ones.

Re:Why is this a big deal?

If ssh on your cisco boxes is slow, you either have serious network problems [...]

Most likely, the reverse DNS is misconfigured. This is the number one reason for ssh-login delays. Maybe, the nameservers initially put into the router's configuration are no longer reachable due to subsequent "hardening". Or, maybe, they went away and were replaced long ago — without anybody telling the routers. Nothing else on a router uses DNS usually, so this problem affects only ssh-daemon and gets blamed on it...

The daemon could, of course, be a little bit smarter and not try to do a reverse DNS, when there are no hostname-based authorization rules in the first place... But that's a minor bug compared to reverse DNS being dysfunctional.

Re:Why is this a big deal?

except it's not... (at least not as of the 10/06 release)

Re:Why is this a big deal?

Since the exploit site didn't yet have information about older versions of Solaris/SunOS, I hope it can quench the panic for some when I say that only Solaris 10+ appears to be affected.

If you're on Solaris 8 (SunOS 5.8 or Solaris 2.5.8) or 9 (SunOS 5.9, or Solaris 2.5.9), you appear to be safe.

This is relevant because large companies seldom jump to the newer versions until they have to - for production systems, as long as the older versions are supported and working, that's more important than gambling on existing software still working if upgrading the OS. So there's an awful lot of systems with Solaris 8 and 9 out there, but luckily they appear not to be affected.

Re:Why is this a big deal?

Relevant line from /etc/services:

telnet 23/tcp imadumbass hackmenow rootrus rotflmao

Re:Why is this a big deal?

I do. And then I sit down naked in the snow and castigate myself with a 9-tail as a punishment for these impure thoughts.

Having said that, today is a good day to find out if that head of IT you never liked anyway has telnet enabled on one of his Solaris machines :)

Re:Why is this a big deal?

Let me take a crack at this:

1) Fermi National Accelerator Laboratory.

That'll account for a couple thousand computers. It's left as an exercise for the reader to find other sites.

Are they just crazy? I know that almost every single box at FNAL has the telnet daemon running, and is behind no firewall. Why aren't they hacked-to-death? Kerberos.

FNAL has a policy that every service beyond central IT's web pages is protected by Kerberos. The Kerberos-enabled version of telnet is as secure as one can get; I've been told by their sysadmins that it is more secure than SSH because it is simpler and the network and authz/authn stacks are separated. So, historically, Kerberos-enabled telnet has had less bugs than SSH.

Just because YOU don't run telnet (or don't know how to run it securely) doesn't mean that there aren't thousands of boxes out there that are secured by it.

If there are actually any Sun boxes at FNAL (they were one of the original big adopters of Linux), you can bet they'll probably be turned off today...

Re:Why is this a big deal?

Sounds like they're more interested in watching their own employees than in securing their systems from external threats.

If it were me I'd just log everything in every session (which is easy), and make the users use SSH. That way you can audit everything they do, every command they type, but still have a level of security. You have to remember that any user can sniff telnet traffic on the network, so forcing everyone to use telnet because you don't trust them means the ones who are untrustworthy have a better chance of stealing something useful from a coworker.

Even better would be to hire trustworthy people and treat them as such in the absence of evidence to the contrary.

Re:Why is this a big deal?

Just because the login is "safe" doesn't mean that using an unencrypted protocol is ever a good idea.

You're right... No more secure websites for you, since HTTPS is just HTTP over an SSL data stream.

You could just as easily use Kerberos to encrypt HTTP traffic as SSL, and that is indeed exactly what Kerberos does for just about any communications protocol...

Kerberos telnet is as encrypted as it gets.

Re:Why is this a big deal?

Who the hell even THINKS about enabling telnet on any box these days?

Sadly, a whole lot of people. I work for a company that makes very expensive and cool specialty servers that perform certain security related functions. As a security company, naturally we take care not to tarnish our reputation by leaving these servers vulnerable themselves. We try to encourage our customers to be moderately responsible as well, as any box can be made insecure. I know of at least on tier-1 ISP that has one of our boxes sitting publicly accessible with telnet enabled and no IP access restrictions.

As for who uses telnet in general, most ISPs in Asia seem to use telnet to configure their systems via their control networks. Large financial institutions in Europe use telnet, as use of encryption is restricted on their trusted networks, for reasons of transparency to the stock regulating authorities. ISPs in South America often use telnet and provide shell accounts to customers. I'm sure there are more groups that use it for one reason or another.

Telnet?

Does ANYONE run telnet anymore? There has been no need to run telnet for at least 10 years. If you ARE nuts enough to run it, you would would be even more nuts to have it open to the internet. Can anyone confirm if telnet is enabled by default on Solaris for new installs? I would doubt it - I haven't seen telnet being enabled by default on any unix flavor in at least a decade.

So what?

Why would anyone keep the telnet port open anyway? SSH is so much more secure (if set up properly) and is just as easy to use. In fact, I find it easier for some tasks.

Hasn't telnet been the source of many dozens of *nix vulnerabilities in the past? From the synopsis, it sounds like this bug is only there because nobody is working on the telnet codebase anymore - it is likened to the Linux exploit from '94. For my own part, the first thing I do when setting up a *nix system is disable the daemon, and the second is to make sure the firewall blocks the port in all directions.

This is not to say this shouldn't be reported, but I think it is more an example why telnet can realistically be considered obsolete technology, and should always, ALWAYS be disabled by default. It's not Windows, after all.

Configuration issue

They give the correct configuration to mitigate the problem. This is kind of a non-story. What's next, a SANS article detailing a "bug" which allows you to set root's password to null, and then anyone can ssh into the machine as root?

Re:Configuration issue

Since apparently Sun is negligent enough to have telnet enabled by default, it is an important story. This reminds me of the old NT4 days, where every service on the machine was enabled by default, and the first thing you had to do was turn everything off. Come on Sun, get with program here...

Re:Configuration issue

The article talks about Solaris 10 u1 released in 2005. The latest thing is u3, which has two things:

1) this attack does not work:

Escape character is '^]'.
Not on system console
Connection closed by foreign host.

2) when installing U3 one can opt to close most services. This could be also done after installation with "netservices limited" command.

Re:Configuration issue

This is only because root is not allowed to log in remotely by default. "-fanyotheruser" will still work. I believe the current favorite is "-fbin". Also, if you've commented out the console line in /etc/default/login, it will allow access to root.

This has been confirmed on the latest version of Solaris 10.

not an excuse

"Nobody should be using it anyways" is not an excuse. If it is included, it should be held to the same standard as every other application. In some legacy cases I'm sure telnet is of some use. But regardless the fact that it has a practical use or not is irrelevant.

the authors seem very confused ...

First they say there's a bug with telnet passing switches through to login.
Then they start a tirade against sending passwords in the clear.
After that they say the fix is not to use telnet.

Putting aside the holier (more secure) than thou attitudes here about telnet security. I've got to say that not using something because it's broken is never a fix (unless you're a manager). The fix is to mend the problem. In the meantime, maybe, avoid the service. but bear in mind, someone still has to fix it.

OpenSolaris as a development model

This seems to be a good example of both the benefits and drawbacks of an open development model.
The good news is that a third party has informed Sun of the info, who will now fix it.
The bad news is that we have no idea how long people have known about this problem...

0-day?

Maybe I'm just confused, but doesn't '0-day' mean the exploit was found the day the code in question was released?

I generally don't follow Solaris, and 11 might have just come out, but I seriously doubt 10 and 11 both came out at the same time.

Re:0-day?

No, zero day means that an exploit was released before or on the same day as the vendor / community found out about it. Ethical security researchers notify the vendor first, and at LEAST give them a few days / weeks to resolve the problem before releasing the full details to the public.

Off By Default

Actually, recent revs of Solaris install with daemons for remote services (including TELNET) not running unless the individual performing the install explicitly requests the legacy behavior. (Previous versions, as with most *NIX operating systems, enabled most remote services by default.) Typically, therefore, there is nothing to "fix."

The Exploit

Since noone seems to have bothered posting it yet, "telnet -l -frandomuser randomsolarishost".

So stupid.

what???

I didn't know anyone still used Telnet. Personally, I gave up that bad habit a long time ago when there was a need to do big things like not have your authentication credentials pass in plain text. Seriously, why is this an issue? Any competent unix sysadmin will be using SSH. The first thing I do when setting up a new unix server is to visually verify that the telnet daemon has been turned off or comment it out in the inetd.conf. Sounds like some attempt at FUD against a very stable, mature, and good operating system. This article is just, well, a moot point.

We're not in the 90s anymore

Coming from a dot-com background, it was a given that telnet was disable and replaced with OpenSSH or something similar. I'm amazed though at how many large companies are still running telnet. Sure, they have most of their servers behind firewalls, but since the largest number of breakins are still attributed to internal hacks telnet needs to be considered obsolete.

Didn't work on Solaris 10 01/06

rhlinux1:~$ telnet -l"-froot" solaris
Trying 172.16.141.27...
Connected to solaris.example.com (172.16.141.27).
Escape character is '^]'.
Not on system console
Connection closed by foreign host

This is basically a vanilla install.

Woah..

It takes this to make windows look secure :)

I just got this in my inbox from Microsoft

To: You Unix Communists
From: Steve Ballmer
Subject: Pwned
Body:
Microsoft:1 - Unix: NIL LOLOLOLOLOLOL!!!!!!!111

:)
Love Steviepoo

Must not be evil .....

Solaris 5.10 is run at our University and telnet is STILL running. I might as well login to telnet as root and shut down telnet, though that I'm sure would be seen as naughty.

There is no valid reason

to be using telnet, and there hasnt been for about the last 5 years easily. I will say again, there is no VALID reason to use telnet. If you want to try and defend your use of telnet, I think you should spend the time looking for a new career in some riskier field because you apparently enjoy unnecessary risks. and that is all telnet is, an unnecessary risk, it has no place on a server, on a network, on a computer at all.

yeah right....

... if there is a single unix admin running telnetd on a non-firewalled, internet-connected machine they deserve to be shot, until they are dead.

... and then shot again.

Guh!

I bet this is still a problem on most other flavors of commercial UNIX, too. I found it for DG/UX back in '96 while reading the source code to their telnet server (I was doing security auditing for them at the time.) Their server was pretty much unmodified from the original AT&T code. The fragmented UNIX industry insures that this problem keeps cropping up even though it's been documented for a solid decade now. And what's worse, most UNIX vendors still ship their machines with telnetd enabled.

Data General's proactive approach to security (Actually having people read through and test all their code) turned up a lot of problems that would otherwise have gone unnoticed and would probably have been exploited at a later date. Perhaps the other commercial UNIX vendors should consider that approach rather than relying on code that no one's looked at in 20 years to be secure.

MUDs ok?

This bug is for Solaris telnet only, correct? So MUDs and others which are using the protocal without telnetd are ok?

Credible Source?

The linked description does not seem to have any references to other descriptions of this vulnerability, nor do they seem to be showing up in Google or in the normal security channels. Anyone have a link to some real information on this. If this is truly a zero-day situation who was exploited and what are the details of the exploit? Was this a manual exploit or a worm?

I have no reason to doubt the linked description, but it is pretty vague. Where's the beef?

I'm trying to think...

I'm trying to think of some good reason someone might still have telnet, ftp, or some other unencrypted service running on Solaris. The only reasons I can think of are not good--legacy apps are NOT a good reason. If you can't do it over an SSH tunnel, then you shouldn't be doing it.

Maybe the Solaris patch team figured the same thing.

What I'd do, if ...

... I had a say in SUN: Sack the responsible for security.
No, not for cheap repay !

Not for the vulnerability as such. Not for the forgotten validity checks. Not for eventually shipping telnetd.
(Only Theo & friends can permit to not ship it.)

But:
  - For enabling it by default; at install; in 2007
  - Worse: for still not running it unprivileged; though that is possible

A blast from the past!

Yow! I remember hacking a fix together for the AIX hole over a decade ago with a little shell script [security-express.com] that I threw together.

A similar fix would probably work now if anybody cared, but I imagine Sun will fix the hole properly quickly, probably more quickly than IBM fixed theirs back when, and not many people have telnet enabled on Internet-facing machines anymore anyways, but even so, it's amazing to see basically the same hole over ten years later. Linux has had similar problems too -- I believe the root source was Julianne/John F. Haugh's shadow suite [debian.org] back then, and I wonder if it's still the original source here.

telnetd NOT on "by default" in Solaris 10

When you install Solaris 10, you are prompted for how you want remote access to the box initially configured. This is done in phase 1 of the install, running off the install media.

You can either turn on everything (telnetd, ftpd, etc, etc), or only have sshd running when the box comes up for the first time.

So saying that telnetd is on "by default" isn't exactly correct, unless your definition of "by default" is "explicitly enabled".

- Roach

At least it's not a LD_PRELOAD bug

When I have first seen this article I thought, LD_PRELOAD bug is back -- old telnet allowed the remote user to pass environment variables including LD_*, so it will run login (as root, of course) with whatever library user had previously uploaded on the host, thus bypassing authentication.

This is... -froot indeed...

In related news...

The ping of death made a brief comeback in Solaris 10 [sun.com]. I find both vulnerabilities funny. Don't ask why.

New advertising slogan;

The Network is Everyone's Computer.

Sun: Woefully inadequate - no excuse

I can't believe a large Unix software vendor with years of experience can get it wrong with some trivial, well understood protocol application designed over 35 years ago. Doesn't give me much confidence in Sun OSs I noticed the snippet about Solaris 10 being vulnerable to "ping of death" attacks before a "patch" came out. Mind you they have never been very good at network stacks. Ever. .. You can probably tell I use Linux ...

Solaris 10: Simple fix to this

There are simple ways to secure this:

I have CONSOLE=/dev/console set in /etc/default/login.

telnet -l"-froot" 10.24.47.9
Trying 10.24.47.9...
Connected to 10.24.47.9.
Escape character is '^]'.
Not on system console
Connection closed by foreign host.


And turn off telnet. Do: svcadm disable svc:/network/telnet:default as root.

And yes! It is STILL BETTER THAN P.O.S. Windoze!!!
--
Zombie Proc

What idiot still uses telnet on a unix box

First off, I assume the problem is with telnetd, not telnet.

Second, anyone that would still use telnetd on a unix system is not competent to be a unix admin in this day and age. (And no, Im not talking about using the telnet *client* to access hardware devices such as routers locally or to connect to SMTP for testing, etc; Im talking only about allowing inbound login from the public Internet via telnet to a unix system where security is evem remotely important)

WOW...

I must Say Wow. Such a big security hole. I had a couple of spare Solaris 10 servers that I tried this out on and to my surprise wow. Its a good thing that I don't enable telnet on any machines. Thanks for the post though. Cheers, Thusjanthan Kubendranathan

Telnet flame war

I started reading the posts and then realized that most of it degenerated into an anti-telnet flame war.

It is possible to use SSH in an insecure manner. It is possible that SSH has exploits [google.com] as well.

I'm not advocating that telnet be reintroduced for standard and widespread deployment. Still, though, I would have thought that such a devoted group of computer enthusiasts would have a more level and sane point of view. Some people like to ride their bicycle or motorcycle without a helmet. Some people like to use telnet. So what?

Poor Solaris. I hope nobody was seriously injured by this exploit.

People still use telnet.

I work for a company that uses a Sun box for a critical application and clients connect using telnet. This vulnerbility could be the answer I was looking for to get the outsourced company that looks after it to switch to SSH which is easily fast enough for the requirements of our users.

Temporary patches available

Temporary patches to fix telnet are available in zip files at: http://sunsolve.sun.com/pub-cgi/tpatch.pl [sun.com] (one for SPARC, one for X86 Solaris).

You need a (free) login to access these (my login was free)--security patches are free.

Fix almost available

I've done the work getting interim security fixes available and starting the sun-alert. These thing should be available shortly.

For a commentary on getting this fixed, have a look at http://blogs.sun.com/tpenta/entry/the_in_telnetd_v ulnerability_exploit [sun.com].

I'll update the blog entry with the links when it's up on sunsolve.

Tp.

SunAlert & Temp Patches Available

SunAlert 102802 [sun.com] is available describing the issue and workaround.

Temporary patches for SPARC and X86 to fix telnet are available [sun.com] You need a (free) login to access this.

Re:Here come the fanboys

Just because it's not deployed in many places, doesn't mean that those places aren't cracker dream targets...I've got 5 Solaris machines, and the least critical of them is a far better target than the most critical Windows, or even Linux box.

Still, first poster is right. Wtf uses telnet anymore, unless they're dealing with the most legacy of legacy crap.

Re:Here come the fanboys

Sure, but that's not what's being discussed. There is a world of difference between using telnet to fake some other non-encrypted protocol, and leaving the telnet service enabled on your machine.

Re:Is it a buffer overflow?

http://erratasec.blogspot.com/ [blogspot.com]

Its not a buffer overflow, its just unvalidated input.

Re:Is it a buffer overflow?

Yes, we should rewrite all the basic unix utilities in java. This way when multiple people are trying to use a system, nothing would work and the hackers cannot access the machine. Security through Denial of Service.

Re:Is it a buffer overflow?

Sure, we can stop using C.

We'll just suddenly and completely rewrite nearly every operating system we use. Yeah, that shouldn't be too hard!

Re:Telnet? Useless...

...

That was the worst comment I've ever read. If someone wants to know about telnet, they can look it up on wikipedia. It even includes a section on security of telnet.

Re:Is it a buffer overflow?

Maybe Sun would rather use Java instead.

Re:RootWont work if CONSOLE set in /etc/default/lo

This only prevents root from not being allowed to login

Um...

Re:Is it a buffer overflow?

Could we stop making dumb mistakes with code? pretty please? Java is not really going to protect software from inept programmers.

Re:Anyone tested it?

I tried on all my boxes (yes, I'm days away from transitioning away from telnet as soon as all the users get a Windows SSH client) and couldn't duplicate the exploit. That is includes two Solaris 10 boxes.

Sigh.

Guns don't kill people, people with guns kill people.

Knives don't kill people. People with knives kill people.
Clubs don't kill people. People with clubs kill people.
Fists don't kill people. People with fists kill people.
Poisons don't kill people. People with poisons kill people.
Cars don't kill people. People with cars kill people.
Cans of gasoline don't kill people. People with cans of gasoline kill people.
If you try to disarm people, where do you stop?

Why do I object? Because guns (or "people with guns") also protect people (including the person with the gun). They do this in several ways, including by opposing unprovoked attacks. Apparently, in that case alone, they prevent more death and injury than they cause, by a factor of several.

The quoted formulation leads to the false belief that killing can be reduced by banning guns (when in fact such attempts apparently greatly increase it "in the wild").

Dropping it into a discussion of another subject, if the poster is not called on it, propagates the dangerous meme.

The extension I posted above is intended to

Yes, my posting is off-topic. So is the parent. If I had mod points at this time I'd have just modded the parent down as off-topic. So instead I'm putting my own karma on the line to oppose the propagation of a meme that has killed countless people and continues to do so to this day.

I request any moderator that choses to mod THIS post down to do the same to the parent. I also request that any moderator who finds the parent posting has less off-topic down-mods than this one to add another down-mod to just the parent. To do otherwise is to take sides in the political debate injected into a different topic's discussion by the parent poster.