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

Non-Exploitable Security DOS Exploit

[jstockdale]

News at 11

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.

CVSup; make buildworld && make installworld

Problem solved.

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.

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.

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

[Anonymous Coward]

For people who've never done this before (such as myself), this is an intimidating operation; care to walk me through it? It also glosses over insignificant little details, such as:
How do you set up your supfile?
Over a period of several updates, how do you avoid having stale libraries/executables/config files scattered all over your machine?
Is there a risk that 'make installworld' will silently overwrite a functional replacement previously installed from ports? (E.g. I'm using postfix, thankyouverymuch, and don't want sendmail to reappear.)

Dumb questions I'm sure, but the answers have never been revealed in a form I can understand.

These are not dumb questions but they should be addressed to freebsd-questions mailing list where you will get good answers.

The FreeBSD Handbook contains all the information that you need, but if you are still unsure please ask questions.

Another good place to check is the freebsd mailing list archives. It is a gold mine of information for about every problem imaginable. Chances are, if you have a question, its been asked and answered before!

Good Luck!

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

Re:Non-Exploitable Security DOS Exploit

[UberLord]

It's really hard to know what updates to provide without seeing a list of software packages installed

That's the nice thing about Gentoo. I recieve the full software tree everything I emerge sync so only *I* know what I have installed.

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.

They are if you just got hacked...

[jarich]

I have a friend who left his ssh server up overnight on a brand new mandrake box... (I know, he shouldn't have, but he did).

Next morning, box his linux and windows box had been compromised.

Slashdot is a great forum for this type of critical patch. Gets the news out very quickly to people who dont read the security sites everyday.

Re:They are if you just got hacked...

[jarich]

Leaving up a service you don't need is not a smart thing to do. My friend didn't need SSH up anymore (he had temporarily) but he thought there was no reason to take it down, so he left the port open on his router.

Next morning, things were hosed. :(

The moral is if you need SSH, FTP or any other service up, keep one eye BugTraq... but slashdot posts a lot of the good ones for those of us who don't have time to read everything.

But, if you don't have a need for the service, shut down the port! NEVER leave up a port you don't need up. There are tons of script kiddies out there just trolling for an opening. If you don't belive me, just turn on the logging for your router and watch the probes go rolling by.

Re:They are if you just got hacked...

[Anonymous Coward]

This vulnerability isn't an exploitable hole, just a DOS, shit-for-brains. Has nothing to do with the security holes in OpenSSH.

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

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.

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

Re:Redhat?

[QuMa]

Or you could just download the RPM's listed in the RHSA and install those.

Re:No, but...

[thogard]

If you need the program to run, its init's job to keep it running and init does a fine job doing exactly that.

I guess you start your critical ssl apps out of the rc scripts don't you?

A well built server can take a # kill -9 -1 and still keep on going. (thats kill -SIGKILL every process)

Re:Yawn

[iwadasn]

I completely agree. The port binding should still be specific, but not root. For instance, every unix system should have a "network" user that is the only one that can bind to ports less than 1024, root cannot, nor can anyone else. That nicely sandboxes all the attack vectors into one user that can be easily controlled and chrooted.

But of course none of this would be necessary if everything possible was written in java. Then you wouldn't really have to worry because worst case scenario, you get an exception...

In addition, I'm going to go off on a tangent here about java performance testing. Basically whenever people compare performance they compile up a C version using the latest compiler, targeting their CPU specifically, and they compile up a java version and run them head to head. This is about the most unfair comparison you can make. In general, software is almost always older than hardware, and it's virtually never targeted for the CPU you're actually running it on. Try compiling the C source on a three year old compiler targeting a pentium II, then run the benchmark on the P4 and lets see how it turns out. That is the common case after all. One of java's largest advantages is that it knows everything about your hardware, so theoretically it should always be fairly well optimized for it. The comparative performance would be much closer (it's usually pretty close anyway) if things were tested in this real world scenario.