SSH Secure Shell 3.0.0 Remote Hole

SSH Communications Security Corp (ssh.com/ssh.fi) announced on bugtraq last night that their commercial product SSH Secure Shell 3.0.0 is a gaping remote hole on various unixes. Technically it's not a root hole, but remote access to users like "adm," "bin," "daemon," and "sys" is not good. Strangely, I don't see an announcement on their homepage. If you're running the $99 workstation version or the $475 server version, go upgrade to 3.0.1 now because it's an amazingly trivial exploit (especially on Solaris, but also on other unixes, excluding NetBSD and OpenBSD which are not affected at all). If you're using OpenSSH, or some other program you didn't pay for, no worries.

Comments

SSH sucks

[VAXGeek]

Yet another SSH hole. This is why all of the security minded admins stick to telnet.
------------
a funny comment: 1 karma
an insightful comment: 1 karma
a good old-fashioned flame: priceless

Re:Not a bug, a feature!

[jamiemccarthy]

"So let me get this straight. . . this bug only occurs if someone uses a TWO CHARACTER password (or shorter)?!? I almost think anyone that dumb deserves to be hacked."

(sigh) No.

I didn't go into technical detail in the story because space was limited. But it's interesting how the exploit works, and I figured maybe some enlightened Slashdot reader would write up an insightful comment about it. Never mind, here's what I would have put in the story...

The vulnerability is so serious because most unix operating systems use a special code in their /etc/shadow file to signify "no password should ever match on this account." On my Debian installation, it's an asterisk:

daemon:*:...
bin:*:...
sys:*:...

The problem is that this product actually reads that as if the "*" were the crypt()ed password -- that's its first mistake. Then when it compares the crypt()ed attempt against that field in /etc/shadow, it only compares up to the length of the /etc/shadow field -- that's its second mistake.

Both are colossal errors.

The result is that any password will suffice to log into such accounts, because any password, when crypt()ed with the one- or two-character salt ("*"), will have its first one or two characters match -- and that's as far as the algorithm checks.

The result is that a code intended to mean "no password can ever succeed" ends up meaning "all passwords will always succeed." Truly an amazing oversight.

Jamie McCarthy

telnetd, etc. Re:SSH sucks

[warpeightbot]

Well if I shut down telnetd how am I going to telnet to my router-box-in-the-closet to upgrade?!

1) Get libsafe. The telnetd exploit is a buffer overflow (like so many bugs these days); if someone tries to hack your system this way, libsafe will trap it, kill telnetd (which is fine since telnetd should be running from (x)inetd and can respawn), and mail root.

2) Surely the router is firewalling port 23 on the outbound side, or at least tcpwrappered (or blocked in xinetd.conf), right? In the extreme case you can hardwire it to come from only your personal machine...

3) Hardwire it. Use a null modem cable, serial port to serial port; you could even set the headless box to boot to the serial port (yeah, this takes a kernel recompile, but you would've wanted to do that anyway). Use getty on the router, and minicom on your side (don't forget to configure it to not send "ATZ" for the "modem" init string....).

Frankly, I just use OpenSSH and be done with it... no reason to send bucks to Finland when the Canadians will do it better for free... and if it weren't for the fact that my housemate has Windows machines that occasionally need to PPTP to her work, I'd be using OpenBSD as the firewall.... when they get around to making pf tunnel alternate protocols, I'll likely be switching.

--
Linux for the stable desktop
Mac for publishing and pretty pictures
OpenBSD for secure servers
Windows for games
Use the right tool for the job.