back to article Evil OpenSSH servers can steal your private login keys to other systems – patch now

Malicious OpenSSH servers can silently steal people's private SSH keys as they try to login, it emerged today. This means criminals who compromise one server can secretly grab keys needed to log into other systems from a user's computer – allowing crooks to jump from server to server. The security cockup, present in the …

  1. Martin Summers Silver badge
    1. petur

      FFS indeed...

      "When there's a serious security bug in the remote access tool used by 70+% of the servers in the world, people sit up and take notice," said Kenn White, co-director of the Open Crypto Audit Project.

      The problems occur in how OpenSSH client code between versions 5.4 and 7.1 handles roaming,

      This phrase makes it look like those 70+% servers are vulnerable, but it is a client bug...

      (yes, lots of servers means many clients but still....)

      1. Surreal
        Meh

        Re: FFS indeed...

        I'm glad the sky isn't actually falling. Anyone else flashback to 2001, GOBBLES security?

    2. Voland's right hand Silver badge

      Doubly FFS

      X-forwarding and Agent forwarding are the first thing to enable to make ssh useful.

      It is standard usage scenario - ssh into a jump box and ssh to the next system inside the network. If you do not have agent enabled you will be entering passwords or passphrases which is a recipe for disaster.

      Time to start patching.

      1. sthen

        Re: Doubly FFS

        No need to trust jump boxes with your SSH agent - you can just use ProxyCommand with nc or ssh -W instead. The first SSH session authenticates you to the jump box, then it just passes TCP to the destination.

    3. NoneSuch Silver badge
      Devil

      You pay for a fence to keep out the foxes. The contractor tells you it's done, you go take a look and find hole after hole.

      Then you find out the fence company is run by the foxes.

      It's sorta like that.

      1. Anonymous Coward
        Anonymous Coward

        You pay for a fence...

        You pay for a fence to keep out the foxes.

        You're thinking of M$. That's not this crowd.

  2. 2460 Something

    I much prefer to look at the positive outcomes of things such as this. One less flaw (in this case two). I think a dose of replacement key-pairs is about to be administered just in case though :D

  3. PerspexAvenger
    FAIL

    What, no sexy brand-name and associated collection of T-shirts and mugs?

    I am disappointed...

    1. brotherelf
      Paris Hilton

      Oh yes, it's supposedly called "triple-seven" by its CVE number, and folks over at heise.de even threw that into an image search engine to come up with a "hero" image even more pointless than ElReg's.

      (Paris, because it's all about the purty looks.)

    2. Midnight

      Personally I was hoping to call it the Secure SHell Information Transfer bug, with the appropriate acronym, but nobody seems to be going for it.

  4. This post has been deleted by its author

  5. GrumpenKraut

    W.T.F.?

    I recall looking at OpenSSH code many years ago and recoiling, but hoping they knew what they were doing.

    Never attribute to malice... (blah blah)... Almost hard to believe with OpenSSH. A candidate for the history books of software screw ups for sure.

    1. Tomato42
      Flame

      Re: W.T.F.?

      Remember, that's the guys that say how better will be the OpenSSL in form of LibreSSL when they are done with it...

  6. Alistair
    Windows

    does no one use passphrases on their private keys?

    Or am I just a screamingly paranoid grumpy bastard. << and the system scan will *detect* that you don't have a passphrase on the key and log it to security too >>

    1. Anonymous Coward
      Anonymous Coward

      Re: does no one use passphrases on their private keys?

      "does no one use passphrases on their private keys? "

      Yes, min 20 chars and we don't use agent forwarding, hopping a gateway server to another requires passphrase entry. Doing it another way is just for the bone idle.

      The only use for phrase free keys here is for servers to connect to others with no user interaction, things like log transfers etc and then each server has a different key and logs in to a different account on the central machine with user privs. Some of these setup a reverse tunnel that can be used to access the connecting system behind NAT over a mobile 3g connection, but you still need to enter a passphrase to acess it over the tunnel.

      The lazy will always get pawned.

    2. Anonymous Coward
      Anonymous Coward

      Re: does no one use passphrases on their private keys?

      We use passphrases on all personal use keys, or anything that is manually initiated.

      The only place we use keys without passphrases, is server-to-server and only for automated processes, and these are separate keys per point-to-point connection.

    3. John Brown (no body) Silver badge

      Re: does no one use passphrases on their private keys?

      A bit out of my depth here, but what's the difference between using a key AND a passphrase compared to just using a decently complex password and no key?

  7. mlein

    Putty?

    Any idea if putty is vulnerable as well?

  8. chasil

    Password [algorithim] strength

    Key passwords make this more difficult to exploit:

    "One bright spot is that passphrase-encrypted SSH keys are leaked in their encrypted form and must be cracked offline. Not everyone protects their keys using a passphrase, however."

    I wonder if converting the private key to PKCS #8 format will provide further protection?

    http://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.html

    My cygwin keys on my workstation are in PKCS #8 format - but then again, I also have the putty pagent running, which likely erases any benefit from PKCS #8.

    1. Tomato42
      Happy

      Re: Password [algorithim] strength

      Putty is almost certainly not vulnerable - the bug is a feature that was implemented just on client side and never implemented on server side - dead code essentially. There was no reason for PuTTY to ever implement it.

  9. Anonymous Coward
    Anonymous Coward

    "This information leak may have already been exploited in the wild by sophisticated attackers"

    I see OpenSSH 5.4 was released in 2010, however, back in 2007 when I was building secure remote access services for various government departments, one of the items of functionality prohibited in the guidance was... session roaming...

    So given the disclosures todate (such as Edward Snowdon's), I suspect OpenSSH isn't the only implementation of session roaming to have vulnerabilities that would permit the client's key pair to be fully compromised and so facilitate an attack on central systems...

  10. Anonymous Coward
    Anonymous Coward

    Good advert for HSMs and smart cards ?

    Surely this is an excellent advert for the benefits of HSMs and smart carts !

    These days even with SSH Client you can store your keys on a smartcard and connect and use PKCS11.

    No private keys to steal because they can't be exported.

    1. Rainer
      Paris Hilton

      Re: Good advert for HSMs and smart cards ?

      That's why in the Hollywood-movies, they always have the hot chick to date the smart-card holder and relieve him...of his smart-card.

      ;-)

      1. Joe Harrison

        Re: Good advert for HSMs and smart cards ?

        If any hot chicks are reading this... I have a smart card. Several in fact. Just sayin.

  11. g00se
    Headmaster

    Verb and noun

    Then when you next login,

    No, no, no! The verbal form is TWO words. What you've got is a noun

  12. Anonymous Coward
    Anonymous Coward

    My workaround...

    ...is to use telnet and ftp.

    With everyone listening in on port 22, we at ports 21 and 23 just fly under the radar.

    I call it security by clarity. :-)

    I'm off to block outgoing TCP on 443, back in a bit.

    1. Number6

      Re: My workaround...

      I assume you use double-ROT13 encryption as well?

    2. Crazy Operations Guy

      Re: My workaround...

      Its fun to run things on other ports. I run ssh on a high-numbered port and run a dummy version of ssh on 22, it just grabs the username / password and the IP of the machine into a csv file and then respond with 'access denied', (Its actually just OpenSSH compiled with an authentication library that does nothing but writes out the data given to it). Now I have a nice big list of usernames and passwords from the bots, and since its coming from multiple bot-networks, I get a wide variety and can sort on the most common to get a very efficient list that I then use for pen testing. That list has greatly reduced my time-to-compromise for my pen tests.

      Only our IT staff are allowed to log in via SSH, and they use key-based authentication and are given files that specific distrust the public keys given out by my fake ssh server (That key happens to be 00:11:22:33:44....).

  13. Anonymous Coward
    Anonymous Coward

    Not good

    I suspect I'm not alone in being lazy with keys - I use them without a passphrase so I can jump between systems without typing passphrase or password. This means that if one of these systems is compromised and someone steals my private key, they have access to all of the systems.

    On the plus side, the systems are mostly secure. On the minus side, I will have to generate a new key for systems that are wholly mine. If someone gets the key for those, I'm the one to blame.

  14. PassiveSmoking

    I think the time has finally come to admit that security-critical subsystems should never be written in a language as hairy as C. There's so many gotchas (double-free, dangling pointers, buffer overruns, etc etc etc) that you can't depend on C code to keep sensitive data private.

    We need an SSH library written in something that doesn't let the programmer make so many mistakes and makes it very obvious when they do make one, preferentially one that does all the error-prone memory management for the programmer. C# or Swift, maybe?

    1. teknopaul

      Java

      Java libs exists if you are willing to accept the overhead of a Virtual Machine.

      1. PassiveSmoking

        Re: Java

        I nearly said java, but then I remembered how many security flaws the JVM and JDK seem to lead to so thought better of it.

      2. Anonymous Coward
        Anonymous Coward

        Re: Java

        "Java libs exists if you are willing to accept the overhead of a Virtual Machine."

        ..and the fact that the VM is likely written in C/C++.

    2. Peter Gathercole Silver badge

      Languages other than C @Passive Smoking

      At the risk of angering the anti-C lobby, it is unfortunate that trusting a language that implements things like strict bounds, type and syntax checking is not a universal panacea. You're just exporting your trust to another component that could possibly be very complex.

      Consider the following potential headline:

      "Devs told to patch their <vendors implementation of language of choice> development environment, recompile and re-ship all applications due to security checking bug in <vendors implementation of language of choice>'s compiler and runtime."

      This becomes more complicated for users of software who may not be aware of the development environment used for the software they've purchased or otherwise procured.

      Admittedly this is a bit of a contrived scenario, and there is a good chance that because of run-time linking, it may only be necessary to provide a new execution environment or run-time libraries that provide the fix, but just switching to a more strict language does not ensure that applications are guaranteed to be more secure.

      At least, where the bug is in the C source code, it is sufficiently primitive that you can see the error in the source of the application, and not have to trawl your development environment.

      1. Roland6 Silver badge
        Pint

        Re: Languages other than C @Passive Smoking

        Well the only language that comes close to satisfying the requirement would be Ada; but only if you also use a certified compiler...

        There are good reasons why C became the language of choice for systems programmers; the mistake was allowing application programmers to use it. :)

        1. Surreal
          Thumb Up

          Re: Languages other than C @Passive Smoking

          "If I want to do floating point math on a character string, the compiler shouldn't stop me!" Me, twenty-something years ago.

      2. This post has been deleted by its author

  15. John Robson Silver badge

    Private key on the server???

    Wha'

    Why is it ever transmitted - surely the appropriate way to do auth forwarding (which is useful) is for the server to pass the auth requests back to the client (which may pass them back to the next client etc.) until it's at the machine with the private key

    1. Peter Gathercole Silver badge

      Re: Private key on the server??? @John Robson

      It's not on the server. It's cached in memory on the client to allow this roving feature, and the second vulnerability can be used by a rogue server to snaffle it from the cache.

      1. Martin
        WTF?

        Re: Private key on the server??? @John Robson

        Well, it's too late now - but if it was never implemented on the server, how come it was the default on the client??

        1. Remy Redert

          Re: Private key on the server??? @John Robson

          Because nothing needs to be implemented on the server. It's just the client keeping your key in memory so that if the connection is dropped for any reason, the client can automatically reestablish the connection without bothering the user about it. If the drop is short enough, the user might not even know his connection was dropped.

  16. phuzz Silver badge

    Workaroud breaks putty

    Just a heads up for everyone, if you apply the workaround (setting "UseRoaming no" in OpenSSH's config) then you will get "Connection Refused" from putty if you try and login. I'm not sure what it is that's rejecting the connection yet.

    1. phuzz Silver badge
      Facepalm

      Re: Workaroud breaks putty

      Ulp, ignore that, if you add "UseRoaming no" to sshd.conf (rather than ssh.conf) then you break SSH, and that is of course what I've done. (thank fsck for puppet still working and being able to fix my cockup)

      Not that anyone else is going to be daft enough to make that mistake, right?

      1. crayon

        Re: Workaroud breaks putty

        When messing around with ssh on a remote machine always keep at least 1 ssh connection alive, that you can stop/restart the sshd on the remote machine and if there are any problems you can use your existing connection to correct it.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like