12 ms·

The OpenSSH Bug That Wasn't

129 points by glass- 11y ago

geerlingguy 11y ago
Key takeaway: > And as several correspondents have reminded me already -- switching your sshd to keys only authentication will let you sleep better at night. Even with fail2ban and limited retries, there's no excuse for using password-based authentication anymore. Use an SSH key, protect the key with a password, and turn off password login on all your servers. Other than that, the main gist of this post is: on most platforms, the default settings for remote login already make brute-force login attempts annoying at best, and with fail2ban or something similar, it's a non-issue.
- feld 11y ago
  Unless they can provide a username that crashes fail2ban via blowing up the regex parsing... and then they get all the free tries they want. fail2ban/sshguard/etc are not infallible. Someone will find a way to break them.
  - mzs 11y ago
    I think fail2ban does not do IPv6 yet.
    - Aloha 11y ago
      I also get 0 attempts via IPv6 interestingly enough. That said, I think fail2ban does support v6 now, but not all of the firewalls do (like ipfw on my ancient ppc mac)
- jandrese 11y ago
  Then you're screwed when you need to log on to your server from some random machine that doesn't have your key installed.
  - cbhl 11y ago
    You can mitigate this by having lots of machines with your key installed (at least two), in different physical locations.
  - TheDong 11y ago
    Good. If you can login from "some random machine" that means your password is terribly weak as well. Use a password manager, generate passwords with over 100 bits of entropy, and then you can't log into anything without it present. Now start carrying around your password manager on an encrypted thumbdrive, along with your gpg key and private ssh key with the decryption password + password manager password being the only ones you remember. Any password a human creates and remembers is a problem. The best mitigation is to only remember passwords that are only useful in conjunction with physical access (the password manager / decryption ones).
    - ChristianBundy 11y ago
      >generate passwords with over 100 bits of entropy Is this arbitrary, or is there a specific reason you recommend at least 100 bits of entropy?
      - UnoriginalGuy 11y ago
        Not them, but this is arbitrary, and frankly a confusing way of even defining a password's strength. A password's strength is measured by both how it was created and also its absolute length. In this case they're simply calling anything longer than 12.5 ASCII characters or 6.25 Unicode characters secure. While those are good solid lengths for passwords (in both cases due to the larger character set of Unicode), without knowing exactly how they were calculated it is completely arbitrary. For example for a sentence-based password, 100 bits is insecure. But for a password generated using the secure random number generator, it is absolute unbreakable e.g. "goodnight moon": Insecure but 120 bits (16 chars) of 'entropy' "5%ML#_rjMe": Secure but "only" 80 bits (10 chars) of 'entropy' Now you could argue, that the word 'entropy' would discount any sentence based passwords by definition, but that's not how I've seen people [mis]use it. They call any content of a password that password's 'entropy.' I also want to take a moment to make fun of people measuring character passwords in bits (as opposed to characters). The whole bits thing started when people are contrasting character based passwords with other types of passwords like certificate based (as a way of showing how much more secure certificate based authentication is). It makes absolutely no sense to use bits in a discussion about purely character based passwords, and people only do it because they witness others do it but have no concept of WHY.
- heywire 11y ago
  I've always wanted to disable password based auth, but I am worried that if I need to connect to my machine in a pinch from some random device (wife's phone, borrowed machine from friend, work, etc), that I won't be able to connect. How do people get around this? Keep in mind that I'm talking about home machines and hobby VM instances, I do not manage any production servers or anything.
  - UnoriginalGuy 11y ago
    Create a normal user, DON'T add them to the sudo group (or any other special group), and then generate keys for them. Store those keys in some online "cloud" storage (DropBox, Google Drive, OneDrive, et al). Then if you need to get in, download the key, type in the password, login as that user, and the su up to root by entering the password only you know. As an additional layer of security you could encrypt the key using AES-256 (e.g. 7Zip archive, Microsoft Office's Word .docx (NOT .doc) format (just drag drop the file into Word, "Encrypt with password") now AES-256 encrypted, others). Now you have four layers of protection: - su password. - Key password. - AES-256 encryption password. - "Cloud" storage credentials.
    - larrys 11y ago
      So in short store the keys in some place that you have easy access to by a password. Kind of a version of two factor "something you know and something you have" whereby the "something you have" is the cloud storage device with the key.
    - cbsmith 11y ago
      While I'm a big believer in defense in depth, I think this adds a lot more complexity on the usability side without really improving the overall security. You'd be better off just protecting the private key with more trials and storing it with whichever cloud storage solution you have the most confidence in.
  - kryptiskt 11y ago
    Put a key on your phone or an USB stick. I make a key for every machine that I have, and that keys never leaves that machine. In addition I keep another key that I can use to get started again if my laptop gets stolen or breaks. If I lose the phone, there's a pretty good password on that key that should give me ample time to remove access rights for it.
