Slashdot Mirror
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.
IIRC the OpenBSD crew got a hold of some old crufty "free" (as in license) ssh/sshd program, cleaned it up, added a ton of feartures, cleaned it up more, audited the source, released it and currently is maintaining it. IMHO the OpenBSD/OpenSSH team is doing a hell of a good job with this.
The orignal source was IIRC written from the ground up, but was in pretty bad shaped before the OpenBSD/SSH crew got a hold of it.
At last that is how my Papa tells the story.
Every "fearture" check I have compared between OpenSSH and SSH, they both keep up with each others in the buzzword complaint list. As far as price, OpenSSH wins hands (even can change/redistrub full source!). OpenSSH wins hands down also on the number of exploits found (ie. OpenSSH has less).
Personally I think OpenSSH(d) is easier to admin then SSH(d), but maybe that is just because I am more famlair with it?
Oh the OpenBSD/SSH crew is A LOT nicer than those jerks that support SSH. About 1-2 years ago I had to admin a bunch of old Solaris 2.3 boxen (yuck!). Both SSH and OpenSSH would not work correctly on 2.3 I emailed them both, the OpenSSH team sent me a diff and it worked prefectly. SSH team said that solaris 2.3 was unsupported and that they could not refund my $ (techinally my bosses cash). Theo may have a attitude problem, but atleast his has never riped me off! (in fact I think I have probably riped him off, downloading OpenBSD without giving donations!)
*sigh*
I'm too lazy to look up the exact quote or the correct attribution, but "For every complicated question, there is an answer which is simple, elegant, and wrong."
That's not necessarily the answer, for a variety of reasons:
(1) The use of RSA/DSA keys without a passphrase is reckless. Situations far less severe than having your box completely rooted (including numerous forms of pilot error) can allow people to read your files. In particular (and at the risk of sounding inflamatory), consider that such keys can be generated on and used from a windows box. Do you trust win98, with (for instance) no concept of file ownership, to keep some luser's private key safe?
(2) The use of RSA/DSA keys (even with a good passphrase) makes your machine a single point of failure, from a security standpoint, for all the machines to which you have access. Basically, the only thing that publickey authentication proves is knowledge of the contents of id_dsa. Ignoring the fact that several implicit assumptions lie between that and the "fact" that it's actually you trying to log in is of an order of stupidity similar to the mistake the ssh.com folks made.
(3) More broadly, anything which automates authentication subverts that authentication.
(4) The 'password' authentication in sshd_config need not use a static password. It is fairly straight-forward to write a PAM backend for (for instance) SecurID, while using the basic "ask user for magical identification string" semantics of password authentication provide the front end.
All that said, if they are used correctly, DSA keys can be significantly more secure than static passwords. However, there is no practical way to confirm on the server whether or not the keys are being used incorrectly. And, used incorrectly (e.g. w/ a null passphrase as you seem to suggest), they are much worse than static passwords with reasonable restrictions (complexity, length, expiration) placed upon them.
With that in mind, all of my really critical machines use SecurID authentication. Best-case is somewhere between password and public key authentication, but, and, when dealing with users in the real world, this is key, its worst-case security is _far_ better than the worst-case of either password or RSA/DSA keys.
> But, this product appears to only make its
> source available if you buy the $475
> server version. The cheaper workstation
> version does not come with source.
Bollocks. SSH 3.0.1 still comes with source in a non-commercial (though not libre) version. Excerpted from the license:
"To qualify for a Non-Commercial Version License, You must: (1) use the Software solely on a system under the Linux, FreeBSD, NetBSD, or OpenBSD operating system(whether for commercial or non-commercial use), or (2) use the Software for non-commercial purposes as defined herein and be a Non-Commercial Entity as defined herein, or (3) be an University User as defined herein, or (4) be an Excluded Contractor as defined herein."
You can download the SSH 3.0.1 sources from the usual place: ftp.ssh.com/pub/ssh.
I prefer free software as a rule, but OpenSSH's connection tunneling didn't work properly last time I tried it (around 2.4), and it still appears to lack MIT Kerberos 5 support as of 2.9p2. That said, it appears that ssh.com's v3.0 client won't authenticate via Kerb5 with a v2.x server.
I think it's kind of interesting how everybody is reacting to this with the "OpenSSH REWLS! SSH SUCKS!" attitude.
Reinforcing their own notions that open source software is somehow superior. I'm not certain how defensible this position is considering OpenSSH has also had quite a number of vulnerabilities of it's own.
For my purposes. I use SSH at home on my Sparc running Solaris 8. I do so because I tried OpenSSH and for whatever reason found it very difficult to configure, install and get working.
In fact I couldn't get it working. After spending a frustrating hour on it I decided to try the non-commercial version of SSH.
Compile, install... up in running with no problems.
The difference between these two products from an ease of installation was like night and day. OpenSSH suffers from the old "good enough" attitude exhibited by most open source software. SSH on the other hand you can tell they put some time into polishing which is typical of commercial software.
Is the code better? I don't know. Perhaps. But the chief difference is simply one of polish, something OpenSSH clearly does not have.
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
this sig limit is too small to put anything good h
Unquestionably true. But, this product appears to only make its source available if you buy the $475 server version. The cheaper workstation version does not come with source. I'm sure too that the licensing terms prohibit free redistribution of the server source, so (unless I'm mistaken) this is not an open source product. It looks like it's closer to what Microsoft calls "Shared Source."
Jamie McCarthy
Jamie McCarthy
jamie.mccarthy.vg
(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
Jamie McCarthy
jamie.mccarthy.vg
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.
Don't use password authentication with SSH / OpenSSH .
The beauty of *SSH is that you can use crypto keys for authentication. With ssh-keygen -tdsa , you create a pair of keys. id_dsa is the private one (keep it on your computer), and id_dsa.pub is the public one. You can copy the public one in ~/.ssh/authorized_keys2 on every server you are willing to access. The public key can be given to everyone, you can even put it in your signature so that people can grant you access to their machines if they want to.
When the public/private keys matches, you can log in. No need to enter any password. Simple. Fast. Easy. Really handy (especially with scp). And it's secure. Don't tell me "yeah but if your client computer gets rooted, the bad guy can grab your private key". First, LIDS can hide the private key. Then, you can add a passphrase if you want. Next, if your computer gets rooted, the bad guy can always install a keyboard sniffer.
Try DSA authentication. It rules. And it solves the problem of people chosing trivial passwords. Once you only use DSA authentication, you can disable password authentication in your sshd_config file.
-- Pure FTP server - Upgrade your FTP server to something simple and secure.
{{.sig}}
Prevent email address forgery. Publish SPF records for y
The problem is with accounts that have !! in the password field in /etc/passwd or /etc/shadow. This includes lp, adm, etc. Anyone can access those accounts (or any account with a two character entry in the password field) with any password. However, this is not a problem if you have disabled password authentication. Most people using SSH who really need security should be using some other type of authentication, including "public key, SecurID, Kerberos, certificates, Smart Cards, or hostbased." Those people running (non-Open)SSH daemons on Internet-accessible boxes with password authentication should definately upgrade though.
Definitely make an impression on those folks...
Sig: Tell all your friends NOT to download the Advanced Ebook Processor:
LedgerSMB: Open source Accounting/ERP
--The Shortcut