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

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

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