- voidlogic 11y ago
  To secure SSH, the more I care about a system the farther down this list I go. 1. Disable root 2. Use keys, disable passwords 3. Install fail2ban 4. Restrict incoming subnets 5. MathAuthTries = 1 6. Run on high random port 7. Use port knocking
  - steckerbrett 11y ago
    If your threat model has someone stealing your private key and breaking/obtaining the password to it, none of the other measures are going to mean anything as they have root on your box. With root they can bypass the access restrictions, knocking, whatever else. 2FA with an external device would probably make more sense than any of them and be significantly less irritating.
    - emidln 11y ago
      That assumes that stealing your private key is the same thing as sending arbitrary packets from your machine, otherwise things like restricting subnets/ip addresses and port knocking could still be useful layers. How different exfil of a private key from being able to send arbitrary packets on the user's machine is...probably not that different under most circumstances I'd guess.
    - voidlogic 11y ago
      I'd recommend encrypting your private keys if needed with a pass-phrase. I'd also recommend still requiring a sudo password on the other end and sending auth events to a auditing server. 2 factor with a token is ideal, I suppose I should have added that to the list, but that is outside of feasibility for most users. Still, for someone who doesn't have RSA tokens etc available, assuming your remote machine doesn't get owned and someone doesn't extract your pass-phrase with a wrench, that list makes for a very secure system.
      - cbsmith 11y ago
        > I'd also recommend still requiring a sudo password on the other end and sending auth events to a auditing server. You should be auditing everything already, and adding in sudo now adds another attack vector. You also now have two different accounts that can be manipulated to compromise a system.
- scintill76 11y ago
  I've been toying with the idea of making a tool to derive SSH keys directly from memorable passphrases, with something like scrypt. Almost as convenient as a normal passphrase, almost as secure as a random key! ("Secure" because presumably no script kiddies are bruteforcing keys like they are bruteforcing passwords.) Besides the dubious security value, another reason I haven't bothered is that if you don't have convenient+secure access to a proper key, you're not going to have convenient+secure access to the key generator either. Maybe it could still be an excuse to learn a new language and how SSH keys work. I don't know if I could rationalize even tossing it up on Github with warnings though.
  - nickpsecurity 11y ago
    Generating simple ones then encrypt & MAC them with password-derived key seems simpler. There's standard constructions for each step, too.
  - cbsmith 11y ago
    Yeah, I'm not seeing the point of doing that. You might as well create the key, encrypt it with the passphrase as per usual, and then post it online for all to see. It's effectively the same thing as generating the key from the pass phrase, except you are mixing in a nice giant product of two primes in to the mix.
    - scintill76 11y ago
      Well, I don't know a lot of the math and crypto, but I would probably seed an RNG from the stretched key and then pull large primes out just as ssh-keygen would. You're right, though -- given my "requirements", it's not much more to assume a convenient place to store a normal, encrypted key. It can be public since I already based my security on the password strength and some obscurity. I wouldn't use either of these ideas for any serious production server. For the deterministic key, you could "backdoor" ssh-keygen's RNG through something like LD_PRELOAD... at that point it's probably just piping a couple of pre-made shell utils together, which could be more portable and simple than rolling-your-own all the key export stuff. Actually, this strikes me as potentially useful and secure in some niche cases where you don't trust your RNG and/or storage. Use diceware and write your long key down, derive anew for each use. Maybe it's silly, but I would consider something like that (at least the initial deriving part) if I were very paranoid or making a long-lived, deeply-deployed key. Here's a deterministic Ed25519 SSH key generator that takes a 32-byte seed: https://github.com/mithrandi/ssh-key-generator https://github.com/mithrandi/ssh-key-generator
