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

[Anonymous Coward]

Let me summarize this whole thread so we don't waste anytime:

Microsoft fans - "see, Linux/FOSS have security issues too"

Linux fans - "yeah, but we fixed this right away. If this was Microsoft, we would have been waiting for months"

Repeat again and again..

Netx topic please..

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:3 actually

[smittyoneeach]

You're flying too low to see the us/them dichotomy going on, boss.

Re:3 actually

[fermion]

Anyway we all know the problem isn't MS, the problem is C. It is such a 1970 type of language. Back when programmers were randomly jumping from place to place, casting memory as whatever type of data pleased them, recasting the data in function calls, copying blocks of data without a care of whether the blocks really existed, and, in this case, assigning NULL pointers all willy nilly. I mean really. No programmer educated in the past 15 years actually has the skill to remember that the void pointer pointer which in the last call has the value of the beginning of a three dimensional array, now points to the beginning of four dimensional array, which, of course, is complicated by the fact that such beasts only exist in the mind of the programmer, and not in any specific language construct, pointer math being one of those fictional things beat into the heads of the unfortunate programmers trained 20 years ago. And let's not even talk about the infinite loop idiom.

Anyway, we need to rewrite the entire thing in the elegant languages of the 21st century. I suggest this

Let's be like M$...

[barfarf]

I think we should be like Microsoft and not tell anyone about it until it's already patched.

... oh, wait....

Re:Let's be like M$...

[Trejkaz]

But remember, according to Microsoft the exploits can't exist until after the patch is released anyway.

Re:Let's be like M$...

[thedillybar]

They didn't tell anyone until a patch was available. Note that the vulnerability was announced Wednesday, and it included a link for the patch (openssl-0.9.7d) when it was released.

It's fairly reasonable to assume that the developers knew of the vulnerability some time before the new version became available.

I think it's good practice to do this if you can develop the new version fast enough. Announcing it early is only inviting someone to exploit it. I doubt anyone will fix the vulnerability themselves and put it into production before the official release comes out.

before the trolls start...

[contrasutra]

Please don't comment "so I guess Windows isn't so insecure, is it...". We always seem to get a few of these. OpenSSL/OpenBSD has a VERY good security track record. Is a vulnerability a problem? Yes, but when MS has OpenBSD's track record, you can compare.

Also I think this is a good news post simply because it helps to show we're not Anti-windows bias. We report security problems on ALL os's.

Oh well, sometimes you just have to combat the trolls.

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

[doomy]

Yes, but when MS has OpenBSD's track record, you can compare.

This just out from MSFT:

Only one remote hole in Windows XP, since yesterday.

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

[BlueCodeWarrior]

For those of us not on the FreeBSD mailing list, it is.

Bullshit...

[Anonymous Coward]

Everything is fine, firewall is quiet, and I dont think a single box wiL#%*#AT+H+H[NO CARRIER]

Re:Patch updates are NOT news

[pompousjerk]

I'm betting that there are a large number of sysadmins who pay more attention to /. than they do to keeping systems up to date.

Re:Non-Exploitable Security DOS Exploit

[stratjakt]

It's certainly front page news if there's a non-exploitable flaw in Windows for which a patch has been released.

cvs, make and build sure.. But when it's click windows update, somehow it's some monumental task thats just the worst thing imaginable.

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

[KidSock]

...is this really /. front page news? This came out on the FreeBSD mailing list 36 hrs ago.

Yes. Most of us are not on the FreeBSD mailing list. Instead we wait for the more mainstream outlets like ./ to report the problem. Also it's good to wait about 36 hours or so for the fix to go through the motions as the sudden intrest rattles free other problems.

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:Why Is This Happening?

[nathanhart]

Probally has something to do with many people being able to do code audits freely and of course submit their fix for it ;)

Re:Non-Exploitable Security DOS Exploit

[ewhac]

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

Schwab

For the love of god

[Anonymous Coward]

Please let the 'no proble...[NO CARRIER]' joke die. It is less funny than recursive acronyms, number representation wackiness, or 'yet another' names for programs.

Okay, maybe not less funny - but just as unfunny.

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

[Sivar]

You have a good point, as using Windows Update is easier (or at least as easy) as any GNU/Linux update method, and can be made automatic very easily (like some GNU/Linux update methods).
One noteworthy difference, however, is that none of the BSD or GNU/Linux update methods tell the vendor the software (and their versions) that you run. To their credit, at least, none of them (including Microsoft) collect any actual personally identifiable information.

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.

Yawn

[ChiralSoftware]

I'm bored of these OpenSSL advisories. On and on they go. An unchecked null and an out-of-bounds read. Someday, people will realize that unsafe data (anything that comes in over the net) really can't be safely manipulated in a language like C. If OpenSSL had been implemented in Java, there types of errors couldn't exist, or if they did exist, they would throw exceptions which could be caught and handled in some reasonable way.

Rule #1: Unsafe data should be handled in sandboxed languages.

Rule #2: Programs that are exposed to unsafe data (server processes) should run at some minimum and constrained privilege level, not as root. The "must be root to bind to ports less than 1024" rule on Unix is almost exactly the opposite of what the rule should be.

I'm sure many people who don't understand these issues will flame me or say I am trolling, but oh well, someone needs to keep bringing this up until it sinks in.

