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)
"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.
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
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++;
Slashdot Burying Stories About Slashdot Media Owned
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.
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.
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."