j_m_b 11y ago
I am curious as to what happens when this is done with an existent user? I feel like there would be different behaviors for timeouts when a non-existent username is used and when a wrong password is used for an existent username.
- feld 11y ago
  No, the behavior needs to be identical in all failure cases or attackers can use the different feedback to learn valid usernames, etc
  - j_m_b 11y ago
    I should have elaborated better. I think that the feedback should in theory always be the same. However, the check for existent user and the check for correct password are different procedures in the program. The program masks this fact by always having one feedback prompt for actions that don't result in login. Perhaps the original bug report only allowed multiple retries for existent users but not for non-existent users, thus shattering the illusion that the feedback is always the same.
feld 11y ago
Thankfully my use of PAM is for 2FA with SSH when I don't have my key. So they wouldn't have been successful in pulling off a bruteforce anyway. But it's annoying that their attempts weren't being limited as it can waste resources...
- currysausage 11y ago
  You wouldn't have a working config at hand for requiring TOTP (Google Authenticator) only for OpenSSH password logins on Debian, would you?
akkartik 11y ago
Oh, good old PAM: http://web.archive.org/web/20131205090841/http://deadmemes.net/2010/10/19/fear-and-loathing-in-debianubuntu-or-who-needs-etcmotd http://web.archive.org/web/20131205090841/http://deadmemes.n... (Discussed previously: https://news.ycombinator.com/item?id=3325510 https://news.ycombinator.com/item?id=3325510)
- enum_write2 11y ago
  Security glory hole, is security glory hole!
liveoneggs 11y ago
NetBSD is integrating a system called blacklistd to address fail2ban being less than elegant. http://netbsd.gw.com/cgi-bin/man-cgi?blacklistd++NetBSD-current http://netbsd.gw.com/cgi-bin/man-cgi?blacklistd++NetBSD-curr...
- RexRollman 11y ago
  Doesn't NetBSD use PAM? It might behave the same way.
hyperion2010 11y ago
I have disabled PAM by default on all my boxes that run sshd for the last 9 years out of habit, I long ago forgot the reason why (probably because the gentoo sshd handbook entry said it was a good idea). Why UsePAM is set to yes in sshd_config by default on many distros is beyond me.
- ak217 11y ago
  Key problem: aside from PAM, there is no way to use TOTP-based 2FA on your SSH server. And any modern security setup requires 2FA.
  - tete 11y ago
    OpenBSD has bsd_auth and it works well with things like googleauth (HOTP, TOTP), s/key, etc. I think the problem is that somehow everyone ended up with PAM and are now somewhat stuck with it. FreeBSD too.
    - ak217 11y ago
      Good to know, thanks! I hope this gets ported to Debian/Ubuntu... I wish it shipped with built-in 2FA capability.
- ajross 11y ago
  Because PAM is the default authentication framework on all those distros. Yes, it's a disaster of complexity and something pretty much no one understands. But it's what we have. Maybe a rearchitected replacement will land in systemd someday...
  - mjard 11y ago
    Or in pulseaudio as a master troll.
  - digi_owl 11y ago
    Would that be systemd-pamd or s-pamd?
