Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Security

New SSH Vulnerabilities Discovered 33

Posted by timothy from the this-too-shall-pass dept.
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.
This discussion has been archived. No new comments can be posted.

New SSH Vulnerabilities Discovered More

New SSH Vulnerabilities Discovered

Comments Filter:

  • OpenSSH v3.5 and earlier not vulnerable (Score:5, Informative)

    by ubiquitin ( 28396 ) on Monday December 16, 2002 @08:42PM (#4903685) Homepage Journal
    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.

  • exploitable (Score:4, Interesting)

    by Anonymous Coward on Monday December 16, 2002 @09:11PM (#4903951)
    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.

    • 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!

    • 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.

  • 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.
  • 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? (Score:3, Informative)

    by phr2 ( 545169 ) on Wednesday December 18, 2002 @09:37PM (#4920265)
    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.

    • 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.
      • 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.
        • 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.

          • 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.

            • 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 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.
                • 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.

    • 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.

Slashdot Top Deals

The 11 is for people with the pride of a 10 and the pocketbook of an 8. -- R.B. Greenberg [referring to PDPs?]

Close