SSH Secure Shell 3.0.0 Remote Hole 77
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.
Re:Trivial isnt the word for it (Score:4)
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!)
Re:Don't use password authentication (Score:4)
*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.
Re:SSH.com needs to change their focus (Score:2)
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.
---
Re:But... But... (Score:3)
> 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.
Re:SSH sucks (Score:1)
Will wonders never cease . . . (Score:2)
Of all the good things I've heard about OpenBSD, I've never seen *this* one before
Re:Interesting reaction (Score:2)
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.
Re:"Exploit" doesn't work for me (Score:2)
At least it's not as simple as just trying to connect and type in a short password.
Interesting reaction (Score:3)
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.
Go sendmail! (Score:1)
ssh more *ahem* configurable, like sendmail is,
so that people write incredibly huge books
detailing how it can be configured, and then sell
an 'enchanced' version that has a nice GUI to the
configfile
SSH sucks (Score:5)
------------
a funny comment: 1 karma
an insightful comment: 1 karma
a good old-fashioned flame: priceless
Re:Trivial isnt the word for it (Score:1)
OpenSSH is not perfect. It has had interoperability problems with SSH.com's ssh (arguably because SSH.com had strayed from the SECSH reference design, but strict standards adherence does not always useabilty make). It also still supports the SSH-1 protocol, which is inherently flawed. While this is nice for sites transitioning to SSH-2 (or for people concientiously using SSH-2 but having to deal with admins elsewhere who are less on the ball), it's allowed the SSH-1 protocol to linger in the community longer than Tatu would have liked. And he's been very noisy about that fact. Even though there have been pretty much no reports of anyone actually exploiting SSH-1 just yet.
Point is, OpenSSH comes straight out of SSH.com's source, though its been much-updated, as opposed to other SSH (-1 and -2) implementations like FreSSH [fressh.org] and ossh [appwatch.com], which were reimplemented from the ground up.
--
Re:But... But... (Score:3)
Unquestionably true. But, this product appears to only make its source available if you buy the $475 server version [ssh.com]. 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
Re:Not a bug, a feature! (Score:5)
(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
Re:Is this a case of... (Score:2)
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..."
Re:Oh SHIT! (Score:1)
So you don't need to get it at your local warez dealer.
You get cuffed anyway if you (even not) try to distribute it
if you don't believe this I'll find another reason
Freaker / TuC
Re:Purchasing vulnerabilities (Score:2)
Not really. Microsoft gives these out for free.
They're called "Service Packs"
-- Give him Head? Be a Beacon?
What really sucks in OpenSSH freaks (Score:1)
Start documenting before bashing any product that doesn't have 'Open' before its name. It's a good product, you have access to the source and it's free for non-commercial use (it works great in my home server). Most of the people saying that ssh sucks, doesn't even know how to setup their ssh/openssh server to use public key authentication, and not the password authentication used by default. Real security is in public key.
Re:What is so good about it over openssh? (Score:1)
Riiiiight.
What is so good about it over openssh? (Score:1)
What is so bad about openssh that it is a wise decision to move to a commercial version with security leaks? It is fairly new and only the $475 server version includes source code, so it hasn't seen much review. Surely everybody realizes that when it comes to encryption, security through obscurity works against you. This is just the kind of place where full openness increases the quality of the product.
Re:But... But... (Score:1)
After the story about the shower curtains last week, I did try mine with cold water, and guess what: It hangs perfectly straight with cold water, and bulges with hot water. The article claimed to the contrary...
I guess it was all just a trick to let me take a cold shower
Re:What is so good about it over openssh? (Score:1)
Use the source luke.
Re:SSH on Mac OSX (Score:1)
I disagree unless there are security issues for the older versions. Just this incident with SSH version 3.0.0 shows again that you shouldn't go with a x.0 version, neither should have upgraded to it just because it was new.
Re:What is so good about it over openssh? (Score:1)
Might I ask what it is that you use ssh for that makes ssh such an important program for you that you need support, features, and easy compilaton?
SSH looks like a sufficiently functional secure telnet with port forwarding and secure file transfer to me. I've never found any additional features that I was missing in ssh, no need to touch it. Touching it will only add risk of new security problems.
I just do an easy apt-get for the linuxes, and compile once for each of the (very limited) Unix platforms that I need ssh on, then just distribute binaries. Re-installation is only necessary if there are security fixes.
telnetd, etc. Re:SSH sucks (Score:5)
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.
Re:What is so good about it over openssh? (Score:1)
OSS deprives users of the opportunity to pay for their software.
--
Closed source (Score:2)
Re:What is so good about it over openssh? (Score:1)
Send a cheque to the author(s).
Problem solved.
Fuck libsafe! (Score:1)
Bullshit. The only thing libsafe has ever done on my system is cause my fsck's and fdisk's not to run. It's a great idea but obviously implementation is lacking egregiously.
Re:Not a bug, a feature! (Score:2)
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! =(
But... But... (Score:2)
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?).
Re:Not a bug, a feature! (Score:1)
Back in the days when Sun and AT&T got into bed on SysVR4, someone decided to change the '*' that was commonly used to a 'NP' since '*' had a wildcard meaning. The problem is that NP is a vaild (and sometimes even used) seed so now programs much check for the two letter 'NP' and treat is special, while the old programs used to take the password string, pass that as one arg to crypt and the plain text as a second and if the result mached you let them in. This is about the same time that people started looking at buffer overflows and the result was people would go clean up code and make bad assumptions about how long the bits that came back from crypt were and tried to fix it but got it wrong.
I guess it was just time for history to repeat its self again.
Re:Stick with ssh 1.x (Score:1)
If the script kiddie has control of the router, its all over.
I think ssh 3.0 was to version 1.5 out of existance. Many places can be convinced to go with a prior version but most won't go with a very old version.
Quote attribution (Score:1)
- H. L. Mencken
Don't use password authentication (Score:4)
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 [lids.org] 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 [pureftpd.org] - Upgrade your FTP server to something simple and secure.
Re:Oh SHIT! (Score:2)
ftp://ftp.ssh.com/pub/ssh/
???
Re:What is so good about it over openssh? (Score:2)
Thus was born OpenSSH, a truly bsd-licensed piece of code that rocks.
"Exploit" doesn't work for me (Score:2)
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.
Fraudien slip (Score:1)
Pure guinness! (er, genius)
Re:So lemme get this straight... (Score:1)
Re:Not a bug, a feature! (Score:1)
You obviously don't know much about how UNIX works. Excerpting from my
daemon:*:11447:0:99999:7:::
adm:*:11447:0:99999:7:::
lp:*:11447:0:99999:7:::
sync:*:11447:0:99999:7:::
Yep, that's right. Common UNIX system accounts (that run daemons and system services) don't even have a password set. This, of cousre, means that they have a password that's shorted than two characters, making them vulnerable to the SSH hole. Once access to these accounts has been gained, using a local root hole is trivial. Seriously, I don't see why anyone should still be running the commercial SSH client when a great and audited alternative like OpenBSD exists and is available freely.
Purchasing vulnerabilities (Score:3)
Should disable these users anyway (Score:1)
Re:Oh SHIT! (Score:1)
Only affects those using password authentication (Score:4)
Re:Trivial isnt the word for it (Score:1)
w4r3z r001z (Score:2)
So copies obtained from #warez aren't vulnerable ?
Nice to know that n4u9h7y w4r3z is useful for summat :)
Re:Oh SHIT! (Score:2)
Re:Not a bug, a feature! (Score:2)
Re:Stick with ssh 1.x (Score:2)
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> [sourceforge.net]. 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.
Re:Oh SHIT! (Score:2)
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.
Try stunnel (Score:2)
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.
Re:Should disable these users anyway (Score:1)
Ok - here's a little nugget of potentially useful info you.
If you have a valid shell, but one that is for all intents and purposes useless (like
What can be done is to setup port-forwarding. Sure the victim user cannot login, but we can still forward ports on their behalf. Such access could be used to circumvent many TCP connections that use host-based authentication.
Used to target 'sync' accounts like that waaaaaay back in the day.
Just an FYI. Give em a shell that doesn't exist. Or, get rid of them altogether, and for God's sake, CHOWN ROOT ANY BIN OWNED FILES!!!!
sedawkgrep
Re:telnetd, etc. Re:SSH sucks (Score:1)
Re:Closed source (Score:1)
That was Phil Zimmermann [mit.edu], author of PGP [pgp.com], who quit working for Network Associates [nai.com].
Re:Don't use password authentication (Score:1)
I'd never heard of SecureID, so I decided to look it up. My analysis: a time-based one-time password generator in lots of different packages. I'd use the PIN to protect the one-time password, but this is probably a useability decision since it's hard to make a keychain thingy that you can enter a PIN into.
Also, this "Two-Factor" hype is stupid. SSH with RSA/DSA without an agent is exactly like this, but better as you say yourself. One *must* have a "two-factor" method in the network world because anything that can be remembered by a human can be guessed by a computer in a reasonable amount of time. (Of course I assume that only someone with very low security concerns would use an RSA/DSA key with no passphrase.)
My main dissagreement with you is this: If someone were to write an "agent" for SecureID it would be just as much a "single point of failure" as SSH with RSA/DSA. And a pickpocket shoulder-surfer could rip your network wide open. There is *no way* for a server to confirm if the tools on the other end of the channel being authenticated are being used correctly. This is impossible, and can only be solved by educating the user or descriminating against careless users.
Any security solution must be chosen based on the needs at hand and the likelyhood of the people to actually follow the guidelines. SSH generally provides what is called for -- Flexibility. Unfortunately, depending on how it is used, this can introduce insecurity. Like most unix stuff it is perfectly happy giving you enough rope to hang yourself.
I believe there is no substitute for people having a firm understanding of security, only supplements and tools. Of course I don't work in security and I'm an idealist. Unless educated, people will always do something stupid that you would have never forseen that completely compromises security.
So you don't think I'm being hostile: Your last paragraph is probably right, I would say SecureID is probably the best security option for clueless users. But since I'm sure it's incredibly expensive, it seems like any place that could afford it should have more clueful users! Also you are absolutely correct that convenience is the enemy of security.
Trivial isnt the word for it (Score:1)
What the historical relationship bewteen OpenSSH and the SSH company? just the name? Or was there shared source at some point? -M
Re:gaping? (Score:1)
Re:SSH sucks (Score:4)
Re:Stick with ssh 1.x (Score:1)
Plus more eyes are on the 2x sources than the 1x.
Have not even gone into a feature list, you can do that yourself mon ami
This is a problem with 3x, which is pretty darn new. Who trusts
StarTux
Message to Jamie... (Score:2)
Its great to see helpful notices like this on Slashdot, but if you could just check your hostility at the door...
Nick
Re:Should disable these users anyway (Score:1)
Sig: Tell all your friends NOT to download the Advanced Ebook Processor:
Re:Should disable these users anyway (Score:2)
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:
Re:Should disable these users anyway (Score:3)
Definitely make an impression on those folks...
Sig: Tell all your friends NOT to download the Advanced Ebook Processor:
Re:Not a bug, a feature! (Score:2)
Re:Interesting reaction (Score:1)
So lemme get this straight... (Score:1)
OK, I swear I am NEVER going to rip on Microsoft for crap security again.
Re:Trivial isnt the word for it (Score:1)
As far as I know, OpenSSH is not a fork of "SSH."
Re:But... But... (Score:1)
SSH is a great product and well worth it's price. The company has been very response to bugs in the past, this one being no exception. I've been using the commercial SSH for years now. It has a very liberal educational license and the ALL the source for the unix version is available. In fact I usually compile from source. Plus I seem to remember just as much OpenSSH holes in the past as ssh.com ones.
From the article I pickup the old 'all commercial software is bad and opensource rules' attitude, and for a journalist that's just frickin' sad.
Reasons for commercial SSH (Score:1)
I'm doing very fine with openssh.
Can someone tell the difference?
Re:SSH sucks (Score:1)
Re:Message to Jamie... (Score:1)
Without the graciousness of SSHCSC there would be no free alternative
Yes, there would. Witness GPG and all the alternatives that sprang up to RSA encryption when it was patented. Witness gzip, a better compression scheme that arose in response to the LZW compression patent.
Re:Not a bug, a feature! (Score:1)
bin:NP:1:1:bin:/bin:/dev/null
you are vulnerable. (Obviously, telnetd, popd, and others will read this as "no password" and unconditionally deny logins.)
--The Shortcut
SSH.com needs to change their focus (Score:4)
--The Shortcut
Is this a case of... (Score:1)
Thanks for the clarification... (Score:1)
Re:Not a bug, a feature! (Score:1)
authentification (Network neighbourhood)
When you send the password, they only check up to the size of the password you send..
e.g. The password is "Password" but it will allow "P", "Pa" etc..
Linux smbclient can be hacked in a few hours to simply try every single letter, and with a another half hours work, then expand it so once it knows one letter, it gets the next etc., hence finding the full password.
I have used this hacked version with much success, and this works in 95 and 98
(Not later tho.. they fixed it heh)
But even MS do dumb things like this..