baby 11y ago
They talk about FreeBSD in the original article and the guy tests that on other OS and say it's not a serious vuln? This is a serious vuln for FreeBSD. Period.
- glass- 11y ago
  > They talk about FreeBSD in the original article and the guy tests that on other OS and say it's not a serious vuln? Mr Hansteen is saying it is not a serious OpenSSH vuln, like the tech media is claiming it is. > This is a serious vuln for FreeBSD. Period. That's why the original disclosure and subsequent news articles clearly stated it was a FreeBSD and/or PAM vulnerability, and didn't run with headlines such as "OpenSSH keyboard-interactive authentication brute force vulnerability"[0] or "Bug in widely used OpenSSH opens servers to password cracking"[1]. [0] https://kingcope.wordpress.com/2015/07/16/openssh-keyboard-interactive-authentication-brute-force-vulnerability-maxauthtries-bypass/ https://kingcope.wordpress.com/2015/07/16/openssh-keyboard-i... [1] http://arstechnica.com/security/2015/07/bug-in-widely-used-openssh-opens-servers-to-password-cracking/ http://arstechnica.com/security/2015/07/bug-in-widely-used-o...
cbsmith 11y ago
This really is a bug in how OpenSSH USE_PAM is implemented. Particularly if you presume that PAM is the devil, the last thing you want to do, from a security standpoint, is to let a client dictate how a server applies PAM. The policy _has_ to be entirely controlled by the server's config. Once you let the client decide, you're just asking for things to go wrong.
- acqq 11y ago
  Yes, and this guy, quoted by the article author: "I wouldn't call that an OpenSSH bug. I would call it a systemic design flaw in PAM." is then clearly wrong, it is an OpenSSH bug.
  - cbsmith 11y ago
    Well, it sort of isn't, because the OpenBSD team designed OpenSSH to not use PAM at all. PAM was patched in by some folks, and clearly they got it wrong, but I suspect the OpenSSH team doesn't see that as "part of OpenSSH".
    - stsp 11y ago
      PAM support is part of OpenSSH portable releases. http://www.openssh.com/faq.html#3.15 http://www.openssh.com/faq.html#3.15
gosukiwi 11y ago
Lol'd at the blog's title
deleted 11y ago
[deleted]
pellaeon 11y ago
FreeBSD hasn't released a patch, so I patched it myself. https://nyllep.wordpress.com/2015/07/25/emergency-fix-for-cve-2015-5600-on-freebsd/ https://nyllep.wordpress.com/2015/07/25/emergency-fix-for-cv...

129 points by glass- 11y ago

Key takeaway: > And as several correspondents have reminded me already -- switching your sshd to keys only authentication will let you sleep better at night. Even with fail2ban and limited retries, there's no excuse for using password-based authentication anymore. Use an SSH key, protect the key with a password, and turn off password login on all your servers. Other than that, the main gist of this post is: on most platforms, the default settings for remote login already make brute-force login attempts annoying at best, and with fail2ban or something similar, it's a non-issue.

feld 11y ago
Unless they can provide a username that crashes fail2ban via blowing up the regex parsing... and then they get all the free tries they want. fail2ban/sshguard/etc are not infallible. Someone will find a way to break them.
- mzs 11y ago
  I think fail2ban does not do IPv6 yet.
  - Aloha 11y ago
    I also get 0 attempts via IPv6 interestingly enough. That said, I think fail2ban does support v6 now, but not all of the firewalls do (like ipfw on my ancient ppc mac)
jandrese 11y ago
Then you're screwed when you need to log on to your server from some random machine that doesn't have your key installed.
- cbhl 11y ago
  You can mitigate this by having lots of machines with your key installed (at least two), in different physical locations.
