Submitted by If you’ve got Solaris with telnet running, you could be in for a big surprise. There is a fairly trivial Solaris telnet 0-day exploit in the wild [.pdf]. “This was posted to Full-Disclosure. Remote root exploit in the Solaris 10/11 telnet daemon. It doesn’t require any skill, any exploit knowledge, and can be scripted for mass attacks. Basically if you pass a ‘-fusername’ as an argument to the –l option you get full access to the OS as the user specified. In my example I do it as bin but it worked for regular users, just not for root. This combined with a reliable local privilege escalation exploit would be devastating. Expect mass scanning and possibly the widespread exploitation of this vulnerability.”
I’m not sure if there are many Solaris servers hooked up directly to the Internet *and* running telnetd so the public impact of this might be relatively minor. The situation might be different on Uni campuses though as they usually have plenty of Sun boxes which might not be properly secured (running telnet).
As stated in the article you can’t use this exploit to become root on a default install, but of course regular user accounts and daemon accounts are useful in different ways (private docs, DOS attacks or data logging).
Edited 2007-02-12 18:46
Plain simple, although it’s a serious BUG on the telnet daemon service, I won’t consider it as an “EXPLOIT”.
First, you don’t exploit anything, just run the plain telnet client with the right argument.
Second, in order to get r00t, you gotta EXPLOIT sthg on the system ala local privilege escalation, since logging as root won’t get you nowhere..
Third, why use Telnet on the wild? Why use OpenSSH or SunSSH on port 22 tcp on the wild?
Easy admins, next->next->next->ok
Plain simple, although it’s a serious BUG on the telnet daemon service, I won’t consider it as an “EXPLOIT”.
Well, this bug will be exploited 🙂
Third, why use Telnet on the wild?
Telnetd is enabled by default on Solaris 10.
Ummm no it’s not. You have the option of turning it on during install but that is most definately not the same as being on by default.
Only starting with recent revisions. Solaris 10 u1 and previous versions enabled telnet by default.
u2 and previous previous versions. u3 is the first release with the “secure by default” option.
>”Telnetd is enabled by default on Solaris 10.”
I don’t believe this is the case, but without doing a fresh install I can’t be positive.
Can anyone else comment on this?
Yes, it is. If you install S10, S10u1 or S10u2, the “full install”, in.telnetd is running. Only in the latest release, S10u3, you have the option to install it “secure by default”. In that case, the only internet-listening daemon is sshd. All other are either stopped, or are listening on 127.0.0.1 only.
The bug appears to be from Sol10’s installer adding support for telnet and turning it on by default when you do a full install.
Wikipedia says: “In computer security, an exploit is a piece of software, a chunk of data, or sequence of commands that take advantage of a bug, glitch or vulnerability in order to get unintended or unanticipated behavior out of computer software, hardware, or something electronic (usually computerized)….”
So unless the result was intended (user access without a password) or anticipated I’d say we are technically talking about a BUG, GLITCH or VULNERABILITY.
The EXPLOIT would actually be ‘telnet -l “-fbin” target_address’.
Edited 2007-02-12 19:07
Solaris does not allow root logins from remote consoles in the first place regardless of protocol. In order for this to be a remote root exploit, the /etc/default/login file would have to be changed to allow remote root logins.
Build 56 of Solaris Express disables telnet by default, and it is a trivial matter to disable telnet:
svcadm disable telnet
Or for the ultra paranoid:
pkgrm SUNWtnetc
pkgrm SUNWtnetd
pkgrm SUNWtnetr
According to a message sent out by David Comay Sun should be releasing an Interim Patch for this issue later today.
“Solaris does not allow root logins from remote consoles in the first place regardless of protocol. In order for this to be a remote root exploit, the /etc/default/login file would have to be changed to allow remote root logins.”
Or you exploit an account with passwordless sudo access…
That is if sudo is installed, sudo does not come with Solaris. Sun uses Role Based Access Control (RBAC) to provide sudo functionality.
Good thing nobody really uses telnet on the intarweb any more
WAH?
I use telnet all the time to play MUDs.
Those MUDs are probably running on mission critical servers too, oh wait, that’s right, they’re not.
“Good thing nobody really uses telnet on the intarweb any more”
Yeah, except a good chunk of the intarweb infrastructure.
Try getting a refurbished Cisco box that supports ssh or an IOS image that does. Heck, try getting a brand new Cisco box that does, especially if you’re outside the U.S.A. In the unlikely event that you do Cisco still only support ssh v1.
Not to mention the other myriad of equipment old and new.
Uh, I think we are talking about the telnet server on a general purpose Unix OS made by Sun, not IOS used in a router or switch. most of the places I have worked, the switches and routers can and are configured not to talk to the outside world on port 23, so I think that could be considered moot
“Uh, I think we are talking about the telnet server on a general purpose Unix OS made by Sun, not IOS used in a router or switch. ”
Well, the original post only stated that “nobody really uses telnet on the intarweb”, not “nobody uses telnetd on a general purpose OS”.
That’s why I qualified it with “really”, so It would not be an absolute statement, there is no such thing as the intarweb either, care to comment on that too?
Another reason why I Love and Hate sun. The exploit worked on a test sol10, but would not work on a Sol 9 box. I cant wait to get ZFS in FreeBSD and OSX .
Very bad period for Solaris, first ping/ICMP panic, then this one, but of course, there is no bug free software, and Zones/ZFS/Dtrace are great Solaris features.
Run and buy symantec antivirus for Solaris 10 NOW !!!!
Bwahahahahahaahahah!! It’s a joke.
[edit] Hu ? -5 just after a few seconds oO
Edited 2007-02-12 19:42
LOLZ☺☻♥
Bluntly: all those running telnetd on a net-connected server deserve to be rooted. Take it as a wake up call. From the last century.
I agree. Telnet should be avoided anyway, as the data is sent in plaintext anyway, making it very vulnerable for all kinds of security breaches, including “man-in-the-middle” attacks.
Honestly, telnetd should *never* be used, let alone set as a default on a server connected to the Internet. SSHd is much more secure (in addition to having more features).
Haven’t know anyone who has left that port open in well over what must be 12 years now, was a well known security hole long before then. Must be new to someone out there. Try ssh instead.
I guess so is ftp cause it also uses plain text userid/password.
So, for those hating on telnet(I don’t recommend it either), don’t forget about all the ftp servers out there which are prone to packet sniffing.
Of course, this does not imply that this particular telnet bug is any less troubling, but I had to point out ftp as being pretty bad also.
The trick is in catching one, ftp not so easy.
Many ways to secure ftp. ftp + ssl, stunnel, use virtual users instead of os users, etc.
… to setup a server without doing any security hardening/common “good” system administrative practices, you have no business setting up a server.
# telnet -l”-fadm” localhost
Trying 127.0.0.1…
telnet: connect to address 127.0.0.1: Connection refused
Trying ::1…
telnet: Unable to connect to remote host: Network is unreachable
# uname -a
SunOS server2 5.10 Generic_118855-33 i86pc i386 i86pc
#
No problem for me. That said, it is a bit silly anything was enabled by default on “old” versions, but it has since been fixed. Now you have to explicitly enable it.
The bigger worry is the recent “ping o’ death” exploit that came out end of Jan. Go check the sun security notices if you don’t know what I’m talking about and you run Solaris boxes.
You have to realize that telnet is deeply entrenched into many environments. So… the argument of “don’t use telnet”, is NOT going to work in many places. While I certainly advocate for the destruction of telnet and ftp, there are many places that have these tools deeply embedded into their INTERNAL infrastructure.
I emphasize INTERNAL because most believe they were relatively safe running those insecure protocols on the inside of a private network.
Second, you DON’T need to use -l”-froot” to be able to compromise a remote host. All you need is a somewhat priv’d user to cause some havoc. Shoot.. do you want somebody logging in as your username? How about the id of the database user? I can think of a million of these. Sure… it’s possible that a good administrator has prevented direct logins (e.g. no shell) for these accounts… but still… probably not just because nobody expected there to be a huge gaping hole in the telnet server.
So… to all who say… “ah, this is no big deal”… blurzptz to ya! This is a VERY big deal.
“””So… to all who say… “ah, this is no big deal”… blurzptz to ya! This is a VERY big deal.”””
Indeed. Despite the antics of the “Blame the users! Blame the admins!” crowd, this truly *is* embarrassing.
As a Unix advocate since 1988, consider me suitably humiliated by this one. 🙁
Well thanks to you and the previous poster we now know who the retards are that are still running telnet in 2007. You can put me in the “blame the admins” crowd if you like. I am an admin myself and would deserve to be fired if I ever even thought of turning on telnet over an open network.
As the engineer who ran with doing the fix for Solaris 10, I have to say that one real positive out of this is that our current process works.
At about lunchtime (Sydney) I had one of our onsite folks call me from a very large customer asking me about this bug. We very quickly saw what was going on and started looking at how to fix it.
While I was looking at usr/src/cmd/cmd-inet/usr.sbin/in.telnetd.c, I noticed that Dan McDonald had put a fix into nv (about 2pm).
By 5pm we had IDR patches for both SPARC and i386 and I started on the Sun-Alert.
The security folks and the sustaining and engineering folks were incredibly helpful. By the time I left (just after 11), the process was in place to get the sunalert and the IDRs fast tracked to public sunsolve.
The ISRs (Interim Security Relief) should be shortly available on http://sunsolve.sun.com/tpatches as should Sun Alert 102802.
The RTI was accepted for the s10 patch gate and I did the putback about an hour ago. I would expect formal patches in the next few days.
So, less than 24 hours between teh bug creation and a putback happening. Not bad.
Alan.
“””As the engineer who ran with doing the fix for Solaris 10, I have to say that one real positive out of this is that our current process works.”””
You put an… err, the word “trivial” doesn’t do it justice… exploit into telnetd, and you say that it shows that your current process works?
I’ve never bought the whole “we have exploits, but we fix them fast” argument. Not from Mozilla Corp. And certainly not from Sun.
You frecked up. And badly.
It’s best to just admit it.
Don’t provide command-line options to compromise our systems in the first place, please.
At which point did I say that it was not an almighty cockup?
God, yes it was.
And by the way, *I* did not put a trivial exploit ito telnet. The actual code was part of a substantially more complex putback for kerberos authentication for S10 FCS.
I think we all agree that it should not have happened. It did. Let’s move on.
The point that I was making which you entirely missed is that patch creation process within Sun has come an incredible way in the last few years.
The Interim fixes will be available close to 24 hours from discovery and the actual fix has already gone back into the patch gate for patch generation.
Yes, we cocked it up, and I’m more than happy to acknowledge that, but please; let’s have a little credit when it’s due. Five years ago it would have been unheard of for Sun to not only acknowledge but have a fix out anywhere near this quickly. The powers that be have made fantastic progress in smoothing the way for the rapid release of security fixes.
Alan.
You put an… err, the word “trivial” doesn’t do it justice… exploit into telnetd, and you say that it shows that your current process works?
I’ve never bought the whole “we have exploits, but we fix them fast” argument. Not from Mozilla Corp. And certainly not from Sun.
You frecked up. And badly.
It’s best to just admit it.
Don’t provide command-line options to compromise our systems in the first place, please.
Certainly we’ve never met, but you give me little reason to assume you know much about software. Mistakes happen. It’s inevitable. Would you prefer having exploits and fixing them slowly? If you would prefer having no exploits, I hate to be the one to break it to you, but that is only an option in a dream world.
But maybe I’m wrong. Perhaps a bunch of people at Sun just read your advice regarding exploits and became enlightened. If so, let me be the first to congratulate you.
“””Certainly we’ve never met, but you give me little reason to assume you know much about software. Mistakes happen.”””
In general, I agree. Mistakes do happen. We are human.
But I see an excessive volume of “Gee, mistakes happen” posts as reactions to completely avoidable security mishaps.
And I see “we amended it quickly” used as an excuse far too often.
I applaud the OpenSolaris guys, and Alan in particular, for the damage control.
But it does not erase the incident.
That is my point. No more, and no less.
I applaud the OpenSolaris guys, and Alan in particular, for the damage control.
But it does not erase the incident.
That is my point. No more, and no less.
I understand, and that’s reasonable. Personally I would just rather not beat people up over this kind of thing if they are responsive in fixing it. In the short term, software is not getting less buggy, but customer support can surely get a lot less responsive than what we [seem to] see here.
# cp /bin/login /bin/login.new
# perl -pi -e
‘s/u:s:R:f:h:r:pad:t:U:z:/u:s:R:F:h:r:pad:t:U:z:/’
/bin/login.new
# mv /bin/login /bin/login.bad.save
# mv /bin/login.new /bin/login
I think that’s a good temporary workaround. Sun supposedly is pushing out a temp fix as we speak.
I’ve written up a blog on what happened in getting this fix out. I’m pretty impressed with the process nad the people involved in speeding this through.
http://blogs.sun.com/tpenta/entry/the_in_telnetd_vulnerability_expl…
Alan.
ssh has been here for so long now and gives much better security, so why even have telnet open. specially wide open????
Stupids.