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:before the trolls start...

[thebatlab]

Not that I entirely agree with him (and not that I don't ;)) but his math is just fine . 100% are biased in some direction, 50% don't admit it. Works by my account.

Re:Non-Exploitable Security DOS Exploit

[Electrum]

For people who've never done this before (such as myself), this is an intimidating operation; care to walk me through it?

First, RTFM:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/h andbook/cutting-edge.html
http://www.freebsd.org/doc/en_US.ISO8859-1/books/h andbook/makeworld.html

I run 4-STABLE on all of my boxes, so this will be a bit different for 5. Create /etc/make.conf. You can look at /etc/defaults/make.conf and in the handbook for more details:

CFLAGS=-O -pipe
NOPROFILE=true
NO_BIND=true
NO_SENDMAIL=t rue

SUPHOST=cvsupXX.freebsd.org
SUP_UPDATE=yes
SUP =/usr/local/bin/cvsup
SUPFLAGS=-g -L2
SUPFILE=/usr/share/examples/cvsup/stable-supf ile
PORTSSUPFILE=/usr/share/examples/cvsup/ports- supfi le

Replace SUPHOST with your CVSup mirror. See the handbook for more info. The NO_BIND and NO_SENDMAIL lines keep buildworld from building BIND and Sendmail, respectively, since I use djbdns and qmail.

Once you have setup /etc/make.conf, you can update the source tree by doing this:

# cd /usr/src
# make update

That will also update /usr/ports. If you want to just update ports, run make update from /usr/ports.

Once your source tree is up to date, update the system following section 21.4.1 in the handbook. I skip the single user mode part, since I do everything over SSH:

# mergemaster -p
# rm -rf /usr/obj/*
# make -j4 buildworld
# make -j4 buildkernel
# make installkernel
# make installworld
# mergemaster -i
# reboot

The order there is important. The kernel should be built after the world is built, since building the world updates the build tools (this is especially important when it has been a long time since you last updated). The kernel should also be installed before the world is installed.

You should almost always update the kernel when you update the world. If you choose not to reboot immediately after installing the new world, you might notice that tools like ps no longer work, since they don't match the kernel.

These is how I do things after several years of experience. Make sure to read and understand the handbook before doing anything. But really, it's not that hard, especially after you do it a few times.

An unrelated but very useful tip: check out the sysutils/portupgrade port.

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.

Re:Non-Exploitable Security DOS Exploit

[cperciva]

CVSup; make buildworld && make installworld

For people who've never done this before (such as myself), this is an intimidating operation; care to walk me through it?

If you're intimidated by buildworld, there's an easier option:
# freebsd-update fetch
# freebsd-update install

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