- TheDong 11y ago
  Good. If you can login from "some random machine" that means your password is terribly weak as well. Use a password manager, generate passwords with over 100 bits of entropy, and then you can't log into anything without it present. Now start carrying around your password manager on an encrypted thumbdrive, along with your gpg key and private ssh key with the decryption password + password manager password being the only ones you remember. Any password a human creates and remembers is a problem. The best mitigation is to only remember passwords that are only useful in conjunction with physical access (the password manager / decryption ones).
  - ChristianBundy 11y ago
    >generate passwords with over 100 bits of entropy Is this arbitrary, or is there a specific reason you recommend at least 100 bits of entropy?
    - UnoriginalGuy 11y ago
      Not them, but this is arbitrary, and frankly a confusing way of even defining a password's strength. A password's strength is measured by both how it was created and also its absolute length. In this case they're simply calling anything longer than 12.5 ASCII characters or 6.25 Unicode characters secure. While those are good solid lengths for passwords (in both cases due to the larger character set of Unicode), without knowing exactly how they were calculated it is completely arbitrary. For example for a sentence-based password, 100 bits is insecure. But for a password generated using the secure random number generator, it is absolute unbreakable e.g. "goodnight moon": Insecure but 120 bits (16 chars) of 'entropy' "5%ML#_rjMe": Secure but "only" 80 bits (10 chars) of 'entropy' Now you could argue, that the word 'entropy' would discount any sentence based passwords by definition, but that's not how I've seen people [mis]use it. They call any content of a password that password's 'entropy.' I also want to take a moment to make fun of people measuring character passwords in bits (as opposed to characters). The whole bits thing started when people are contrasting character based passwords with other types of passwords like certificate based (as a way of showing how much more secure certificate based authentication is). It makes absolutely no sense to use bits in a discussion about purely character based passwords, and people only do it because they witness others do it but have no concept of WHY.
heywire 11y ago
I've always wanted to disable password based auth, but I am worried that if I need to connect to my machine in a pinch from some random device (wife's phone, borrowed machine from friend, work, etc), that I won't be able to connect. How do people get around this? Keep in mind that I'm talking about home machines and hobby VM instances, I do not manage any production servers or anything.
- UnoriginalGuy 11y ago
  Create a normal user, DON'T add them to the sudo group (or any other special group), and then generate keys for them. Store those keys in some online "cloud" storage (DropBox, Google Drive, OneDrive, et al). Then if you need to get in, download the key, type in the password, login as that user, and the su up to root by entering the password only you know. As an additional layer of security you could encrypt the key using AES-256 (e.g. 7Zip archive, Microsoft Office's Word .docx (NOT .doc) format (just drag drop the file into Word, "Encrypt with password") now AES-256 encrypted, others). Now you have four layers of protection: - su password. - Key password. - AES-256 encryption password. - "Cloud" storage credentials.
  - larrys 11y ago
    So in short store the keys in some place that you have easy access to by a password. Kind of a version of two factor "something you know and something you have" whereby the "something you have" is the cloud storage device with the key.
  - cbsmith 11y ago
    While I'm a big believer in defense in depth, I think this adds a lot more complexity on the usability side without really improving the overall security. You'd be better off just protecting the private key with more trials and storing it with whichever cloud storage solution you have the most confidence in.
- kryptiskt 11y ago
  Put a key on your phone or an USB stick. I make a key for every machine that I have, and that keys never leaves that machine. In addition I keep another key that I can use to get started again if my laptop gets stolen or breaks. If I lose the phone, there's a pretty good password on that key that should give me ample time to remove access rights for it.
voidlogic 11y ago
To secure SSH, the more I care about a system the farther down this list I go. 1. Disable root 2. Use keys, disable passwords 3. Install fail2ban 4. Restrict incoming subnets 5. MathAuthTries = 1 6. Run on high random port 7. Use port knocking
- steckerbrett 11y ago
  If your threat model has someone stealing your private key and breaking/obtaining the password to it, none of the other measures are going to mean anything as they have root on your box. With root they can bypass the access restrictions, knocking, whatever else. 2FA with an external device would probably make more sense than any of them and be significantly less irritating.
  - emidln 11y ago
    That assumes that stealing your private key is the same thing as sending arbitrary packets from your machine, otherwise things like restricting subnets/ip addresses and port knocking could still be useful layers. How different exfil of a private key from being able to send arbitrary packets on the user's machine is...probably not that different under most circumstances I'd guess.
  - voidlogic 11y ago
    I'd recommend encrypting your private keys if needed with a pass-phrase. I'd also recommend still requiring a sudo password on the other end and sending auth events to a auditing server. 2 factor with a token is ideal, I suppose I should have added that to the list, but that is outside of feasibility for most users. Still, for someone who doesn't have RSA tokens etc available, assuming your remote machine doesn't get owned and someone doesn't extract your pass-phrase with a wrench, that list makes for a very secure system.
    - cbsmith 11y ago
      > I'd also recommend still requiring a sudo password on the other end and sending auth events to a auditing server. You should be auditing everything already, and adding in sudo now adds another attack vector. You also now have two different accounts that can be manipulated to compromise a system.
