Slashdot Mirror

← Back to Stories (view on slashdot.org)

The OpenSSH Bug That Wasn't

Posted by timothy on from the or-only-kind-of-is dept.

badger.foo writes: Get your facts straight before reporting, is the main takeaway from Peter Hansteen's latest piece, The OpenSSH Bug That Wasn't. OpenSSH servers that are set up to use PAM for authentication and with a very specific (non-default on OpenBSD and most other places) setup are in fact vulnerable, and fixing the configuration is trivial.

55 comments

  1. Spoiler by bobstreo · · Score: 5, Informative

    According to the article, it's a bug in PAM.

    You shouldn't see this behaviour with SSH unless you have PAM authentication turned on. And apparently only in FreeBSD ?

      And as OpenBSD developer Marc Espie says in his message,

            Not surprisingly, as the patch clearly shows, the problem is right smack in the middle of USE_PAM code.

            I wouldn't call that an OpenSSH bug. I would call it a systemic design flaw in PAM. As usual. LOTS of security holes in authentication systems stem from PAM. Why ? Because that stuff is over designed. Difficult to configure. Gives you MORE than you need to hang yourself several times over. It's been that way for as long as I can remember.

    1. Re:Spoiler by Forever+Wondering · · Score: 3, Interesting

      I just tested this (I've got UsePAM yes in sshd_config) on fedora 21 and I only get three tries before disconnect. So, what's special about freebsd?

      --
      Like a good neighbor, fsck is there ...
    2. Re:Spoiler by Anonymous Coward · · Score: 1

      Different PAM settings, different /bin/login, different sshd_config settings, different defaults of SSH version versus versoin 2? Who knows?

    3. Re:Spoiler by Anonymous Coward · · Score: 0

      Gives you MORE than you need to hang yourself several times over.

      This isn't crazy; This. Is. *nix!

    4. Re:Spoiler by Anonymuous+Coward · · Score: 1

      According to the article, it's a bug in PAM.

      Then the article (which I wouldn't bother to read) is misleading.

      The bug is inside openssh proper. This is how they fixed it:

      http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/auth2-chall.c.diff?r1=1.42&r2=1.43&f=h

      Basically, OpenSSH was accepting a list of 'keyboard interactive devices' where the same device apeared thousands of times, completely bypassing the MaxAuthTries setting from sshd_config (default 6).

      This is well explained in kingcope's original report.

      https://kingcope.wordpress.com/2015/07/16/openssh-keyboard-interactive-authentication-brute-force-vulnerability-maxauthtries-bypass/

      It's very much a bug, and the code in auth2-call.c looks silly enough (just like the fix, btw) that there's a high probability of other such gross bugs in there.

      And as OpenBSD developer Marc Espie says in his message,

      Not surprisingly, as the patch clearly shows, the problem is right smack in the middle of USE_PAM code.

      That doesn't seem to be the case.

      In fact, my will guess is that the default pam_faildelay is what stays in the way of this bug's being exploitable on Linux.

    5. Re:Spoiler by phantomfive · · Score: 2

      Fred Brooks pointed out that integrating your code with other systems is one of the most intractable problems of software development. Not only does it increase the time for development dramatically (which he pointed out in the first chapter of MMM), it is also necessary to understand the behavior of both sides extremely well.

      Although the OpenBSD team is very good at avoiding bugs, it is not surprising that a vuln would show up here, on a system boundary like this.

      --
      "First they came for the slanderers and i said nothing."
    6. Re:Spoiler by Forever+Wondering · · Score: 1

      Okay, just answered my own question. I also had "ChallengeResponseAuthentication no" in my sshd_config. When I changed this to "yes", I was able to reproduce the bug. In the original article, I had done a /. post with a link to a redhat page explaining why they used "no" and it is because of keyboard interactive [which tracks CRA].

      My original slashdot post, with additional security I use and the logging of script kiddies I've been doing for years: http://slashdot.org/comments.p...

      The redhat page: https://access.redhat.com/solu...

      --
      Like a good neighbor, fsck is there ...
  2. It may not be an OpenSSH bug ... by Anonymous Coward · · Score: 1

    ... but still, if PAM is configured with OpenSSH, a PAM bug may sometimes be mis-identified to be an OpenSSH bug

    No matter if it's a PAM bug or an OpenSSH bug, a but report which points out a vulnerability is good thing for the community - something that will allow the users to tighten up their configuration to deny that bug from being able to function in the first place

    1. Re:It may not be an OpenSSH bug ... by Demonoid-Penguin · · Score: 1, Funny

      ... but still, if PAM is configured with OpenSSH, a PAM bug may sometimes be mis-identified to be an OpenSSH bug

      No matter if it's a PAM bug or an OpenSSH bug, a but report which points out a vulnerability is good thing for the community - something that will allow the users to tighten up their configuration to deny that bug from being able to function in the first place

      Does not parse.

      tl;dr Huh?

    2. Re:It may not be an OpenSSH bug ... by Zontar+The+Mindless · · Score: 1

      That's because your parser's broken.

      --
      Il n'y a pas de Planet B.
    3. Re:It may not be an OpenSSH bug ... by Demonoid-Penguin · · Score: 3

      That's because your parser's broken.

      No, my parser is fine. Your's matches your usename - that is just a pseudonym, right?

      ... but still, if PAM is configured with OpenSSH, a PAM bug may sometimes be mis-identified to be an OpenSSH bug

      Then it's not an OpenSSH bug. (and that's not English)

      No matter if it's a PAM bug or an OpenSSH bug, a but report which points out a vulnerability is good thing for the community

      (assuming the coward means "bug report"). No - it's a waste of limited resources. Big scare about an insecurity in OpenSSH which did not exist

      "King Cope" posted to the Full Disclosure mailing list Fri, 17 Jul 2015 21:23:36 +0000 (UTC) (according to my email system) with an exploit

      ssh -lusername -oKbdInteractiveDevices=`perl -e 'print "pam," x
      10000'` targethost

      and "a patch for openssh-6.9p1 that will allow to use a wordlist and any passwords piped to the ssh process to be used in order to crack passwords remotely.". By applying the patch it allows an attacker to try as many attacks as possible within the gracetime (2 minutes). The best case scenario allows an estimated 10000 attempts in that time period.

      I only read it because he's usually good for a laugh, or, as is this case, a face-palm.

      Which might brute force a very short (stupid) password that would fall to a small, lucky, dictionary attack. Which is why BP is to use a key.

      He mentions in that email that it has been "tested against a new FreeBSD 10.1 system and older FreeBSD versions such as version 6.2.".

      something that will allow the users to tighten up their configuration to deny that bug from being able to function in the first place

      Tighten up what? Their SSH configurations? It is a bug in PAM that is restricted to small range of BSD versions.
      Tightening up SSH, which is already as tight as it can be against the exploit unless you deliberately loosened it (as Sex Conker would recommend - but he's an idiot). Default configurations already stop the exploit (no root ssh login, all ssh logins with keys).

      The exploit would only affect insecure systems that use piss poor password security - and even then only on a limited number of BSD systems.

      That belief is a broken as the idea that if there's a story a cigarette lighter exploded, which causes a panic about cigarette lighters, and calls for a recall of them - turns out to be a case of someone in petrol soaked pants being injured when the cigarette lighter in their pocket exploded as a result of them falling out of a building and landing on their arse. Unfortunately they had a box of matches in the back pocket which exploded on impact, setting fire to their pants - the heat of the flames caused the cigarette lighter to explode.

      The moral of the story is not - oh the panic about cigarette lighters exploding was a good thing.
      It would have been a "good thing" if that energy was spent on warning people of the dangers of wearing petrol pants and falling out of windows.

      It would be a "good thing" if people focused on the actual bug in PAM instead of trying to justify their earlier panic (the sky is not falling).

      The coward that wrote that gibberish you're defending , who is obviously not you, is referring to what bug report?Hint: there was none, just another of King Cope's self-promoting and inflated security exploits (he also thinks robots.txt is a security hole). You fell for it, get over it.

    4. Re:It may not be an OpenSSH bug ... by Hognoxious · · Score: 4, Funny

      No, my parser is fine. Your's matches your usename

      Luckily I just ordered a new pack of needles for my irony meter.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  3. I love the attitude by Sowelu · · Score: 3, Insightful

    I love the attitude of one of the anon commenters: if you don't know enough to configure every single security option on your system right out of the box, you shouldn't have your *nix machine hooked up to the internet. Truly, this is the year of *nix on the desktop.

    1. Re:I love the attitude by Anonymous Coward · · Score: 1

      I love the attitude of one of the anon commenters: if you don't know enough to configure every single security option on your system right out of the box, you shouldn't have your *nix machine hooked up to the internet. Truly, this is the year of *nix on the desktop.

      Firstly, disabling password-only auth (for keys) is one of the very basic security rules for a good SSH config. You'll find it in nearly every tutorial, along with disabling root logins. It definitely isn't obscure, as you suggest, and yields hundreds of thousands of search results (for guides, blogs, wikis, etc.)

      Secondly, he talks about the "open internet". As in, a server accessible to (attackable by) anyone and everyone. This has nothing to do with the desktop. Stop trying to twist it into an argument against the *nix community.

    2. Re:I love the attitude by NotInHere · · Score: 1

      disabling root logins has no security benefit at all. Keep the keys secure, everything is fine. In some cases there is a small benefit, but in most there is none.

    3. Re:I love the attitude by Anonymous Coward · · Score: 1

      disabling root logins has no security benefit at all. Keep the keys secure, everything is fine. In some cases there is a small benefit, but in most there is none.

      Disabling remote root logins multiplies the attempts needed to break in which can be detected and banned. You'd have to guess usernames too if it weren't for an allowed remote root login in many linux distros. Debian only changed the default in their latest release for example.

    4. Re:I love the attitude by Anonymous Coward · · Score: 2, Informative

      Explain to me how having to guess a username AND a password during a bruteforce attempt is the same as already knowing and being able to log in as a uid=0 user (root) and just having to bruteforce the password.
      "No security benefit at all" != makes my life more difficult because I have to learn how to use su and leave audit trails and unique users in my sloppy throwing code around developer life.

    5. Re:I love the attitude by Anonymous Coward · · Score: 0

      You could just change the username of root :)

    6. Re:I love the attitude by Bert64 · · Score: 3, Interesting

      That's very true, and doesn't just apply to unix based systems... You should not be connecting a system to a public network unless you fully understand and control it, and windows is actually much worse in this regard because its massively more complicated than any unix.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    7. Re:I love the attitude by Anonymous Coward · · Score: 0

      Quick, go unplug your grandmother's computer from the internet. And their ipad, and the satellite TV receiver, and the cell phone, and the Roku.

    8. Re:I love the attitude by Anonymous Coward · · Score: 1

      It's silly, but I wouldn't be surprised if a large bunch of automated hacking scripts break if you do that.

      Security through obfuscation sucks if it is the only means of protection. As an extra layer on top of something else? It will make life harder for anyone trying to break in, stealing away their valuable time.
      If everyone made a unique twist on their own security then automated hacking would be a thing of the past.

    9. Re:I love the attitude by ogdenk · · Score: 3, Interesting

      If grandma knew how vulnerable she truly was the way a good sysadmin should, she'd cut the cords herself with a pair of sewing shears.

    10. Re:I love the attitude by TCM · · Score: 1

      Simple, the username is to be considered public knowledge. It's visible when entering it everywhere, it may be in ~/.ssh/config, it's not a secret.

      Just assume the whole world knows it already. All strength must come from the password either way, so don't even start to treat the username as some sort of secret.

      --
      Of course it runs NetBSD. BTC: 1NT7QvbetmANwaMzhpVL6
    11. Re:I love the attitude by DarkOx · · Score: 3, Interesting

      Generally I agree but if you are going to brute force knowing the user names are half the battle. root is one you know will be there and its a valuable one if you could get it.

      I never try and brute force passwords on pentests. I usually brute force user names with a handful of bad passwords. That is once I work out how user names are constructed fist letter first name last name or whatever is being used. I'll dictionary like this:

      asmith:password1
      asmith:P@$$w0rd
      asmith:Summer2015!
      bsmith:password1
      bsmith:P@$$w0rd
      bsmith:Summer2015!

      If the organization is big enough someone has used one of the top 100 worst passwords. Hopefully its not a sysadmin.

      Then it comes the issue of the root account being shared. No nobody should ever be allowed to logon as root directly. Why because than you have no accountability. Was it Jim, Bob, Ted, or Sally who did that? I don't know. On the other hand if you have some kind of secure logging in place and you make people logon with their own account you at least have the log entry of who did sudo or su. Attribution is important!

      Finally if Bob leaves the company yes the root password needs to be changed. Sometimes though there are reasons you can't immediately do that. Usually these are problems in and of themselves but that is neither here nor there. It should be safe to disable or delete Bobs account the moment he walks out the door. If root logins are not allowed you will be 'mostly' even if it takes Sally a few days to change the root password everywhere.

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    12. Re:I love the attitude by Anonymous Coward · · Score: 1

      found the guy who relies on root logins for hax

  4. No it's a bug in OpenSSH by pavon · · Score: 3, Informative

    It is a bug in OpenSSH misusing PAM. They argue that these sorts of bugs wouldn't be as easy to make if PAM was less complicated, which is certainly true, but it is still a bug in OpenSSH.

    1. Re:No it's a bug in OpenSSH by Anonymous Coward · · Score: 1

      It is a bug in OpenSSH misusing PAM. They argue that these sorts of bugs wouldn't be as easy to make if PAM was less complicated, which is certainly true, but it is still a bug in OpenSSH.

      Prove it. Cite the relevant code. Otherwise, you have no defensible position.

      Marc Espie said the error exists in FreeBSD's PAM implementation. A Slashdot comment that predates your own indicates that enabling PAM support in OpenSSH on Fedora still limits to three login attempts, thus implying the problem does lie with FreeBSD's PAM implementation.

      On the other hand, you merely have a bald assertion unsupported by evidence.

      Even absent the anecdotal evidence against your assertion, I'll believe an OpenBSD developer over an unproven comment on Slashdot. It's a matter of credibility.

    2. Re:No it's a bug in OpenSSH by Anonymous Coward · · Score: 0

      The funny thing is, as a novice system admin that had to learn PAM, both the "old" way and the "new" way. I learned it, down to reading the code of it and various modules to understand what was going on, and frankly, it's not that complicated.. I don't see why this comment is made.

    3. Re:No it's a bug in OpenSSH by Shimbo · · Score: 1

      It is a bug in OpenSSH misusing PAM. They argue that these sorts of bugs wouldn't be as easy to make if PAM was less complicated, which is certainly true, but it is still a bug in OpenSSH.

      Prove it. Cite the relevant code.

      He doesn't need to: Marc Espie already did.

    4. Re:No it's a bug in OpenSSH by Anonymous Coward · · Score: 0

      Prove it. Cite the relevant code. Otherwise, you have no defensible position.

      Marc Espie said the error exists in FreeBSD's PAM implementation.

      No, he didn't. The blogger in TFA quoted him selectively to make it sound like this was a FreeBSD bug and not an OpenSSH bug. However, as Marc Espie said in the same post that the blogger quoted:

      "Okay, let's admit that the *portable* version of openssh wasn't programmed in a way that's paranoid enough about the failure modes of pam."

    5. Re:No it's a bug in OpenSSH by Raenex · · Score: 1

      Marc Espie said the error exists in FreeBSD's PAM implementation.

      Marc Espie's post, linked from the article: http://marc.info/?l=openbsd-mi...

      "Okay, let's admit that the *portable* version of openssh wasn't programmed in a way that's paranoid enough about the failure modes of pam."

      Lots of hemming and hawing about how PAM sucks and is easy to screw up, and maybe it is, but the bug still exists in OpenSSH code and that's where it was patched:

      https://anongit.mindrot.org/op...

    6. Re:No it's a bug in OpenSSH by Cramer · · Score: 1

      Actually, it's an issue with OpenSSH's blind acceptance of a user supplied device list. The PoC uses "PAM", but any valid device can be used. (hint: PAM isn't the only one.) There's an additional bug in that the code ignores ("overrides") KbdInteractiveAuthentication no -- if I put that in my config, it should be off, PERIOD, anything that requires it is disabled as well.

  5. TL;DR by Anonymous Coward · · Score: 0

    Don't read Slashdot, especially not on the graveyard shift, when they put their "best", Timmy, in charge.

  6. Re: by Anonymous Coward · · Score: 1

    Yay! The BSDs are still better than the Linux/SYSV variants (due to PAM being mainly used on Linux).

  7. fixing the configuration is trivial by El_Muerte_TDS · · Score: 4, Insightful

    > fixing the configuration is trivial

    So trivial that the suggested configuration change is not mentioned anywhere.

    1. Re:fixing the configuration is trivial by CRC'99 · · Score: 1

      > fixing the configuration is trivial

      So trivial that the suggested configuration change is not mentioned anywhere.

      Just like a useful description of the problem.... Obscure news is obscure.

      --
      Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
    2. Re:fixing the configuration is trivial by Demonoid-Penguin · · Score: 1

      > fixing the configuration is trivial

      So trivial that the suggested configuration change is not mentioned anywhere.

      Where did you look? The summary - or your closet? If you don't run FreeBSD you don't have to change anything. If you do - try reading the referenced article. Though if you need to be told the bleeding obvious that won't fix your problem.

    3. Re:fixing the configuration is trivial by arth1 · · Score: 1

      The article does not specify what configuration changes are needed to get the flaw to appear or disappear.
      It references a code patch, which is a completely different thing.

      And from what I can tell, non-BSD systems are vulnerable too - as long as you don't use the default configuration. If you do, you probably should wait for vendor patches anyhow, and are safe while you wait...

    4. Re:fixing the configuration is trivial by Demonoid-Penguin · · Score: 1

      The article does not specify what configuration changes are needed to get the flaw to appear or disappear.

      Agreed. It's a crap summary. The blog post it references is worth reading - as does the BSD list thread I quoted earlier. The many "news" stories, and the reddit thread are not.

      It references a code patch, which is a completely different thing.

      And from what I can tell, non-BSD systems are vulnerable too - as long as you don't use the default configuration. If you do, you probably should wait for vendor patches anyhow, and are safe while you wait...

      It doesn't affect non-BSD systems. It only affects a small number of BSD systems. And in those instances only if the sysadmin does not follow best practices (they'd have to disable default configurations, and then use a stupid password).

    5. Re: fixing the configuration is trivial by Anonymous Coward · · Score: 0

      I knew it! It's a freebsd problem!
      Or is that user?

  8. Get your facts straight before reporting by Anonymous Coward · · Score: 1

    I think that sentence right there is far beyond the scope of today's bloggers playing reporters.

  9. Re: by Anonymous Coward · · Score: 0

    Except that the PAM bug appears to only exist in BSD.

    So actually, no.

  10. However the attitude above is broken by dbIII · · Score: 3, Insightful

    disabling root logins has no security benefit at al

    Of course it does. That former employee that knows the root password or has the keys can't get to it. The current employee that fat fingers a command to the wrong host can't do much damage. That thief with a stolen laptop can't use a key to get full access remotely. There is a very very long list and it's just inexperience, laziness or lack of sleep that's stopping you from thinking of entries in it.

    1. Re:However the attitude above is broken by sjames · · Score: 1

      Set PermitRootLogin without-password

      Then control access with authorized_keys. If someone leaves, remove his key from authorized_keys.

      Next step, laugh at the 'hackers' wasting all that effort trying to guess the root password.

    2. Re:However the attitude above is broken by NotInHere · · Score: 1

      That former employee that knows the root password or has the keys can't get to it.

      Make a good policy, no passwords, only keys, and every employee has one. Then you only have to delete the keys from all boxes, if an employee leaves, done. You will however have to use custom tools for logging, because ssh does only log the key if at VERBOSE loglevel, which you usually don't want.

      The current employee that fat fingers a command to the wrong host can't do much damage.

      That is, I agree, more likely possible. However if an employee has to do "sudo" all the time, they just start turning their brain off while doing it. Too much "are you sure" harms too.

      That thief with a stolen laptop can't use a key to get full access remotely.

      If you require your employees to encrypt their keys with a passphrase, which you should do, then this isn't an issue.

    3. Re:However the attitude above is broken by dbIII · · Score: 1

      Make a good policy, no passwords, only keys, and every employee has one.

      And that laptop thief that is going to get an employees machine eventually is going to have one click access to root on your server - now that's a major fuckup isn't it?

      However if an employee has to do "sudo" all the time, they just start turning their brain off while doing it.

      I prefer "su" so as to keep things entirely separate although others swear by "sudo" for user tracking - either way if they can't keep track of context they should lay off the drugs.

  11. ROFLMAO by Hognoxious · · Score: 1

    Get your facts straight before reporting

    To whom may I address this invoice for a new keyboard?

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  12. You may find this helpful ... by Anonymous Coward · · Score: 0

    Here's a link to conversation few days back at reddit.com/r/netsec/

    OpenSSH keyboard-interactive authentication brute force vulnerability (MaxAuthTries bypass)

    Suggestion from noop_ works well, till pam stuff gets fixed at some point.

    ac

  13. Re: by Anonymous Coward · · Score: 1

    Both FreeBSD and NetBSD use PAM. Sadly, only OpenBSD uses the BSDAuth framework.

  14. You didn't get far in reading by dbIII · · Score: 1
    You didn't get far in reading my post above - "That thief with a stolen laptop can't use a key to get full access remotely" was mentioned, but maybe I should add another. The tiny amount of extra effort required by disabling root logins covers a lot of possibilities. I've gained access to a former workplace as much as three years after leaving by running the wrong old script - whoops! That human intervention of cancelling accounts depends on things like those HR people talking to IT people (Eloi vs Moorlocks in some places). Having a procedure that does not have an unreliable person as a vital part of the chain is a better idea than the latter - or in more diplomatic terms keeping it simple with one less thing to go wrong.

    Next step, laugh at the 'hackers' wasting all that effort trying to guess the root password

    Logs get full of such attempts even when root is not able to login. Once it gets tedious you can install sshgaurd or similar to block them and not be bothered by so many of such fruitless attempts clogging up the logs.

    1. Re:You didn't get far in reading by sjames · · Score: 1

      If HR fails to notify IT to remove an account for someone who has access to root in any way, the same problem happens. That's why I leave it accessible through RSA authentication.

      That same old script would have worked if you used sudo or an IP KVM.

    2. Re:You didn't get far in reading by dbIII · · Score: 1

      That's one of the reasons I don't use sudo on internet facing machines or have a KVM exposed to the internet, but that's another story.
      To sum up I just have the opinion that one step root access from out on the internet is an accident waiting to happen - especially if you are likely to log on from anywhere and not a known trusted address.

    3. Re:You didn't get far in reading by sjames · · Score: 1

      Really, it depends on the environment. If you have servers in a lights out environment rather than 24/7 on-site staff, less moving parts is good.

      It's a shame if where you are asking HR to do all of their job is too much, especially with employees identified as security sensitive.

      If the machine normally doesn't need to allow ssh, you can always choke it down to a pair of very reliable admin servers (Perhaps atom based systems with no moving parts) that authorized users can use as a jumping off point using the ssh-agent (so that the admin servers contain no private keys).