Alarming Open-Source Security Holes


#1

[quote=", post:, topic:"]

Back in May 2006, a few programmers working on an open-source security project made a whopper of a mistake. Last week, the full impact of that mistake was just beginning to dawn on security professionals around the world.

In technical terms, a programming error reduced the amount of entropy used to create the cryptographic keys in a piece of code called the OpenSSL library, which is used by programs like the Apache Web server, the SSH remote access program, the IPsec Virtual Private Network (VPN), secure e-mail programs, some software used for anonymously accessing the Internet, and so on.

In plainer language: after a week of analysis, we now know that two changed lines of code have created profound security vulnerabilities in at least four different open-source operating systems, 25 different application programs, and millions of individual computer systems on the Internet. And even though the vulnerability was discovered on May 13 and a patch has been distributed, installing the patch doesn’t repair the damage to the compromised systems. What’s even more alarming is that some computers may be compromised even though they aren’t running the suspect code.

The reason that the patch doesn’t fix the problem has to do with the specifics of the programmers’ error. Modern computer systems employ large numbers to generate the keys that are used to encrypt and decrypt information sent over a network. Authorized users know the right key, so they don’t have to guess it. Malevolent hackers don’t know the right key. Normally, it would simply take too long to guess it by trying all possible keys–like, hundreds of billions of years too long.

But the security of the system turns upside down if the computer can only use a limited number of a million different keys. For the authorized user, the key looks good–the data gets encrypted. But the bad guy’s software can quickly make and then try all possible keys for a specific computer. The error introduced two years ago makes cryptographic keys easy to guess.

The error doesn’t give every computer the same cryptographic key–that would have been caught before now. Instead, it reduces the number of different keys that these Linux computers can generate to 32,767 different keys, depending on the computer’s processor architecture, the size of the key, and the key type.

Less than a day after the vulnerability was announced, computer hacker HD Moore of the Metasploit project released a set of “toys” for cracking the keys of these poor Linux and Ubuntu computer systems. As of Sunday, Moore’s website had downloadable files of precomputed keys, just to make it easier to identify vulnerable computer systems.

Unlike the common buffer overflow bug, which can be fixed by loading new software, keys created with the buggy software don’t get better when the computer is patched: instead, new keys have to be generated and installed. Complicating the process is the fact that keys also need to be certified and distributed: the process is time consuming, complex, and error prone.

Nobody knows just how many systems are impacted by this problem, because cryptographic keys are portable: vulnerable keys could have been generated on a Debian system in one office and then installed on a server running Windows in another. Debian is a favored Linux distribution of many security professionals, and Ubuntu is one of the most popular Linux distributions for general use, so the reach of the problem could be quite widespread.

So how did the programmers make the mistake in the first place? Ironically, they were using an automated tool designed to catch the kinds of programming bugs that lead to security vulnerabilities. The tool, called Valgrind, discovered that the OpenSSL library was using a block of memory without initializing the memory to a known state–for example, setting the block’s contents to be all zeros. Normally, it’s a mistake to use memory without setting it to a known value. But in this case, that unknown state was being intentionally used by the OpenSSL library to help generate randomness.

Source: http://www.technologyreview.com/Infotech/20801/?a=f

[/quote][quote=", post:, topic:"]
Homeland Security Helps Reduce Open Source Flaws

Two years into the effort, new report sheds light on how effective your tax dollars have been at improving open source security.

Nearly two and a half years ago, the US Department of Homeland Security (DHS) issued a multi-year grant to help improve open source code quality. It appears that the DHS investment has paid off.

According to a report from code analysis vendor Coverity, the DHS sponsored effort has helped to reduce the defect density in 250 open source projects by 16 percent over the past two years. That defect reduction translates into the elimination of over 8,500 defects. The report on the benefits of the DHS open source security efforts comes at a time when open source software is increasingly becoming part of critical infrastructure both in the government and in US enterprises.

“The improvement of project defect density is such that when we started the effort they were at 0.30 defects per thousand lines of code and now they are down to on average 0.25 defects per thousand lines of code,” David Maxwell, open source strategist for Coverity told InternetNews.com. "I know that feels like a small percentage change but when it’s over 55 million code it adds up."

Coverity is a code analysis vendor and runs its scanning tools on the included open source projects to identify coding errors.

While many projects have benefited from running the DHS sponsored Coverity scan, not all have actually managed to reduce their defects.

