The OpenSSH Bug That Wasn't 55
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.
Spoiler (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.
It may not be an OpenSSH bug ... (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
Re: (Score:2, 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?
Re: (Score:2)
That's because your parser's broken.
Re:It may not be an OpenSSH bug ... (Score:4)
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
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 [mozilla.org].
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 [marc.info]? 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.
Re:It may not be an OpenSSH bug ... (Score:5, Funny)
Luckily I just ordered a new pack of needles for my irony meter.
Re:Spoiler (Score:4, 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?
Re: (Score:1)
Different PAM settings, different /bin/login, different sshd_config settings, different defaults of SSH version versus versoin 2? Who knows?
Re: (Score:2)
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... [slashdot.org]
The redhat page: https: [redhat.com]
No it's a bug in OpenSSH (Score:4, 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.
Re: (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 deve
Re: (Score:2)
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.
Re: (Score:2)
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... [marc.info]
"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... [mindrot.org]
Re: (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.
Re: (Score:1)
Yay! The BSDs are still better than the Linux/SYSV variants (due to PAM being mainly used on Linux).
Re: (Score:1)
Both FreeBSD and NetBSD use PAM. Sadly, only OpenBSD uses the BSDAuth framework.
Re: (Score:2)
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 [openbsd.org]
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 king
Re: (Score:3)
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.
I love the attitude (Score:4, 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.
Re: (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 ag
Re: (Score:2)
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.
Re: (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.
Re: (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.
Re: (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.
Re: (Score:2)
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.
Re:I love the attitude (Score:4, 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.
However the attitude above is broken (Score:4, Insightful)
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.
Re: (Score:2)
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.
You didn't get far in reading (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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 th
Re: (Score:2)
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.
Re: (Score:2)
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?
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 shoul
Re: (Score:1)
found the guy who relies on root logins for hax
Re:I love the attitude (Score:4, 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.
Re:I love the attitude (Score:4, 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.
fixing the configuration is trivial (Score:5, Insightful)
> fixing the configuration is trivial
So trivial that the suggested configuration change is not mentioned anywhere.
Re: (Score:2)
> 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.
Re: (Score:2)
> 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.
Re: (Score:2)
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...
Re: (Score:2)
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).
Get your facts straight before reporting (Score:1)
I think that sentence right there is far beyond the scope of today's bloggers playing reporters.
ROFLMAO (Score:2)
To whom may I address this invoice for a new keyboard?