OpenSSL Security Vulnerability

SiliconEntity writes "On the heels of multiple OpenSSH vulnerabilities, the OpenSSL project is now reporting a number of security vulnerabilities of its own. OpenSSL is a standard cryptographic library used in a wide variety of security applications. The new vulnerabilities range from denial-of-service attacks to stack corruption, which imply the possibility of running malicious code. New versions of the software are released today which address the vulnerabilities."

Comments

Re:Got the popcorn

[Skyshadow]

Looks like there were "a number" of vulnerabilities. Perhaps they should have waited?

Waited for what, perfection?

In a Real World environment, "pretty safe" is a whole hell of a lot better than nothing. So long as flaws are fixed quickly after being identified, I don't see what the problem is.

If you want *real* security, you need an air gap. Otherwise, quit yer bitchin'.

Open Source Code Quality

[Anonymous Coward]

I think this firmly refutes the argument that Open Source software is inherently more stable.

There are still potential overflow bugs in the OpenSSH buffer library. The great thing about Linux malloc() realloc() is that even when there is no memory, it returns a non-Null pointer anyway.

A ring buffer would have been a better design choice.

Re:Open Source Code Quality

[statusbar]

The man page is lying. Make a test program. It is entirely possible for two or more programs to allocate more memory than phys+swap together. malloc() and realloc() on linux NEVER return 0, unless one single allocation in one program exceeds swap.

Linux allocates physical memory pages on the fly, as you use them. Try this code. It allocates 256 megs on each run until you exit. How many times do you have to run it before it says malloc returns 0? How much more memory than you have (including swap) did it allocate?

#include <stdio.h>
#include <unistd.h>

int main()
{
char *p = (char *)malloc(256*1024*1024);
printf( "malloc returned 0x%X\n", (unsigned long)p );
getchar();
}

This kind of thing happens with stacks as well. Memory on your stack is allocated on the fly as you use it. What happens when the kernel can't allocate a memory page when it is first accessed? It kills the process. hard. This means that user processes can steal resources and cause any number of root processes to die, just because they made a function call that required a larger stack.

This does have many security and dependability implications, as the original poster said. Most people do not know this and do not handle this case!

--jeff++

Re:Feeling kinda good about it

[Overly Critical Guy]

At least we find out when where vulnerable BEFORE the exploits start rolling out.

As opposed to what? The months before Blaster came out that the patch was available?

Things like this just illustrate that all software has bugs. OSS is not a magic solution, and Microsoft does not hire poor programmers. That won't stop rampant anti-"M$" trolls of course, but the more rational of us can look at this and move on.

Why is some software more secure than others?

[cras]

I got annoyed at the slashdot comments last time there was security hole in OpenSSH and wrote this page (copy pasted below). I count OpenSSL as insecure software - we need a secure replacement. GNUTLS looks somewhat better, but I don't trust it too much either.

Why is some software more secure than others?

How do you measure software security?

Here's my definition on what is secure software.

Intro

I get really tired of seeing these kinds of comments every time some widely used software has security holes:

• No software is secure. The difference is how quickly they fix it.
• It's good that they were found. Now we have less security holes.
• Popular software gets more security audits which is why they seem to have more security holes.

While they may be partially true, I think they're also very misleading and disparages the hard work that some secure software authors have done.

Simplicity Is Security

The difference between secure and insecure software is really the coding techniques being used by it's authors. Authors of secure software do everything they can to prevent accidental mistakes from ever happening. Authors of insecure software just fixes the accidental mistakes. There are very few secure software authors.

Auditing insecure software doesn't make it secure. Sendmail is a good example of this. It's been audited countless times by competent people. The simplest mistakes were catched easily long time ago, but a few very difficult to find vulnerabilities were found only recently.

How do secure software authors then avoid the kind of security holes that are difficult to find? By keeping the code simple. The code doesn't get secure by polluting it with tons of security checks. It gets secure by keeping the security checks in as few places as possible.

Auditing secure software is easy. You can just quickly browse through most of the sources without having to stop and look at it carefully. Everything just looks clean, simple and correct. vsftpd is a good example of this.

Sure, it's still possible that secure software has some security holes occationally. It just happens a lot less often (if ever) and usually the problems are less critical. For example none of the security holes in Postfix have lead to arbitrary code execution or being able to read other peoples mails. Denial of Service attacks are nothing compared to them.

(some examples in the web page not included)

Re:Why is some software more secure than others?

[GSloop]

'No software is secure. The difference is how quickly they fix it."

Perhaps no software is absolutly secure, and without bugs, but we're not anywhere close yet.

