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.
You're probably right. There is certainly no (that I know of) reason to fork out any dough to the SSH guys currently.
But who is going to pay for serious support for OpenSSH? For the most part you just rpm -i it and it works. Sure, there are a few configuration details. Maybe support in getting client programs to tunnel over SSH, but that wouldn't likely rake in a killing for anyone.
---
> 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.
Of all the good things I've heard about OpenBSD, I've never seen *this* one before
No, the libs were only half the frustrating part.
I was able to build OpenSSL and such that OpenSSH would compile.
I had it compiled and installed. Appeared to be configured correctly, but ssh clients would not authenticate with it.
I read in another post that OpenSSH has problems with Kerberos. That might be it, because I use Krb5 on my Solaris box to authenticate users.
I wasn't able to reproduce it either.
At least it's not as simple as just trying to connect and type in a short password.
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
Perhaps you already knew this, and were punning, but Slashdot draws a world-wide audience and as Tony Joe White said in Polk Salad Annie, "Some of y'all ain't never been down South might not know what I'm talkin' about..."
I see even classic Slashdot is now pretty much unusable on dial up anymore.
Not really. Microsoft gives these out for free.
They're called "Service Packs"
-- Give him Head? Be a Beacon?
-- Give him Head? Be a Beacon? :P)
(If you can't figure out how to E-Mail me, Don't.
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.
This is a bad blow for SSH the company. Didn't someone there quit a while ago since he disagreed about the decision to not provide source code to customers?
Seriously, though, not being too well acquanited with Unix systems, I didn't know this. Still, though, it was a joke -- I didn't mean to get you so worked up! =(
-- Imagine how much more advanced our technology would be if we had eight fingers per hand.
SSH Secure Shell 3.0 isn't made by Microsoft, and yet it has a super-trivial remote security hole. Guys, it's not April 1, knock it off.
But seriously, folks, this just goes to show mistakes can happen to anybody. Open source may be your best protection, but even it's not perfect (remember that recent OpenBSD local root hole?).
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}}
If you have to pay to get the source code, then what is the ssh-3.0.1.tar.gz file on their FTP server:
ftp://ftp.ssh.com/pub/ssh/
???
I print, therefore I am.
SSH began with a bsd-ish license, NOT a gpl license. It was then forked when they decided to get draconian with their licensing, and prices.
Thus was born OpenSSH, a truly bsd-licensed piece of code that rocks.
GPL'd web-based tradewars themed space game
In short, the trivial vulnerability doesn't seem to exist on these systems. Of course, I'll upgrade (or sidegrade?) to OpenSSH, which I already have on most of my other systems.
Has anyone actually had the trivial case of logging into lp or adm or some other username with an arbitrary password? I'm not doubting the vulnerability exists, but it seems that on systems withOUT any of the recommended workarounds, I'm still not vulnerable.
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.
So copies obtained from #warez aren't vulnerable ?
Nice to know that n4u9h7y w4r3z is useful for summat :)
"Be vewy vewy quiet, I'm hunting wuntime ewwors!" - Elmer Fudd
PLATFORMS NOT IMPACTED: Tru64 4.0.G, NetBSD, and OpenBSD are not vulnerable
This Wiki Feeds You TV and Anime - vidwiki.org
My God. It boggles the mind to think that a "professional" software company like SSH Communications would make such an insanely stupid oversight....
"We obviously need a new moderation category: (-1, Woo-fucking-hoo)" --Mr. AC
Because it's no more secure than telnet if your local script kiddies have the right tools.
Don't believe me? Take a look at Ettercap> . Does a great Man-in-the-middle attack and is so trivial to use the most brain-dead script kiddy could master it in 10 minutes.
"We obviously need a new moderation category: (-1, Woo-fucking-hoo)" --Mr. AC
OpenBSD uses OpenSSH not SSH. OpenSSH does not have any current holes. SSH does. SSH is commerical software. OpenSSH is free open source software. SSH does include source, but you have to fork out money.
FreeBSD IIRC also uses OpenSSH, not SSH.
Not sure what NetBSD uses, but betting it uses OpenSSH over SSH.
This is *NOT* a remote hole in OpenBSD, SSH is *NOT* even installed in the default installation. OpenSSH is. OpenSSH is secure, read above. SSH is not.
"`Ford, you're turning into a penguin. Stop it.'" -THHGTTG
If your router is not running a vulnerable telnetd then that's not the problem.
If your router is running a vulnerable telnetd then maybe you could run stunnel and telnet via SSL to it. www.stunnel.org
Set the stunnel to -v3 so that only clients with recognised certificates can actually connect.
So even if the telnetd is vulnerable, attackers don't get a chance to talk to it unless they have the right cert, or stunnel has a problem.
Stunnel has had some problems, but since the code is a lot smaller than SSH and the feature set is a lot more limited, I bet it's still more secure than SSH. I took that bet 2 years ago, and so far SSH has had tons more problems compared to Stunnel.
I feel some subtle hostility and contempt towareds SSH Communications Security Corp in your post. How unfortunate. SSH Secure Shell is a good idea and a great product. Without the graciousness of SSHCSC there would be no free alternative, and many more people may have suffered because of this particular vulnerability. Are you advocating open-source solutions or spreading propoganda? Its a tough call - you choose your words almost too well.
Its great to see helpful notices like this on Slashdot, but if you could just check your hostility at the door...
Nick
I would actually use /bin/false because it immediately terminates the session returning an error.
I don't use host based (at least name or address based) authentication either, except as one layer in VPN setups. No credentials, no access. Certificates are fine, as are Kerberos tickets. But host-based authentication is only one layer and is in no way trusted on my network with the security.
Sig: Tell all your friends NOT to download the Advanced Ebook Processor:
LedgerSMB: Open source Accounting/ERP
Definitely make an impression on those folks...
Sig: Tell all your friends NOT to download the Advanced Ebook Processor:
LedgerSMB: Open source Accounting/ERP
Not two-char passes; two char entries in /etc/passwd. Solaris uses the keyword "NP" in records in /etc/passwd when there is "no password" -- when no one is supposed to be able to log in as that user.
Liberty in your lifetime
--The Shortcut