Re: Alleged OpenSSH bug
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
Re: Alleged OpenSSH bug
There's one obvious thing I totally forgot to mention, but the initial spin put on this issue is *all wrong*. Calling that an OpenSSH bug is, pure and simple, slander. If anything, it is a PAM bug. Or you can say it's a system integration bug on FreeBSD. Calling that an OpenSSH bug just because OpenSSH does not take all the necessary paranoid measures required by an insane auth system is an over-simplification that goes in one specific direction. To throw mud in openssh direction. But yeah, it's SO SIMPLE to try to blame the openssh team (because you know, they're full of ubris) instead of putting the blame where the blame is. - treat passwords hashing as something mundane (FreeBSD). For sure it's not your task to make it hard to brute force password. - treat authentication as a maze (PAM). For sure, it's not your task to make things clear and simple so that configuration mistakes HAPPEN ALL THE TIME. - put all the blame on openssh, because you know, they're the only guys who have a clue about what's going on. - forget to mention this specific issue happens on ONE particular system due to ONE specific set of conditions. Do not EVERY try it everywhere. Publish first. Leaving it to the OpenBSD developers to reassert that this ONLY affects one *specific* deployment of OpenSSH. Here, I'll give you my root password. You can now exploit my machine.
Re: Alleged OpenSSH bug
On Thu, 23 Jul 2015 18:12:28 -0400 Garance A Drosehn wrote: to write software defensively if you want PAM to not fuck you over. It happens that I'm setting up some new (to me) RHEL 7 systems right now, and way too much time has been spent fighting with PAM (and I'm not done yet). So I'll energetically agree with everything Marc says here. Just a few days ago I was talking with one of other systems-programmers here at RPI saying how all of PAM should be ripped out and done over. We happened to be talking about a different failure scenario, but it (PAM) has always been a headache for me, almost every time I've dealt with it. Actually it is perfectly well engineered to bring in support revenues to RedHat. Forgive my cynicism but I wouldn't be surprised, I also wouldn't be surprised if banks probably changed the contactless cards design in the UK *after* the security audit and refused to fix it for over two years before apple paid news agencies to make a fuss upon release of apple pay because banks want large fraud numbers to give them somewhere to hide their own financial engineering and may have to invent some new fraud causing systems if forced to fix the blatant idiocy. p.s. The guidance is to use pubkey or long passwords in which case you should either have no problem or notice the cpu cycles if your an admin worth any salt.
Re: Alleged OpenSSH bug
Em 24-07-2015 14:27, Kevin Chadwick escreveu: The guidance is to use pubkey or long passwords in which case you should either have no problem or notice the cpu cycles if your an admin worth any salt. There are tons of info regarding OpenSSH best practices. The link bellow [1] is one of them. I personally let my servers with only the state of the art, which currently is ed25519 for both PubKeys and HostKeys, chacha for cipher, curve25519 for kex and hmac-etm for mac. [1] https://wiki.mozilla.org/Security/Guidelines/OpenSSH
Re: Alleged OpenSSH bug
Em 23-07-2015 18:10, Ted Unangst escreveu: Come on. Calling it an oversight is not condescending. I think it's perfectly reasonable to say it was an oversight. He did't say it was the hole of the century. There's no need to be so defensive. Yep. Others also told me this off list. I already sorted things out with the OP. But, truth is, that this bug is being sold by others, including news sites, as The BUG. It's hard to stay over the fence when things like this happen. Perhaps I need to drink less coffee and see what that thing called meditation is all about. Cheers, Giancarlo Razzolini
Re: Alleged OpenSSH bug
On 23 Jul 2015, at 17:38, Marc Espie wrote: 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. It happens that I'm setting up some new (to me) RHEL 7 systems right now, and way too much time has been spent fighting with PAM (and I'm not done yet). So I'll energetically agree with everything Marc says here. Just a few days ago I was talking with one of other systems-programmers here at RPI saying how all of PAM should be ripped out and done over. We happened to be talking about a different failure scenario, but it (PAM) has always been a headache for me, almost every time I've dealt with it. -- Garance Alistair Drosehn= dro...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA
Re: Alleged OpenSSH bug
On Thu, Jul 23, 2015 at 5:10 PM, Ted Unangst t...@tedunangst.com wrote: Come on. Calling it an oversight is not condescending. I think it's perfectly reasonable to say it was an oversight. He did't say it was the hole of the century. There's no need to be so defensive. Given that the last (and first) remote exploit against openssh *was* in the last century, IIRC, he could still be correct to call it the hole of the century... :) Heh. (apologies for the previous blank email :( )
Re: Alleged OpenSSH bug
Em 23-07-2015 16:43, Garance A Drosehn escreveu: As noted in my message, I did actually test it on a variety of systems. You mentioned FreeBSD boxes and a Mac. That ain't a variety of systems. I happened to avoid it on my systems, but that was more by luck than any cleverness on my part. This says a lot about you. The original post wondered if this was some mis-timed April Fool's joke. My reply was just to say that it's a real issue, although many people won't see this issue due to the way sshd is configured on their systems. You were condescending, admit it. Quoting you: I'm also told that there is a patch for the oversight in OpenSSH's code There was no oversight. There were people using the OpenSSH code in unintended ways. The OpenSSH portable is only provided by the OpenSSH project because there are developers that care for it. People should stop being lazy and use OpenSSH as close as upstream as possible and even better, with no portable glue code. You don't need PAM, specially if you're using PubKeyAuthentication. If you must use OpenSSH portable, at least bother enough to secure it. The patch wasn't provided because of a bug in OpenSSH code, it was provided because people are lazy, and wouldn't fix their own PAM configuration. Cheers, Giancarlo Razzolini
Re: Alleged OpenSSH bug
On Thu, Jul 23, 2015 at 5:10 PM, Ted Unangst t...@tedunangst.com wrote: Giancarlo Razzolini wrote: The original post wondered if this was some mis-timed April Fool's joke. My reply was just to say that it's a real issue, although many people won't see this issue due to the way sshd is configured on their systems. You were condescending, admit it. Quoting you: I'm also told that there is a patch for the oversight in OpenSSH's code There was no oversight. There were people using the OpenSSH code in unintended ways. The OpenSSH portable is only provided by the OpenSSH project because there are developers that care for it. People should Come on. Calling it an oversight is not condescending. I think it's perfectly reasonable to say it was an oversight. He did't say it was the hole of the century. There's no need to be so defensive.
Re: Alleged OpenSSH bug
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-authentication-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.
Re: Alleged OpenSSH bug
On 23 Jul 2015, at 13:33, Theo de Raadt wrote: 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. So try it on some other system without that setting. We'll wait. Then come come back and report whether your observations are identical or subtly different. As noted in my message, I did actually test it on a variety of systems. I can reproduce the problem on my Macs, because they are setup with 'ChallengeResponseAuthentication yes', and I do not turn it off. That has effectively the same authentication system as FreeBSD, same fast password check, etc. 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 It was an oversight, and on most systems it has limited impact, because repeated session connects can still be used by people to run the passwd check ciphers at full speed. It affects some operating systems to a much larger degree. Your statements sound like advocacy. No, it was not meant as advocacy. I'm just reporting what I found out from my own tests, and tests that others have done. And even by my own reports, the default FreeBSD config does exhibit this problem. I happened to avoid it on my systems, but that was more by luck than any cleverness on my part. The original post wondered if this was some mis-timed April Fool's joke. My reply was just to say that it's a real issue, although many people won't see this issue due to the way sshd is configured on their systems. -- Garance Alistair Drosehn= dro...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA
Re: Alleged OpenSSH bug
Giancarlo Razzolini wrote: The original post wondered if this was some mis-timed April Fool's joke. My reply was just to say that it's a real issue, although many people won't see this issue due to the way sshd is configured on their systems. You were condescending, admit it. Quoting you: I'm also told that there is a patch for the oversight in OpenSSH's code There was no oversight. There were people using the OpenSSH code in unintended ways. The OpenSSH portable is only provided by the OpenSSH project because there are developers that care for it. People should Come on. Calling it an oversight is not condescending. I think it's perfectly reasonable to say it was an oversight. He did't say it was the hole of the century. There's no need to be so defensive.
Re: Alleged OpenSSH bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/23/15 16: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-authentication-brute-force-vulnerability-maxauthtries-bypass/ I'll bite. In my *very* limited testing, using variations of the first ssh command in that blog post, none of my OpenBSD boxes with fairly pristine out of the box /etc/ssh/sshd_config permitted more than three tries before closing the connection. I also tested some Linux boxes (CentOS 6.something) with the same result. However, running that command pinting at a FreeBSD 10.1 box in my care gave more than three tries. I aborted well before reaching 1 for obvious reasons. I'm sure developers with more intimate knowledge of the code in question can fill in some gaps. - -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. iQIcBAEBAgAGBQJVsPcvAAoJELJiGF9h4Dye0PUP+gNAIEKaZuLxN3wtpGF2+cbk pgeU2ktuEXHHSm3Zo0OEoUGOQcyb01oAR4jtBn8ofHqy5pl1nkFz44bbttjfwKoQ tuCjtt4SKTe9rth1rfNQnUXKZeMCJfoUuupi+tShj61zlfq3xlYfa33wotx2FOy9 XKaX6Nq9k6pFsHJJeDuka/jsiFcMq4nxT6kgZACW4owolDuzIRhLbLRDwPOi+do6 JyBrOitPVBO52uhH1LFDQIYuut7oLMqA7FHvFOUVap2YsQfsqV1KqQrETrT8dwSE rzuV0ZKd8wO7DsvpJX3X4p1Ww3Y+XviGdBx30tbuG/99evhiWhH26zf4D05tzzJu TegsLgwcPvg1HjE8CjFnPx3XkYvRlD7oVWpG66QixdW2mW7dNKA2qnm/saaA9q3s zMtFk3e+I98iDR03lLzYaASFPKEwIw1o/nvr2WYq9RZtyzKSR2NT9yYsdbfdcHJu Vb3qtrsX1lZFfNQT8ojcREbK8s2w+Zptt/poWe8E+u43VtgtvcQUsML0KZQPCObk ZMJexU3+YSdIRKbpM5D2tvdgvhgHXGwt+HAJKhEt8clf/X1s+cv13ktU9iim/O3V brTXZWM/SAM49Hg/9i2p8zHQQft/bvDWlu6hyvrViMAjIDqhrUYd7m2gTzuAgQaL BKIu5nNh58RfIPeUDDax =Xum/ -END PGP SIGNATURE-
Re: Alleged OpenSSH bug
Em 23-07-2015 11:16, Peter N. M. Hansteen escreveu: In my *very* limited testing, using variations of the first ssh command in that blog post, none of my OpenBSD boxes with fairly pristine out of the box /etc/ssh/sshd_config permitted more than three tries before closing the connection. I also tested some Linux boxes (CentOS 6.something) with the same result. I have tested the command with various linux (CentOS 6, Ubuntu 12.04, 14.04, 15.04, Archlinux, plus some others) and OpenBSD (5.4, 5.5, 5.6 and 5.7) machines, and none of them were vulnerable. I don't have any FreeBSD machine available to test it. But it seems to be the only OS affected. I'm betting that they have some bad interaction between the openssh configuration and their PAM configuration. Cheers, Giancarlo Razzolini
Re: Alleged OpenSSH bug
It seems to affect only FreeBSD. But it's bad, and affect a lot of versions, dating back to 2007. And also, as I guessed, interaction with PAM is the culprit. That's why Dr. House doesn't allow exotic things to be ported to OpenBSD. You Can't Always Get What You Want. Seriously, dlopen of kerberos-grade software never hurt anyone (yet).
Re: Alleged OpenSSH bug
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-authentication-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 -- Garance Alistair Drosehn= dro...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA
Re: Alleged OpenSSH bug
Em 23-07-2015 13:29, Garance A Drosehn escreveu: 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. Yes, it seems so. Going through the source code and the openssh-unix-dev mail list, I see that it's indeed an issue that could affect a lot of machines. But it depends on the right (wrong) combination of factors which, unfortunately, FreeBSD has. Using the default ssh configuration you need to append the Konsole output -o NumberOfPasswordPrompts=1 option for being able to test this bug. My first attempts didn't had this. But I still can't replicate it on linux hosts. I can reproduce it on Mac's too. And it's as nasty as on FreeBSD. The problem is with the KbdInteractiveAuthentication option, which defaults to the same value of ChallengeResponseAuthentication which in turn has the yes default. If there are any forms of PAM authentication delays, they still apply. But that could perhaps be overcome with some kind of distributed attack, with many connections opened. Cheers, Giancarlo Razzolini Konsole output
Re: Alleged OpenSSH bug
It is a real issue. Your servers might not see the issue depending on what options have been set for sshd_config. Some operating systems have extremely fast passwd checks, others have slow ones. FreeBSD seems to be the worst affected because their PAM integration does not terminate the loop itself; it think it has no limit. Pay close attention and you will see you are replying to others who actually tested it on other systems. The issue is being overplayed by a fair bit. Yes, on some systems with careless authentication systems, many passwd checks can happen in one pre-auth session. However, even with this fixed, someone can do many, many sequential pre-auth sessions with less setup, and approach the same speeds. Only downside is they may be exposed by the extra logging. The issue comes to the fore *because* each passwd check is so cheap. In 1999, OpenBSD made moves to improve things, you may have heard of something called bcrypt... 16 years later, FreeBSD is now on their second successive generation of passwd crypt algorithm, having ignored the lessons. These layers fit together. One specific system had zero mitigations. 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. So try it on some other system without that setting. We'll wait. Then come come back and report whether your observations are identical or subtly different. This issue does not have the same scale of impact on all operating systems. One operating system is affected far more than the others. I can reproduce the problem on my Macs, because they are setup with 'ChallengeResponseAuthentication yes', and I do not turn it off. That has effectively the same authentication system as FreeBSD, same fast password check, etc. 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 It was an oversight, and on most systems it has limited impact, because repeated session connects can still be used by people to run the passwd check ciphers at full speed. It affects some operating systems to a much larger degree. Your statements sound like advocacy. I'll throw some back at you for fun. It seems too easy for FreeBSD folk to throw accusations at OpenSSH and the greater OpenBSD dev community, when the rich commercial sphere surrounding FreeBSD has never given a penny and gets all this for free. Why does FreeBSD PAM not have a counter in it to prevent this by itself? Why does it have super-fast passwd checks? Are those not oversights as well?
Re: Alleged OpenSSH bug
But it depends on the right (wrong) combination of factors which, unfortunately, FreeBSD has. Exactly.
Re: Alleged OpenSSH bug
On 7/23/2015 12:29 PM, Garance A Drosehn wrote: On 23 Jul 2015, at 10:06, Emilio Perea wrote: [snip] 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. [snip] When you set ChallengeResponseAuthentication to no, the pop-up Enter your Authentication Response that appears after you enter your password is suppressed.
Re: Alleged OpenSSH bug
On 23 July 2015 at 09:15, Giancarlo Razzolini grazzol...@gmail.com wrote: Em 23-07-2015 11:16, Peter N. M. Hansteen escreveu: However, running that command pinting at a FreeBSD 10.1 box in my care gave more than three tries. I aborted well before reaching 1 for obvious reasons. Digging some more, I've found this: http://seclists.org/oss-sec/2015/q3/156 It seems to affect only FreeBSD. But it's bad, and affect a lot of versions, dating back to 2007. And also, as I guessed, interaction with PAM is the culprit. And there's this: https://lists.freebsd.org/pipermail/freebsd-security/2015-July/008527.html Hopes to have it corrected before the next freebsd release. Cheers, Giancarlo Razzolini -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si
Re: Alleged OpenSSH bug
Em 23-07-2015 11:16, Peter N. M. Hansteen escreveu: However, running that command pinting at a FreeBSD 10.1 box in my care gave more than three tries. I aborted well before reaching 1 for obvious reasons. Digging some more, I've found this: http://seclists.org/oss-sec/2015/q3/156 It seems to affect only FreeBSD. But it's bad, and affect a lot of versions, dating back to 2007. And also, as I guessed, interaction with PAM is the culprit. Cheers, Giancarlo Razzolini
Re: Alleged OpenSSH bug
It seems to affect only FreeBSD. But it's bad, and affect a lot of versions, dating back to 2007. And also, as I guessed, interaction with PAM is the culprit. That's why Dr. House doesn't allow exotic things to be ported to OpenBSD. You Can't Always Get What You Want.