scintill76 11y ago
I've been toying with the idea of making a tool to derive SSH keys directly from memorable passphrases, with something like scrypt. Almost as convenient as a normal passphrase, almost as secure as a random key! ("Secure" because presumably no script kiddies are bruteforcing keys like they are bruteforcing passwords.) Besides the dubious security value, another reason I haven't bothered is that if you don't have convenient+secure access to a proper key, you're not going to have convenient+secure access to the key generator either. Maybe it could still be an excuse to learn a new language and how SSH keys work. I don't know if I could rationalize even tossing it up on Github with warnings though.
- nickpsecurity 11y ago
  Generating simple ones then encrypt & MAC them with password-derived key seems simpler. There's standard constructions for each step, too.
- cbsmith 11y ago
  Yeah, I'm not seeing the point of doing that. You might as well create the key, encrypt it with the passphrase as per usual, and then post it online for all to see. It's effectively the same thing as generating the key from the pass phrase, except you are mixing in a nice giant product of two primes in to the mix.
  - scintill76 11y ago
    Well, I don't know a lot of the math and crypto, but I would probably seed an RNG from the stretched key and then pull large primes out just as ssh-keygen would. You're right, though -- given my "requirements", it's not much more to assume a convenient place to store a normal, encrypted key. It can be public since I already based my security on the password strength and some obscurity. I wouldn't use either of these ideas for any serious production server. For the deterministic key, you could "backdoor" ssh-keygen's RNG through something like LD_PRELOAD... at that point it's probably just piping a couple of pre-made shell utils together, which could be more portable and simple than rolling-your-own all the key export stuff. Actually, this strikes me as potentially useful and secure in some niche cases where you don't trust your RNG and/or storage. Use diceware and write your long key down, derive anew for each use. Maybe it's silly, but I would consider something like that (at least the initial deriving part) if I were very paranoid or making a long-lived, deeply-deployed key. Here's a deterministic Ed25519 SSH key generator that takes a 32-byte seed: https://github.com/mithrandi/ssh-key-generator https://github.com/mithrandi/ssh-key-generator

j_m_b 11y ago

I am curious as to what happens when this is done with an existent user? I feel like there would be different behaviors for timeouts when a non-existent username is used and when a wrong password is used for an existent username.

feld 11y ago
No, the behavior needs to be identical in all failure cases or attackers can use the different feedback to learn valid usernames, etc
- j_m_b 11y ago
  I should have elaborated better. I think that the feedback should in theory always be the same. However, the check for existent user and the check for correct password are different procedures in the program. The program masks this fact by always having one feedback prompt for actions that don't result in login. Perhaps the original bug report only allowed multiple retries for existent users but not for non-existent users, thus shattering the illusion that the feedback is always the same.

feld 11y ago

Thankfully my use of PAM is for 2FA with SSH when I don't have my key. So they wouldn't have been successful in pulling off a bruteforce anyway. But it's annoying that their attempts weren't being limited as it can waste resources...

currysausage 11y ago
You wouldn't have a working config at hand for requiring TOTP (Google Authenticator) only for OpenSSH password logins on Debian, would you?

akkartik 11y ago

Oh, good old PAM: http://web.archive.org/web/20131205090841/http://deadmemes.net/2010/10/19/fear-and-loathing-in-debianubuntu-or-who-needs-etcmotd http://web.archive.org/web/20131205090841/http://deadmemes.n... (Discussed previously: https://news.ycombinator.com/item?id=3325510 https://news.ycombinator.com/item?id=3325510)

enum_write2 11y ago
Security glory hole, is security glory hole!

liveoneggs 11y ago

