Slashdot Mirror

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...

"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...

What piece of code would the Open SSH project possibly want from any developer?

It's not like it's defect-free software that requires no more development.
https://bugzilla.mindrot.org/s...

Should Google fire the OpenSSH developers they employ (Like this guy)? Should they stop donating to OpenBSD as shown here?

Given that the problem addressed by RequiredAuthentications2 is still being worked on by the Portable OpenSSH team (using a completely different configuration directive), it appears that RequiredAuthentications2 probably shouldn't have shown up in RedHat at all. A lesser version of how Debian managed to bork OpenSSL by touching things they didn't understand.

Non-Open-SSH has been able to require multiple authentication stages for some time now. Every now and then someone updates a patch for OpenSSH to do the same.

Yes. The bottleneck for ssh probably becomes the HMAC - this thread is enlightening. SHA HMAC is afaict considered difficult to accelerate with Via's implementation, though a patch may exist. With a stock (AES-accelerated) build, software MD5 is quicker.

Your answer is probably "Not Yet". The "original" non-OpenSSH has had a configuration option for this for years, Portable OpenSSH (the one you're probably using unless you're on OpenBSD) has a bug from 2005 that is still drawing patches (last patch from Jan. 2010)

I'd like to thank the OpenBSD project, as well, but I'd also like to point out a few issues.

OpenSSH still won't work with certificates signed by a CA.

Quite right, and we have no intention of incorporating x.509 support. X.509 parsing and verification exposes a large amount of attack surface and all of it is, by necessity, pre-authentication too (the type which, if buggy, allows worms). Read Peter Gurmann's X.509 style guide and see if you ever want to go near this horror again. We have actually written our own minimal RSA verification code to avoid the sort of ASN.1 parsing that is necessary to deal with X.509, and it has saved us from at least seven bugs - some probably exploitable for authentication bypass or remote code execution.

OpenSSH doesn't allow an unencrypted connection (after authentication). Not all CPUs can encrypt/decrypt at 1Gbps.

Yep, we are a _secure_ shell and we take a mildly patriarchal attitude to adding options that can lead to insecure use of OpenSSH. Note that the actual bottleneck in most cases is not the crypto anyway (at least when using arcfour256 as your cipher) but the MAC, and you wouldn't want to switch that off. We do have a very fast MAC though: umac-64

OpenSSH doesn't work - as advertised - with an exclamation point in a "Match" statement.

File a bug, we'll fix it.

Other than that, OpenSSH is possibly one of the most capable and reliable pieces of software I've ever had the privilege to use.

Thanks :)

"OpenSSH now has a blacklist feature for weak Debian-generated ssh keys." From: http://www.dragonflybsd.org/community/release2_0.shtml Please do just a LITTLE bit of research before posting.

Please do some research before telling someone else to do research before posting.

DragonflyBSD is a fork of FreeBSD and not exactly mainstream so you can hardly accuse me of not being aware of what it said. Further, apart from that remark on the page you linked-to claiming that "OpenSSH contains a blacklist feature", there's nothing to suggest that OpenSSH itself actually contains any such blacklist management.

My research: There's nothing in the OpenSSH ChangeLog at ftp://ftp.plig.org/pub/OpenBSD/OpenSSH/portable/ChangeLog which mentions blacklisting and there's nothing in the source tarball either. I've looked (both the core distribution and the portable version).

It may be that DragonflyBSD includes blacklist management, but if so, they didn't get it from OpenSSH.

I raised the bug https://bugzilla.mindrot.org/show_bug.cgi?id=1469 because I thought that such a feature should be included. If the OpenSSH developers were interested in supporting this, I'm sure they'd have (a) commented on the bug and (b) written the code or used some of the contributed code. They may well have good reasons for not including this, but they haven't commented either way.

Even the openssh guys don't seem interested in including blacklist support for probably-compromised keys: see https://bugzilla.mindrot.org/show_bug.cgi?id=1469