“There is a graph in the report that shows some project have significant improvements and some that haven’t been actively using the results from the scan that have actually increased in defect density,” Maxwell commented.

The report graph that was provided to InternetNews.com doesn’t fully name the names of those project that did not improve as a result their defect densities. The report however did identify Perl, PHP, Python, Postfix, Samba and TCL among the projects that have been able to reduce their code defect densities by using data from the Coverity scans.

Popular errors

Coverity’s scanning efforts have also provided them with some interesting statistical data points about which type of errors seem to occur more often than others. Leading the pack are Null Pointer Dereferences at nearly 28 percent.

“This type of error often occurs when one code path initializes a pointer before its use, but another code path bypasses the initialization process,” Coverity said in its report. "Because pointers are often used to pass data structures by reference between pieces of program logic, they may be the most commonly manipulated data objects due to repeated copying, aliasing and accessing. Therefore, it is not surprising that the most frequently used artifacts will incur the most errors in manipulation."

Coming in second for recurring defects are resource leaks at 26 percent of all defects.

“Resource leaks often involve failure to release resources when the initial allocation succeeds, but a subsequent additional required resource is not available,” the Coverity report explains.

Maxwell commented that in looking at the volume of data they were able to collect on open source projects there were some things that went against their expectations.

Among the findings that Coverity did not expect is one that has to do with function length and its relationship to defect density. Maxwell explained that there is a common myth or misconception that if a code function is too long and for example can’t fit on a programmers screen, then it is more defect prone. As it turns out, that’s not the case.

“The defect density did not increase,” Maxwell said. “There is almost no correlation between average function length in a project and a project’s defect density.”

The DHS grant money that is helping Coverity to run the scans was originally announced to only be for a three year term. The term ends in the July/August time frame of this year.

“DHS does not have a mandate for doing ongoing efforts as they’re oriented on research and development and technology transition so it wouldn’t be within their purview to fund an ongoing effort,” Maxwell said.

That said, Coverity isn’t necessarily done with the open source scanning effort.

“It is our intention to continue,” Maxwell added. "Open Source developers have given us a very positive response and we want to continue to offer the service."

Source: http://www.internetnews.com/security/article.php/3747961

[/quote]

Open source? Yeah… what ever. :rolleyes:

:D^_^


#2

its mainly a vunerablity in OpenSSL

and is actually one of the few compare that to the thousands of vunerabliteis that exist in closed source programs and this is nothin compared to that


#3

[quote=", post:, topic:"]

Open source? Yeah… what ever. :rolleyes:

:D^_^

[/quote]

I’m sure I could start linking similar vulnerabilities in close source and say “whatever”. But unfortunately, that doesn’t prove any point; and no one will ever be able to win an argument of opensource vs closed source proprietary software.

Moreover, the lame article writer there is exaggerating. Every software obviously has problems, but Microsoft and Apple take months to fix them while it only takes few days to fix them in opensource world ;)

Well, here’s another blog entry: http://etbe.coker.com.au/2008/05/21/security-flaws-in-free-software/


#4

[quote=", post:, topic:"]

its mainly a vunerablity in OpenSSL

and is actually one of the few compare that to the thousands of vunerabliteis that exist in closed source programs and this is nothin compared to that

[/quote]

Yeah, but my point was that blind faith in open source is hazardous. The thousand of vulnerabilities, as you say, are usually patched quickly and not left to dangle like softwares dependent on OpenSSL.

[quote=", post:, topic:"]
I’m sure I could start linking similar vulnerabilities in close source and say “whatever”. But unfortunately, that doesn’t prove any point; and no one will ever be able to win an argument of opensource vs closed source proprietary software.
[/quote]

Do that; linking vulnerabilities in major closed source softwares, that is. Also mention how many of them are fixed.

And yeah, most people have their minds made up so a debate is pretty much useless.

[quote=", post:, topic:"]
Moreover, the lame article writer there is exaggerating. Every software obviously has problems, but Microsoft and Apple take months to fix them while it only takes few days to fix them in opensource world ;)
[/quote]

lame article? Sure… That is what you would say. I got it via ACM’s subscription. :rolleyes:

Microsoft doesn’t takes months to fix problems or vulnerabilities, and we are not taking some odd case here. Apple does takes a lot of time, but not Microosft since their software runs on the majority of PCs. They would be sued left and right if they weren’t quick to respond.