Peter N. M. Hansteen writes about a bug that occurs when Pluggable Authentication Modules (PAM) are used in conjunction with OpenSSH set to keyboard-interactive. The bug first blogged about back on the 16th, which showed a way to bypass MaxAuthTries limits for certain configurations. When the bug is exploited it allows virtually unlimited tries at password authentication, good enough for brute-force password guessing. One easy way to mitigate this is to disable password authentication all together and use only keys with OpenSSH.
Mr. Hansteen tested several various systems on OpenBSD, Linux, and FreeBSD, and could only find issue with the FreeBSD box, as the others apparently had default configurations which did not allow this. The original blog does have a simple one line ssh command to test if your system is vulnerable. Fail2ban should help stop this, but may not completely mitigate depending on firewall rule setup.
Here is some more interesting info on the subject from the OpenBSD mailing list. Most comments seem to indicate that while this may be concerning it probably isn't world-shattering. Still it is something to keep in mind when hardening systems.
(Score: 5, Interesting) by fnj on Monday July 27 2015, @06:21AM
I verified that my FreeBSD boxes were susceptible to this unforgiveable exploit, while nothing else I have is (CentOS, Ubuntu, Arch, etc). Forget the finger-pointing between sshd and PAM. It's a system config issue. The secret is in sshd_config. None of the others came with ChallengeResponseAuthentication set to yes.
The suggested fix (disable password auth altogether) struck me as ludicrously stupid. Here's what I came up with in sshd_config.
* Change ChallengeResponseAuthentication from yes to no
* Change PasswordAuthentication from no to yes
* Obviously my PermitRootLogin is not set to yes (if you really want to know, it's set to without-password so key auth works but password auth does not)
This way, key exchange is still used where available, yet passwords still work as a fallback. None of my boxes have any stupid weak user passwords, so password auth is perfectly secure in the absence of some stupid bug like this one.
Everyone is going to have their own security imperatives and hang-ups, but this approach works fine for me. Clearly CentOS and others think it's a viable approach for a shipped default.
IMHO FreeBSD should change their default shipped sshd_config so it is set up like everybody else's.
(Score: 3, Interesting) by FatPhil on Monday July 27 2015, @11:34AM
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by CoolHand on Monday July 27 2015, @01:30PM
Anyone who is capable of getting themselves made President should on no account be allowed to do the job-Douglas Adams
(Score: 0) by Anonymous Coward on Tuesday July 28 2015, @11:48AM
sux
(Score: 2) by VLM on Monday July 27 2015, @12:18PM
You can also try ip filtering and port knocking.
Or rephrased its probably a good idea to use ssh as described in the article but its also a good idea to implement some ip filtering and maybe some port knocking.
(Score: 2) by doublerot13 on Monday July 27 2015, @12:52PM
For anything as important as SSH access, especially for an external-facing machine, passwords are just not good enough anymore.
Passphrase-protected key-based login is easy to implement and properly secure. For everything else there is client side certs.