×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Solaris Telnet 0-day vulnerability

Hemos posted more than 7 years ago | from the frantically-trying-to-fix dept.

Security 342

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

342 comments

Here come the fanboys (0, Funny)

Anonymous Coward | more than 7 years ago | (#17981856)

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

Re:Here come the fanboys (0, Troll)

Eco-Mono (978899) | more than 7 years ago | (#17981864)

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

Re:Here come the fanboys (4, Informative)

SatanicPuppy (611928) | more than 7 years ago | (#17981920)

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 (2, Insightful)

Rob T Firefly (844560) | more than 7 years ago | (#17982172)

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 (1)

SatanicPuppy (611928) | more than 7 years ago | (#17982186)

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 (1)

lanc (762334) | more than 7 years ago | (#17982318)

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

Re:Here come the fanboys (5, Informative)

SatanicPuppy (611928) | more than 7 years ago | (#17982346)

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 (0)

nettdata (88196) | more than 7 years ago | (#17982358)

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 (1)

lanc (762334) | more than 7 years ago | (#17982388)

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

Re:Here come the fanboys (1)

aussie_a (778472) | more than 7 years ago | (#17982540)

I do [armageddon.org] 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 (-1)

Anonymous Coward | more than 7 years ago | (#17982282)

I'd give you 10 mod points just for getting the spelling of "cue" right. I'm tired of the retarded "que", or the pretentious "queue".

Why is this a big deal? (5, Insightful)

nettdata (88196) | more than 7 years ago | (#17981860)

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

Re:Why is this a big deal? (0)

Anonymous Coward | more than 7 years ago | (#17981894)

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? (3, Insightful)

TheGratefulNet (143330) | more than 7 years ago | (#17981904)

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? (3, Insightful)

SatanicPuppy (611928) | more than 7 years ago | (#17981982)

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? (3, Informative)

Nasarius (593729) | more than 7 years ago | (#17982022)

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? (2, Informative)

SatanicPuppy (611928) | more than 7 years ago | (#17982122)

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? (1)

fimbulvetr (598306) | more than 7 years ago | (#17982150)

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? (2, Interesting)

ePhil_One (634771) | more than 7 years ago | (#17982308)

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? (0)

Anonymous Coward | more than 7 years ago | (#17982590)

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 [linuxdevices.com]

Re:Why is this a big deal? (2, Insightful)

walt-sjc (145127) | more than 7 years ago | (#17982018)

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? (5, Insightful)

mi (197448) | more than 7 years ago | (#17982246)

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? (1)

alexhs (877055) | more than 7 years ago | (#17982050)

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? (1)

TheRaven64 (641858) | more than 7 years ago | (#17982272)

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? (1)

Alioth (221270) | more than 7 years ago | (#17982448)

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? (1)

Cheesey (70139) | more than 7 years ago | (#17982634)

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? (3, Informative)

drsmithy (35869) | more than 7 years ago | (#17981916)

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? (1)

SatanicPuppy (611928) | more than 7 years ago | (#17982032)

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? (0)

Anonymous Coward | more than 7 years ago | (#17982062)

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

People who live in glass operating systems (-1, Troll)

Anonymous Coward | more than 7 years ago | (#17982112)

It appears people who criticize Windows need to take a better look at their own operating systems.

Go Go Gadget security through obscurity!

Re:Why is this a big deal? (5, Informative)

dknj (441802) | more than 7 years ago | (#17982260)

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

Re:Why is this a big deal? (5, Funny)

imikem (767509) | more than 7 years ago | (#17981944)

Relevant line from /etc/services:

telnet 23/tcp imadumbass hackmenow rootrus rotflmao

Re:Why is this a big deal? (5, Funny)

teslar (706653) | more than 7 years ago | (#17981958)

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? (1)

nfsilkey (652484) | more than 7 years ago | (#17982020)

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

Re:Why is this a big deal? (1)

canuck57 (662392) | more than 7 years ago | (#17982042)

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? (4, Interesting)

bockelboy (824282) | more than 7 years ago | (#17982082)

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? (2, Informative)

SatanicPuppy (611928) | more than 7 years ago | (#17982158)

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? (2, Informative)

Zan Lynx (87672) | more than 7 years ago | (#17982664)

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? (0)

nettdata (88196) | more than 7 years ago | (#17982230)

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? (1)

bockelboy (824282) | more than 7 years ago | (#17982594)

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? (1)

JoeRandomHacker (983775) | more than 7 years ago | (#17982608)

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 [wikipedia.org] 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? (0)

Anonymous Coward | more than 7 years ago | (#17982620)

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.

Ha! (0, Funny)

Anonymous Coward | more than 7 years ago | (#17981870)

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

-Bill Gates

Telnet? (1)

walt-sjc (145127) | more than 7 years ago | (#17981898)

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? (1, Informative)

Anonymous Coward | more than 7 years ago | (#17981976)

AiX 5.3 has telnet enabled by default.

Re:AIX Telnet? (1)

Mr Pippin (659094) | more than 7 years ago | (#17982404)

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:Telnet? (2, Informative)

Anonymous Coward | more than 7 years ago | (#17981980)

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? (1)

walt-sjc (145127) | more than 7 years ago | (#17982038)

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? (0)

Anonymous Coward | more than 7 years ago | (#17982250)

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? (3, Informative)

Anonymous Coward | more than 7 years ago | (#17981998)

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? (1)

Bert64 (520050) | more than 7 years ago | (#17982046)

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

Re:Telnet? (0)

Anonymous Coward | more than 7 years ago | (#17982096)

What, no daytime?

Re:Telnet? (1)

Nasarius (593729) | more than 7 years ago | (#17982118)

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? (1)

thodi (37956) | more than 7 years ago | (#17982086)

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.

So what? (0, Redundant)

Keyslapper (852034) | more than 7 years ago | (#17981900)

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

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

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

Configuration issue (1)

Gothmolly (148874) | more than 7 years ago | (#17981928)

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 (4, Informative)

walt-sjc (145127) | more than 7 years ago | (#17982080)

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 (0)

Anonymous Coward | more than 7 years ago | (#17982266)

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 (4, Informative)

zdzichu (100333) | more than 7 years ago | (#17982630)

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 (1)

cnettel (836611) | more than 7 years ago | (#17982144)

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.

Oh my goodness! This is HORRIBLE! AUUUGH!!!!!!!! (0, Redundant)

Chas (5144) | more than 7 years ago | (#17981968)

[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 (4, Insightful)

otacon (445694) | more than 7 years ago | (#17981970)

"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 (1)

LoadWB (592248) | more than 7 years ago | (#17982130)

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.

the authors seem very confused ... (3, Insightful)

petes_PoV (912422) | more than 7 years ago | (#17981986)

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 ... (1)

Bert64 (520050) | more than 7 years ago | (#17982154)

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 ... (0)

Anonymous Coward | more than 7 years ago | (#17982324)

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

OpenSolaris as a development model (1, Informative)

lewiz (33370) | more than 7 years ago | (#17982008)

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 (2, Insightful)

pipatron (966506) | more than 7 years ago | (#17982066)

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 (1)

Bert64 (520050) | more than 7 years ago | (#17982116)

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.

0-day? (2, Interesting)

Aladrin (926209) | more than 7 years ago | (#17982056)

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? (4, Informative)

walt-sjc (145127) | more than 7 years ago | (#17982146)

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? (0)

Anonymous Coward | more than 7 years ago | (#17982180)

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

- Peder

Re:0-day? (1)

jmv (93421) | more than 7 years ago | (#17982196)

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? (1)

db32 (862117) | more than 7 years ago | (#17982216)

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? (1)

Imagix (695350) | more than 7 years ago | (#17982234)

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? (1)

TobyWong (168498) | more than 7 years ago | (#17982408)

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? (1)

Yenya (12004) | more than 7 years ago | (#17982488)

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 [wikipedia.org], section "Exploits and vulnerabilities".

Off By Default (1)

JusticeISaid (946884) | more than 7 years ago | (#17982072)

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 (1)

TheRaven64 (641858) | more than 7 years ago | (#17982328)

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 (0)

Anonymous Coward | more than 7 years ago | (#17982582)

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.

RootWont work if CONSOLE set in /etc/default/login (0)

Anonymous Coward | more than 7 years ago | (#17982110)

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! (0)

Anonymous Coward | more than 7 years ago | (#17982160)

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.

Is it a buffer overflow? (-1, Flamebait)

master_p (608214) | more than 7 years ago | (#17982222)

Is it a buffer overflow?

if it is, can we stop using C and C++? pretty please???

Re:Is it a buffer overflow? (1)

slack_prad (942084) | more than 7 years ago | (#17982384)

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

Re:Is it a buffer overflow? (0)

Anonymous Coward | more than 7 years ago | (#17982442)

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? (1)

CompMD (522020) | more than 7 years ago | (#17982464)

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? (1)

Stumbles (602007) | more than 7 years ago | (#17982538)

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

Re:Is it a buffer overflow? (1)

someone1234 (830754) | more than 7 years ago | (#17982588)

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?

Telnet? Useless... (0, Redundant)

zuhaifi (1060950) | more than 7 years ago | (#17982374)

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... (1, Funny)

Anonymous Coward | more than 7 years ago | (#17982518)

...

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... (1)

ReluctantBadger (550830) | more than 7 years ago | (#17982562)

"... many Web professionals prefer the more secure SSH ... This level of access is similar to reaching the C: command prompt in DOS ..."

I'm not sure whether to laugh or cry. You have truly and utterly FAILED.

The Exploit (3, Informative)

biftek (145375) | more than 7 years ago | (#17982400)

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

So stupid.

what??? (1)

DaMattster (977781) | more than 7 years ago | (#17982566)

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

We're not in the 90s anymore (1)

thepacketmaster (574632) | more than 7 years ago | (#17982666)

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.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...