Slashdot Mirror
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."
Who the hell even THINKS about enabling telnet on any box these days?
$0.02 (CDN)
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.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
"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.
In a world of acronyms, the words are the real victims.
Can anyone confirm if telnet is enabled by default on Solaris for new installs?
It is on the 06/06 release of Solaris 10.
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.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
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.
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.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
towel.blinkenlights.nl, that's who.
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.
c++;
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...
Slashdot Burying Stories About Slashdot Media Owned
http://erratasec.blogspot.com/
Its not a buffer overflow, its just unvalidated input.
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.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
Since noone seems to have bothered posting it yet, "telnet -l -frandomuser randomsolarishost".
So stupid.
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.
:wq
If thou see a fair woman pay court to her, for thus thou wilt obtain love
From: Steve Ballmer
Subject: Pwned
Body:
Microsoft:1 - Unix: NIL LOLOLOLOLOLOL!!!!!!!111
Love Steviepoo
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.
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.
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
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.
Don't blame me; I'm never given mod points.
> Escape character is '^]'.
/etc/default/login specified that root logins may only be made from the console. Feel free to telnet in as any other user.
> Not on system console
> Connection closed by foreign host.
Reason that message happened: You succesfully logged in as root. However,
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.
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.
Not anymore, netcat is a better replacement for creating sockets. One of its advantages is the ability to listen to ports.
python>>> q="'";s='q="%c";s=%c%s%c;print s%%(q,q,s,q)';print s%(q,q,s,q)
Doing that uses a telnet client. This article is about a telnet server.
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
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.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
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.
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.