Software needs to be designed (engineered is a better word) to be secure, modular and ONLY as functional as needed.

I think in general, OSS and Linux do this better than Windows does, but it's a methodology change every OS level software writer needs to take to heart.

It's critical when Office crashes, or had bugs, but not as critical as in SSL, Apache or something similar.

In short, I think the laissez faire attitude we all have, both from accepting bugs, and about coding them ourselves is a SIGNIFICANT part of the problem. We need to raise the expectations, and hold people/companies accountable when these standards are not met.

Cheers,
Greg

Re:Why is some software more secure than others?

[iabervon]

X.509 may be extremely complex to handle, but that would lead to incorrect X.509 implementations. This, however, was just unsafe code. There's nothing about X.509's complexity which should lead to stack corruption.

The errors which you should expect from a X.509 implementation involve failing to parse obscure certificates correctly or failing to give the right error message about a malformed X.509 certificate. If the code itself is simple in implementation, it should be straightforwardly obvious that, no matter what, the parser will return either an X.509 structure or an error message; the complexity of X.509 merely prevents anyone from determining if the return value is actually correct.

OpenSSL has a lot of spagetti code, wrappers, and unnecessary function pointers, inherited from the SSLeay days. In an ideal world, it would be rewritten to be more straightforward, but that's more effort than anyone is really willing to put in (except the GNUTLS people, but that's license-related anyway).

Re:Why is some software more secure than others?

[pebs]

In short, I think the laissez faire attitude we all have, both from accepting bugs, and about coding them ourselves is a SIGNIFICANT part of the problem. We need to raise the expectations, and hold people/companies accountable when these standards are not met.

Here lies the problem:

1) Cheap
2) Fast
3) Secure

Pick 2

grsec?

[BenjyD]

Another good reason to run a kernel with the grsecurity patches on servers?

Re:Feeling kinda good about it

[wfberg]

At least we find out when where vulnerable BEFORE the exploits start rolling out.

As opposed to what? The months before Blaster came out that the patch was available?

To be fair; that patch didn't install on a significant portion of machines (any system running w2k sp2), and the work-around Microsoft suggested didn't either, and if it did, it didn't until a reboot, which wasn't mentioned.
Add to that that the first patch appeared to install but did not (and would also not "re"install) on a number of machines. Today microsoft advises you to run a firewall and anti-virus programs all over their webpage. Before the blaster incident they didn't, because they hadn't dropped the ball quite as badly yet.

I also find it (not so..) amusing that the System File Checker doesn't work without the DCOM service running (which isn't running for example, in Safe Mode, a Mode you'd expect sfc to be used in), and that DCOM for some reason listens to any one who will talk to it, rather than, by default, restrict access to 127/8.

Re:So basically

[Anonymous Coward]

It is called a "double" standard. To see more examples of the double standard take a quick look here and quickly scan the list for "root compromise". I'm not fingering any particular distro of Linux/*BSD/etc or any particular open source project as much as giving a url for a convenient example that shows that software developed by the open source movement seems to have bugs which can potentially allow a machine to be rooted.

Now go look at Microsoft's security vulnerability list (sorry no URL handy - poke around on technet.microsoft.com) and look for exploits in Microsoft software that can result in gaining local system privileges over the same period of time. You'll see that Microsoft is on pretty even footing although some of its products are more notorious than others for their inherient security flaws.

the ole keep it simple stupid...

[vt0asta]

...troll. Work smarter not harder. Nyuck, nyuck, nyuck. Well, thank god your here to tell everyone how to code secure simple software.

Be advised that complex data dependent protocols are not trivial to code. Not only that, they are even harder to get to interoperate with other implementations of the same protocol. All the nasty little bug-a-boos show up that the protocol designers hadn't thought or even dreamed of.

I count OpenSSL as insecure software - we need a secure replacement.

So what's the plan? Toss out all the OpenSSL/GNUtls code and start over...but this time let's try something new... let's make it simple and secure?

What you don't seem to understand, is that people far smarter than you and I have already had these philosophical debates and do you know what they came up with?

No software is completely secure.

Prompt disclosure is important.

More eyes, code review, what have you is a good thing.

Plan for failure/breaches/etc.

Your measure of secure software is juvenile. It doesn't even provide an interesting definition of software security. Pointing at less than complete implementations of smtp and ftp makes your entire argument suspect. Also the "auditing secure software is easy" comment is another dead give away.

Re:phew

[BlackBolt]

Yeah, me too. Ignorance is bliss.

I like to just sit back, have an espresso, and let everything around me fall into chaos. Life is good; the flashing warning lights keep me company through the long night.