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

Actual Threat?

[Anonymous Coward]

Already updated, but (w/o Kerberos) could this actually lead to anything more than the crashing of sshd and httpd child processes (assuming that's all one's using OpenSSL for)?

Re:Actual Threat?

[$0 31337]

Well I suppose that the answer is no considering that the CERT Advisory, OpenSSL site, Other numerous sites say "This can lead to a DoS attack" and don't mention anything else. RTFA.

Re:Actual Threat?

[Anonymous Coward]

Right. My point is, if the parent process lives on and can continue to spawn children for valid requests, is this DoS actually not much more destructive (with the possible exception of disk space for core files) than someone making "unneeded" connections?

Re:Actual Threat?

[$0 31337]

One of the problems is that a remote attacker could cause an infinite loop which would hang the parent process so yes, this could be a problem.

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

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.

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

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

Re:Non-Exploitable Security DOS Exploit

[Dwonis]

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

Windows Update consists of at least 4 click-then-wait-a-while cycles before your software is updated, and several packages must be installed separately (MSIE, service packs, DirectX, etc). On Debian, at least, you can run one command (apt-get update && apt-get -y upgrade) that will often complete the entire upgrade process, without reboots, etc.

Also, apt-get will upgrade third-party software. Windows Update does not.