New SSH Vulnerabilities Discovered

possible writes "Rapid7 has discovered a new class of vulnerabilities affecting SSH2 implementations from many vendors. These vulnerabilities affect a wide variety of SSH servers and SSH clients. Rapid7 designed an SSH protocol test suite called SSHredder. The SSHredder test suite contains a large number of SSH2 protocol binary test cases, and is released under the BSD license. Rapid7's testing has revealed many defects in products such as F-Secure, SSH.com, PuTTY, etc. OpenSSH and GNU LSH are not affected." Some of the affected vendors have released fixed versions, and some say there's nothing exploitable about the reported holes.

Comments

OpenSSH v3.5 and earlier not vulnerable

[ubiquitin]

Looks like the commercial version(s) of ssh and windows ports of the ssh client were most vulnerable. ssh.com people have denied it is a problem, whereas putty developers already have a fix available. This announcement was done very professionally, with details for each vendor that they were notified and what their response was. This is the first I've heard of Rapid7, and I'm impressed at their thorough approach in announcing this vulnerability.

Re:OpenSSH v3.5 and earlier not vulnerable

[Eil]

Agreed. Brilliant sig, btw.

exploitable

[Anonymous Coward]

Some of the affected vendors have released fixed versions, and some say there's nothing exploitable about the reported holes

Bullshit. Those vulnerabilities are exploitable. I know because i caught someone exploiting the buffer token error earlier today. We had to shut down our ssh server until we could add double-passback scanning to our firewall.

Re:exploitable

[jsprat]

Bullshit. What "buffer token error"? What is double-passback scanning"? You can't just make stuff up and expect to be modded up.

Well, maybe you can, but you are still making this up!

Re:exploitable

[FattMattP]

Those vulnerabilities are exploitable. I know because i caught someone exploiting the buffer token error earlier today. We had to shut down our ssh server until we could add double-passback scanning to our firewall.

Activating double-passback scanning doesn't always work to stop the buffer token error exploit. I've found that it's far more secure, although a bit more work, to realign the phase coil compensators to route any TCP connections through a dual-pole quantum isolator. From there you can tune your TCP/IP carburetors to inject the packets manually onto the firewall's stack. OpenBSD's pf is the only firewall to support this at the moment. Be sure that you have enough semaphores available before you try this. It could crash your system if not configured properly.

i know i'm responding to a troll

[honold]

here's the source code via http, the source code via ftp, and the md5sum

all this and more including read-only cvs access, nightly cvs tarballs, and contacts for submitting your own patches can be found at putty's home page here

just getting the word out. they've apparently become inundated with support mail for their free product, and could use some more developers :)

Re:OpenSSH v3.5 and earlier not vulnerable (duh)

[Anonymous Coward]

The company is based in the US -- the download form looked like your typical crypto export agreement ("I'm not from Libya, Iraq, N. Korea, etc."). Blame the government but don't blame them, I say.

Re:Responsible behaviour?

[RupW]

But they release testcases and detailed descriptions...

It looks like they gave all the affected vendors reasonable notice. Almost all the vendors have released fixed versions. These are not full-disclosure weenies.

They probably mean there's no workaround if you don't/can't update your software.

Is this version of Putty an updated version?

[Vlad_the_Inhaler]

It looks as though there have been no changes since November, I am not about to download a CVS build because that cure is liable to be worse than the disease.

I use Putty as a client to administer two remote Linux servers on a company internal network.

Even Pakistan's govt is moving to OSS

[mnmn]

Governments with high stakes of information on their computers are moving to OSS OSes. Signs of people realizing the stability and reliability of Opensource(tm) code. News like this just hammer the point home.

Sure there were news about that SSL problemo mainly on Apache-SSL, but they fixed it and fixed it good. Did they fix it in IE6 on win32? Could this be used to steal nuclear weapon documents from a scientists laptop online?? If the SSL vulerability and this SSH exploit isnt used, some other security problem will prop up.

Re:Even Pakistan's govt is moving to OSS

[Anonymous Coward]

God knows we all inspire to be as great as Pakistan's government!

It's nice...

[cyt0plas]

It's always nice to see a good security company pop up. I'd much rather companies address security than the US's often "overzealous" government.

Geez, death penalty for "cyberterrorists", a term that includes most twelve year old script kiddies? Like that won't be ab(used) by the prosecutors.

Why does SSH exist at all?

[phr2]

I've never understood that. Even if every one of those protocol bugs is fixed, it's still vulnerable to man-in-the-middle attacks because who the heck bothers to look at those server md5 checksums when connecting a new client?