------------
Create a WAP server

Re:Yawn

[ChiralSoftware]

No, I'm not trolling. I can summarize your whole post in one sentence: "Don't make mistakes and everything will be fine!" We've been hearing that for years. The best C security coders in the world are the OpenBSD team and guess what, they make mistakes. They fail to validate input sometimes. They have had exploitable bugs in their code. And what are they doing now? They are moving to models like privsep, w^x and systrace which are all forms of sandboxing or hole containment. Eventually if they take that far enough, they'll end up running bufferless code in a VM, which would give me a sense of deja vu.

Sure, it's entirely possible to write perfect C code with no mistakes, and it's possible to not validate input on Java code and make plenty of mistakes. You gave a great example: SQL injection attacks. Java has some great defenses against that: Use java.sql.PreparedStatement instead of java.sql.Statement. Even better, use something like JDO to give an abstracted OO view of the data.

Here's where C breaks down: The human mind doesn't think in the right way to use C safely. We can't change the human mind (yet), but we can change which language we use. Humans just don't spot out-of-range errors, for example, but out-of -range errors are all trapped in Java and also because Java collections know their size (unlike C arrays/pointers) out-of-range errors are much more obvious.

Also, saying that "if you validate your input you can run it at any priv level you want" is just the wrong way to think about this. Mistakes will happen in any sufficiently large system (ie, any system that is large enough to be useful today). The only reasonable thing to do is to contain those mistakes, which means isolate processes and functions.

Or you can keep on repeating "nothing bad would ever happen if we didn't make any mistakes!" I guess if that's what you think, I can't change your mind.

Re:Yawn

[thogard]

Its a one line patch to get linux (2.2 and maybe 2.4 and maybe 2.6) to only let you open ports that equal a group your in. Its a simple fix but no one wants to do it. Even the standard /etc/groups aren't set up for this. Whatever listens to SMPT should be in group 25 and apache should be in groups 80 and 443. Then you don't need root to bind to the port and no other user can bind to the port either.

advice on cvsup

[puzzled]

There is a minimal cvsup config for FreeBSD 4.9 - cvsup -g -L 2 and you're off and running.

*default host=cvsup6.FreeBSD.org
*default base=/usr
*default prefix=/usr
# The following line is for 4-stable. If you want 3-stable or 2.2-stable,
# change "RELENG_4" to "RELENG_3" or "RELENG_2_2" respectively.
*default release=cvs tag=RELENG_4
*default delete use-rel-suffix
# If your network link is a T1 or faster, comment out the following line.
*default compress
src-all
#ports-all tag=.

make buildworld & make installworld install *world*, which does not include anything you built out of /usr/ports - portupgrade is what handles moving that stuff forward for you.

FreeBSD *is* intimidating at first, but if you take the thirty days of pain at the end of that time you'll be looking at your Linux boxes and wondering why you ever put up with the chaos ...

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

Scary AND funny!

[veddermatic]

When an OSS / Linux / BSD / OS X / something other than Windows flaw is found, it's serious.

It really is. You need to take it seriously and fix it. ASAP. Hopefully, most folks who run said OSes are paying attention, and will do what they need to do to secure the flaw.

That said, every time anyone uses Outlook to read email, the above looks really, really good.

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:Non-Exploitable Security DOS Exploit

[gad_zuki!]

>Honestly people, is this really /. front page news?

Yes, lets just wait till some kiddie write a worm that crashes thousands servers all over the world and then post about it.

I like that slashdot posts security problems. Why?

1. For the lazy admin. Theres lot of them.

2. because its important to keep reinforcing the idea that computers suck (I dont care what OS you like) and need constant care.

You need to monitor security lists

[donheff]

I see a fair number of posts from people who rely on /. to learn about security flaws. That doesn't seem to be a sensible approach. It is pretty easy to follow a security list and keep an eye out for vulnerabilities affecting your system(s). I am a home user with a simple Web server in the basement. I subscribe to the CERT list. Others here mentioned Bugtraq. I catch quite a few alerts that I don't hear about in more general forums until after I see activity in my Snort logs. Even with a nightly update via yum some things need individual attention. Case in point, a flaw in a PHP application (Gallery) that falls outside of the packages covered by yum. You have to know about it to fix it -- and the bad guys know about immediately.

Don

C language is (also) to blame.

[master_p]

A null-pointer assignment

an out-of-bounds read

Aside from the programmer's errors, if C was safer, both bugs would have already been caught a long time ago. C is clearly to blame here.

OpenSSL in Java would be too slow

[nestler]

An OpenSSL written in Java would be a complete non-starter. Nobody would use it because it would be too slow.

For most applications, you are right that safety outweighs performance concerns. However, OpenSSL is in that 1% of applications where performance outweighs everything. It is a crypto library. Crypto is extremely CPU intensive.

OpenSSL is expected to run as fast as possible, to the point where parts of it aren't even written in C. The core bignum and hashing routines are written in assembly language for various platforms.

You even mentioned this caveat:
if you're not writing an OS, a game, or a calculation based app (lapack, etc...)

But you didn't seem to realize that this caveat certainly applies to OpenSSL (if ever there were a calculation based app, this is it).