NetBSD is integrating a system called blacklistd to address fail2ban being less than elegant. http://netbsd.gw.com/cgi-bin/man-cgi?blacklistd++NetBSD-current http://netbsd.gw.com/cgi-bin/man-cgi?blacklistd++NetBSD-curr...

RexRollman 11y ago
Doesn't NetBSD use PAM? It might behave the same way.

hyperion2010 11y ago

I have disabled PAM by default on all my boxes that run sshd for the last 9 years out of habit, I long ago forgot the reason why (probably because the gentoo sshd handbook entry said it was a good idea). Why UsePAM is set to yes in sshd_config by default on many distros is beyond me.

ak217 11y ago
Key problem: aside from PAM, there is no way to use TOTP-based 2FA on your SSH server. And any modern security setup requires 2FA.
- tete 11y ago
  OpenBSD has bsd_auth and it works well with things like googleauth (HOTP, TOTP), s/key, etc. I think the problem is that somehow everyone ended up with PAM and are now somewhat stuck with it. FreeBSD too.
  - ak217 11y ago
    Good to know, thanks! I hope this gets ported to Debian/Ubuntu... I wish it shipped with built-in 2FA capability.
ajross 11y ago
Because PAM is the default authentication framework on all those distros. Yes, it's a disaster of complexity and something pretty much no one understands. But it's what we have. Maybe a rearchitected replacement will land in systemd someday...
- mjard 11y ago
  Or in pulseaudio as a master troll.
- digi_owl 11y ago
  Would that be systemd-pamd or s-pamd?

baby 11y ago

They talk about FreeBSD in the original article and the guy tests that on other OS and say it's not a serious vuln? This is a serious vuln for FreeBSD. Period.

glass- 11y ago
> They talk about FreeBSD in the original article and the guy tests that on other OS and say it's not a serious vuln? Mr Hansteen is saying it is not a serious OpenSSH vuln, like the tech media is claiming it is. > This is a serious vuln for FreeBSD. Period. That's why the original disclosure and subsequent news articles clearly stated it was a FreeBSD and/or PAM vulnerability, and didn't run with headlines such as "OpenSSH keyboard-interactive authentication brute force vulnerability"[0] or "Bug in widely used OpenSSH opens servers to password cracking"[1]. [0] https://kingcope.wordpress.com/2015/07/16/openssh-keyboard-interactive-authentication-brute-force-vulnerability-maxauthtries-bypass/ https://kingcope.wordpress.com/2015/07/16/openssh-keyboard-i... [1] http://arstechnica.com/security/2015/07/bug-in-widely-used-openssh-opens-servers-to-password-cracking/ http://arstechnica.com/security/2015/07/bug-in-widely-used-o...

cbsmith 11y ago

This really is a bug in how OpenSSH USE_PAM is implemented. Particularly if you presume that PAM is the devil, the last thing you want to do, from a security standpoint, is to let a client dictate how a server applies PAM. The policy _has_ to be entirely controlled by the server's config. Once you let the client decide, you're just asking for things to go wrong.

acqq 11y ago
Yes, and this guy, quoted by the article author: "I wouldn't call that an OpenSSH bug. I would call it a systemic design flaw in PAM." is then clearly wrong, it is an OpenSSH bug.
- cbsmith 11y ago
  Well, it sort of isn't, because the OpenBSD team designed OpenSSH to not use PAM at all. PAM was patched in by some folks, and clearly they got it wrong, but I suspect the OpenSSH team doesn't see that as "part of OpenSSH".
  - stsp 11y ago
    PAM support is part of OpenSSH portable releases. http://www.openssh.com/faq.html#3.15 http://www.openssh.com/faq.html#3.15

gosukiwi 11y ago

Lol'd at the blog's title

deleted 11y ago

[deleted]

pellaeon 11y ago

FreeBSD hasn't released a patch, so I patched it myself. https://nyllep.wordpress.com/2015/07/25/emergency-fix-for-cve-2015-5600-on-freebsd/ https://nyllep.wordpress.com/2015/07/25/emergency-fix-for-cv...