Multiple Vulnerabilities in OpenSSL 274
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."
Non-Exploitable Security DOS Exploit (Score:2, Informative)
Honestly people, is this really
CVSup; make buildworld && make installworld
Problem solved.
3 actually (Score:5, Informative)
Here [uniras.gov.uk]
There are three vulnerabilities.
This was, like, sooo yesterday on the Bugtraq lists
Re:3 actually (Score:5, Informative)
Re:before the trolls start... (Score:5, Informative)
They are if you just got hacked... (Score:2, Informative)
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:3 actually (Score:4, Informative)
Re:Non-Exploitable Security DOS Exploit (Score:5, Informative)
Slackware Linux [slackware.com] 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 (Score:5, Informative)
Nice to hear that they found the holes, though.
Re:Non-Exploitable Security DOS Exploit (Score:5, Informative)
Copy it from
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
/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:
/etc/make.conf, do:
Then you can compare the contents of
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
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:They are if you just got hacked... (Score:3, Informative)
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... (Score:1, Informative)
Not too big of an issue... (Score:5, Informative)
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... (Score:4, Informative)
Re:Non-Exploitable Security DOS Exploit (Score:4, Informative)
First, RTFM:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/
http://www.freebsd.org/doc/en_US.ISO8859-1/books/
I run 4-STABLE on all of my boxes, so this will be a bit different for 5. Create
CFLAGS=-O -pipe
NOPROFILE=true
NO_BIND=true
NO_SENDMAIL=
SUPHOST=cvsupXX.freebsd.org
SUP_UPDATE=yes
SU
SUPFLAGS=-g -L2
SUPFILE=/usr/share/examples/cvsup/stable-sup
PORTSSUPFILE=/usr/share/examples/cvsup/ports
Replace SUPHOST with your CVSup mirror. See the handbook [freebsd.org] 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
# cd
# make update
That will also update
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
# 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 (Score:1, Informative)
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 (Score:5, Informative)
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 (Score:4, Informative)
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? (Score:5, Informative)
wget http://www.openssl.org/source/openssl-0.9.7d.tar.
tar xvfz openssl-0.9.7d.tar.gz
cd openssl-0.9.7d
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:No, but... (Score:3, Informative)
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:Non-Exploitable Security DOS Exploit (Score:3, Informative)
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.
Re:Redhat? (Score:3, Informative)
Re:Yawn (Score:2, Informative)
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.