There was already a perfectly good socket encryption protocol before SSH came along, namely SSL, which has had a reasonably functional PKI (though not as great as the vendors pretend) for years, and it's perfectly reasonable to run telnet through it. SSL-secured telnet is called "telnets", similar to https, smtps, and so forth. Https is built into just about every web browser these days. But almost nobody uses telnets.

SSH just seems to me like a case of the bad driving out the good. There was never any need for it. We should have just used telnets instead.

Re:Why does SSH exist at all?

[sgifford]

ssh is a replacement for the rsh/rlogin/rcp tools, not for telnet. You can do things like:

ssh some.host 'cd /home/gifford; tar cf -' |tar xf -

and

for i in host1 host2 host3 host4 ...
do
killall -HUP inetd
done

which are very hard to do with telnet.

Re:Why does SSH exist at all?

[mindstrm]

SSH is easier to use.
Not sure what you mean about man in the middle... once the initial exchange has happened, it WILL warn you of changes.

The other reason we use it is because it's so damn easy. Port forwarding, commercial tools.. it just WORKS.

So to flip your argument around.. why should I switch all my servers to ssl instead? What benefits do I get for my work, other than having to switch to crappier terminal programs and/or run tunneling software on my administration stations.

WHat? Another more complicated yet somehow "better" solution? No thanks.

I still don't get it

[phr2]

Those things would be easy to do by tunneling rexec through SSL or whatever. I just don't see what SSH brings that's new.

Re:I still don't get it

[sgifford]

The big thing is better forms of authentication. The only authentication method rsh had was to check if the machine you were connecting from was listed in .rhosts and the port you were connecting from was a priveleged port. You can imagine how poorly this worked in a dialup world---and even in the more traditional setting rsh was designed for, it had no protection at all from another computer on the network changing its IP address to one in .rhosts and logging into other computers.

ssh adds password authentication to rsh, and adds authentication by certificate to rsh, rcp, and rlogin. This makes the authentication into something reasonable.

ssh also automatically does X11 port forwarding, and can forward any other ports you want. The r* protocols have no mechanism for this.

Finally, IIRC ssh predates SSL. Otherwise it might have been designed to use SSL. I'm not sure about this one, though.

Re:Go Slashdot!

[Black Copter Control]

2002-12-16 21:30:02 Multiple Flaws In SSH Implementations (articles,security) (rejected) Multiple people submit. Yours gets rejected, his gets accepted. (Perhaps his was better written, or Cmdr Taco was just having a bad day when he read yours). Perhaps his was actually submitted first (I've had an article spend 4 days in the queue).

Re:putty

[Black Copter Control]

Where's putty's URL? Every time I have to find it again... I just go to the openssh site, and follow the links for other OS implementations. quick and easy to remember.

SSH doesn't predate SSL

[phr2]

Though it probably predates stunnel. stunnel is an SSL port forwarding program that does all the stuff that you mention ssh can do.

SSH uses passwords to let the server know that the client is legit. It doesn't do much to let the client know that the server is legit. And it doesn't stop active (man-in-the-middle) attacks unless you actually check the md5 hashes, which nobody does. SSL is far better about all these things.

Re:SSH doesn't predate SSL

[sgifford]

OK, I wasn't sure which came first.

ssh makes port forwarding simpler and more secure than stunnel. I can connect from my machine on my desk to a machine in the office, and ask ssh to create a local port localhost:8080 on my desk which forwards to a remote port 80 on an internal network, and so be able to connect to a machine behind a firewall. While I'm sure it's possible to do that with stunnel, it's much tricker than:

ssh -L8080:intranet.my.office:80 desktop.my.office

. Ditto for X11 forwarding. Of course, stunnel is useful for many other things that ssh can't do at all.

ssh can ensure that the server is legit, if you transfer the key into your known_hosts file by some secure mechanism. It doesn't support the same chain-of-authority mechanism that SSL does, which is both an advantage and a disadvantage. I think ssh would have caught on much less quickly if we'd had to purchase a certificate for every computer we ran it on.

You don't need to purchase certificates

[phr2]

You can create your own CA and generate your own certificates. You just have to configure your client software to recognize your CA. The only thing commercial certificates get you is that many programs (like browsers) are preconfigured to recognize commercial CA's. But for an internal network, making your own CA (or using a remotely administered private CA like Verisign OnSite) is precisely the right thing to do.

Re:You don't need to purchase certificates

[sgifford]

Right...But configuring your client to accept your own CA is no easier or harder than adding the SSH keys to your known_hosts file, and doesn't offer you better protection, either. Well, maybe for large networks it's easier, since you only have to add the CA's key instead of a key for each machine.

Also, when SSH came out, creating your own CA was significantly harder than it is now, IIRC. I remember spending several hours trying to figure it out in 1997 or so.