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

[BlueCodeWarrior]

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

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

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.

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

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