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?
Sun, apparently, since it's enabled by default.
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.
AiX 5.3 has telnet enabled by default.
Can anyone confirm if telnet is enabled by default on Solaris for new installs?
It is on the 06/06 release of Solaris 10.
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.
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...
LOAD "SIG",8,1
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...
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.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
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.
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.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
except it's not... (at least not as of the 10/06 release)
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
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.
If thou see a fair woman pay court to her, for thus thou wilt obtain love
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.
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.
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.
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...
--
"It is now safe to switch off your computer."
I have 11/06, and believe me, I was surprised to find telnet enabled.
If thou see a fair woman pay court to her, for thus thou wilt obtain love
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.
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.
> 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.
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.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
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.
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.