Multiple Vulnerabilities in OpenSSL

gfilion writes "Updated versions of OpenSSL are now available which correct two security issues: A null-pointer assignment during SSL handshake and an out-of-bounds read that affects Kerberos ciphersuites. Full advisory available on OpenSSL site and US-CERT."

Comments

3 actually

[chrisopherpace]

According to this link
Here
There are three vulnerabilities.
This was, like, sooo yesterday on the Bugtraq lists ;)

Re:3 actually

[Siva]

true, but one was in an older-than-current version. not to say it shouldn't be noted, of course...

Re:3 actually

[chrisopherpace]

Not to troll, but OpenSSL is not Linux, and Linux is not OpenSSL.

Re:before the trolls start...

[Trejkaz]

In particular, if you were running OpenSSH on Windows, which still depends on OpenSSL, then you are still in trouble. This isn't an OS security problem, it's a library security problem.

Re:Non-Exploitable Security DOS Exploit

[MobyTurbo]

Honestly people, is this really /. front page news? This came out on the FreeBSD mailing list 36 hrs ago, and a fixed version of OpenSSL is already available.

Slackware Linux also has this fixed. Incidentally, like the parent's subject line says, this is a minor vulnerability that at the most makes openssl crash, not an exploit or a trojan like all the stuff we've been seeing about Windows on /. lately.

Move along

[Dalcius]

Nothing really to see here folks. Both attacks crash the SSL server, so we're looking at DOS attacks and not 'holes'. This is certainly serious for the business who relies on it, but for home networks and casual use (which I'm sure is common among slashdotters) this is no sweat.

Nice to hear that they found the holes, though. :)

Re:Non-Exploitable Security DOS Exploit

[Anonymous Coward]

How do you set up your supfile?

Copy it from /usr/share/examples/ (it's somewhere in there, I think, my FreeBSD box isn't running at the moment, I've poached some of its hardware).

Over a period of several updates, how do you avoid having stale libraries/executables/config files scattered all over your machine?

That's a fine question indeed. What I do is:

make DESTDIR=/usr/local/fake_root distrib-dirs distribution

make DESTDIR=/usr/local/fake_root installworld

make DESTDIR=/usr/local/fake_root installkernel KERNCONF=foobar

Then you can compare the contents of /usr/local/fake_root and stuff in /. I like find and sort and vimdiff to do that. It's not super elegant, but you don't have to do it too often if you're tracking something like RELENG_4_9, since rarely do things get updated. What you would use it for is when you make changes to the base, which leads me to:

Is there a risk that 'make installworld' will silently overwrite a functional replacement previously installed from ports?

Yes! But you can get around it. In /etc/make.conf, do:

NO_SENDMAIL=true

Now sendmail won't be built, although its stale files will hang around; refer to point 2 above.

You'll also, in rc.conf, want:

sendmail_enable="YES"

sendmail_flags="-bd"

sendmail_outbound_enable="NO"

sendmail_submit_enable="NO"

sendmail_msp_queue_enable="NO"

At least for Postfix, which you say you use.

Not too big of an issue...

[InvaderXimian]

Considering most setups (namely FreeBSD ones) aren't affected because this is a problem with Kerberos ciphersuites and the OpenSSL code is extremely MIT Kerberos specific so this flaw doesn't affect it.

From the FreeBSD security list:

If one compiles OpenSSL oneself, *and* has MIT Kerberos, *and*
> enables the Kerberos options, *and* has all ciphersuites (or at least
> the Kerberos ciphersuites) specified in your application's
> configuration, then you might be affected. But that has nothing to
> do with FreeBSD.
> Thus, answering your question again:
>
> Isn't FreeBSD vulnerable to the second "Out-of-bounds read affects
> Kerberos ciphersuites" security problem?
>
> No, FreeBSD is not.

Re:Non-Exploitable Security DOS Exploit

[NightSpots]

Never used RHN, have you?

First thing it does is `rpm -qa` and sends that list right to RedHat.

It's really hard to know what updates to provide without seeing a list of software packages installed. Sure, they could differentiate between "Our" software and "Other" software in the list of installed programs, but that's just silly - send the whole list, and ignore the stuff you don't care about.

Redhat?

[Jesus IS the Devil]

If you have RedHat and can't do the up2date any longer, here's what I did to make mine work:

wget http://www.openssl.org/source/openssl-0.9.7d.tar.g z
tar xvfz openssl-0.9.7d.tar.gz
cd openssl-0.9.7d ./config shared --prefix=/usr
make
make test
make install

Configure with "shared" because it will install the shared library, which is needed for other programs such as SSHD. The prefix is where RedHat put its *.so files that's needed by OpenSSH.

Not sure if it's required or not, but I just restarted SSHD (uses OpenSSL) after that just in case.

Btw, the above is just what I did. I make no warranties. Follow it at your own risk. :)