This means that, since the compromise arose, Debian and Ubuntu distros are safe once patched with the blacklist code. However, for keys generated on Debian/Ubuntu but uploaded to non-Debian/Ubuntu servers, those non-Debian/Ubuntu servers will still be vulnerable unless manually checked. This means: OpenBSD servers, Fedora servers etc.

Have any distros apart from Debian/Ubuntu provided blacklist-like tools for this issue? Any of the *BSDs?

flashboot fits an OpenBSD system that includes wireless, IPsec, firewalling, bgpd, ospfd, ntpd, ssh and a bunch of standard Unix utilities into a 5Mb ramdisk kernel without trying. If you are embedding then you could reduce this easily (you wouldn't need most of the extra commandline utils or all of the half-dozen wireless drivers for a start). uclibc is only required for Linux because glibc is so horribly bloated.

He's probably talking about the typical default Red Hat server setup, which most of these server farm places rent as a Linux server. A lot of people just rent these and use them as is.

Researching a little on the lists it seems like there are a lot of good suggestions such as "exponential backoff" and keeping track of misbehaving IP addresses but no action on the part of developers for a year or more, and no good reasons given to not put them into use (except what seems like lazyness because it looks like more work).

And it looks like the new sshd_config's "MaxStartups" and other like directives won't help with the brute force issue either.

The strange twist is that if you delay a login for a particular user then an attacker could almost lock out that valid user by keeping his retry delay high. So basing it on the users ID is a bad idea, it looks like tracking abusive IPs is a good way to do it, and it should work even with multible connections, so it has to be multi thread compatible which is more complicated work and that's probably why the developers are so against any changes.

Mailing lists for OpenSSH:
http://www.mindrot.org/mailman/listinfo/openssh-un ix-dev
openssh-unix-dev@mindrot.org
http://msgs.securepoint.com/cgi-bin/get/openssh-un ix-dev-previous.html

Well, if you want it fixed then please open a bug at http://bugzilla.mindrot.org, and better yet, attach your patch.

As for submitting a patch: patches took 4 years to be accepted, and then 6 months for a release after that. What makes you think I have the time to deal with that?

Does ./configure handle cross-compile situations correctly yet?

Actually it is possible, there is a magic bit in the CMOS that tells the BIOS to skip the checks. I'm happily running a Netgate Prism 2 card in my X40, after running this program (also available in OpenBSD ports/misc/tpwireless).

There is also this for OpenBSD. It is intended for flash booting, but with PXE it can be used to boot diskless systems too.

And another and yet another. (yes, this is self-promotion)

And another and yet another. (yes, this is self-promotion)

Security Changes:
=================

All versions of OpenSSH's sshd prior to 3.7.1 contain buffer
management errors. It is uncertain whether these errors are
potentially exploitable, however, we prefer to see bugs
fixed proactively.

OpenSSH 3.7 fixed one of these bugs.

OpenSSH 3.7.1 fixes more similar bugs.

Time to patch & upgrade for the second time today?

Security Changes:
=================

All versions of OpenSSH's sshd prior to 3.7.1 contain buffer
management errors. It is uncertain whether these errors are
potentially exploitable, however, we prefer to see bugs
fixed proactively.

OpenSSH 3.7 fixed one of these bugs.

OpenSSH 3.7.1 fixes more similar bugs.

But have they fixed this bug??

This is a showstopper for me. Turning compression off does not solve the problem for me. I ended up using some patch off the mailing list temporarily.

Audio Entropyd is a small program that I wrote to read data from a soundcard, hash it and feed the result to the Linux kernel's random number pool. Since this audio contains at least small amounts of noise, this may be a cheap source of entropy. audio-entropyd takes the difference between stereo channels in an attempt to eliminate hum.

You should try emailing the developers at openssh-unix-dev@mindrot.org. We can only fix problems that we know about.

This is a small program to reseed the Linux kernel random number generator with data from soundcard.

Audio is ready periodically from a stereo soundcard, the difference is taken between the left and right channels, the difference is hashed and credited to the KRNG.

Using the difference between the left and the right channels should eliminate some external signals (e.g. 50/60hz power cycle).
--------
"I already have all the latest software."