Slashdot Mirror
US DHS Testing FOSS Security
Stony Stevenson alerts us to a US Department of Homeland Security program in which subcontractors have been examining FOSS source code for security vulnerabilities. InformationWeek.com takes a glass-half-empty approach to reporting the story, saying that for FOSS code on average 1 line in 1000 contains a security bug. From the article: 'A total of 7,826 open source project defects have been fixed through the Homeland Security review, or one every two hours since it was launched in 2006 ...' ZDNet Australia prefers to emphasize those FOSS projects that fixed every reported bug, thus achieving a clean bill of health according to DHS. These include PHP, Perl, Python, Postfix, and Samba.
Now if they would do the same to Microsoft. Oh yeah...
Do they mean fixed or fixed?
You can't ever say that proprietary software is secure, because there's no way to prove it. With Open Source, you can come a lot closer to proving that it is secure, because you can employ every security test that exists.
The fact that a coverity scanner bug is reported doesn't mean it's an exploitable security flaw.
Bruce
Bruce Perens.
Computer terrorism. They don't want a send-mail bug to allow a beachhead for compromising more sensitive systems.
Uh.. from the article, the software is called "Prevent Software Quality System"... Wow, I can't think of a bigger misnomer for something that should help improve software quality. I sure don't want to prevent software quality in my own products.
http://scan.coverity.com/
Although I understand what you're trying to say, it does seem a little irrelevant.
I'm a software security engineer. I can look at source code and tell you if it has some bugs in it that I would consider relevant to security. If I can't find any, I might tell you that it is more secure than if I could... but that's doesn't mean it is secure. I'll never tell you it is secure, because testing simply can't give you that. I can do this on proprietary software or I can do this on Open Source software.. the only difference is that, with the Open Source software, I don't need permission from someone to do the testing and other people don't need permission to check my work.
Does this mean that more people will check the Open Source software for security flaws? Not necessarily. It completely depends on whether or not someone has an interest in the security of that particular bit of software. Even assuming a similar level of interest in the security of comparable proprietary and Open Source software, there's no guarantee that those who have an interest in testing the Open Source software for security flaws will report back the findings. They may simply decide that the Open Source software is too insecure for their use and go with the proprietary solution - assuming they can have it similarly tested by a trusted third party.
All in all, the assumption that Open Source software is more secure than proprietary software is most likely true, but there's no hard data.. because the stats on the insecurity of proprietary software are guarded secrets - and that's probably the best reason to assume that proprietary software is less secure.
How we know is more important than what we know.
How could he possibly know that? He said already that he stopped reading after 'the PHP'.
Crumb's Corollary: Never bring a knife to a bun fight.
According to McAfee recently (http://yro.slashdot.org/article.pl?sid=08/01/05/0215201) and Microsoft et al, having your code exposed lets the bad guys exploit it's vulnerabilities. Of course if or when a weakness is taken advantage of, it would likely be fixed vary quickly through the FOSS community, instead of on the first Tuesday of every month like as in Microsoft's business model.
I checked out the Coverity website and saw on the list of projects the aalib ASCII art library which according to the history hasn't been updated for something like 7 years.
Damn we better protect ourselves from Terrists hiding their WMD's in ASCI art
I am Slashdot. Are you Slashdot as well?
The article did not seem to give any data on false positives. A story here has Coverity claiming a 10% false positive rate. But there is no independent confirmation. It would also be interesting to know how hard it is to prove a false positive vs. how hard to fix a true positive. In other words, it it worth Coverity's time to further reduce the false positive rate.
This seems like a genuinely useful activity for DHS, certainly more valuable than x-raying my shoes and confiscating my saline solution.
What I'm listening to now on Pandora...
Indeed. FTFA:
One can only speculate about the, er, source of their discomfort.... 8^)
1 per 1000 lines is even more impressive as an average across all 180 FOSS applications tested. Most impressive of all are the highlights:
Even some of those with more bugs have at least responded well:
And my favourite 'backslider' of all, OpenVPN, has yet to fix 100% of the bugs found during this exercise. Of course, that's only 1 bug in over 69,000 lines of code....
These results should be viewed as excellent, by and large. This doesn't mean all this software is bug-free, just that there aren't a lot of easily preventable bugs in the code base. Most encouraging, though, is how fast they got addressed and fixed by the healthier FOSS projects.
Crumb's Corollary: Never bring a knife to a bun fight.
There are two problems with your suggestion:
a) it is too restrictive, and would disqualify the GPL as free software. Remember, that the GPL is a distribution license, not a list of restrictions. You should be able to talk to other people (even publicly) about software without contacting the maintainer first. The behavior you describe is responsible, and generally recommended, but should not be forced.
b) as you have it worded, if the restrictions were followed, it would enable a maintainer to prevent anyone from disclosing any security bugs. You say that reporters have to wait for an acknowledgment. What if one is never received? What if there is no maintainer? The solution for this problem is obvious (don't require an acknowledgment), but I should point it out, nonetheless.
c) It is not enforceable in most jurisdictions. In the US, and I assume most of the "free world", you can't prevent someone from talking about your products publicly. You can have them sign an NDA, but that doesn't work for publicly available software. McAfee tried something like this some time ago, stipulating in the EULA that you can't benchmark their software. It got shot down in court.
Write your own Choose Your Own Adventure. http://www.freegameengines.org/gamebook-engine/
Comment removed based on user account deletion
From TFA:
The popular MySQL open source database was not included in the scans for reasons that were not immediately evident.
Any suggestions as to why MySQL has no results? I'm stumped and wondering why one whole corner of a LAMP foundation was left unchecked.
So close. Lets turn those into a proper Tcl list, shall we...
set thislist {Samba} {the PHP} {Perl} {Tcl dynamic languages} {Amanda}No, I think he's deliberately speaking with a LISP.... 8^)
Crumb's Corollary: Never bring a knife to a bun fight.
Not all bugs are easily reproducible - and not all bugs are found by tripping over them. Consider, for example, bugs found by various of the warnings enabled by GCC's -W options. I.e., you get reports saying "this code path has these problems", not reports saying "this code path blew up when I did XXX".
I just looked at an old report from Coverity on one of the free-software projects with which I'm involved - one of the problems it found was in a chunk of code
where it quite appropriately pointed out that we were checking whether cfg was null after dereferencing it rather than before dereferencing it. We subsequently fixed that problem.
It might be possible to construct a scenario where the application would crash due to that bug - or it might not; that bug is in "framework" code, and if the code using that framework code doesn't happen to pass an argument that would cause cfg to be null, there won't be a crash, but some code in the future might pass such an argument (which might be an argument that comes from user input, so it's not as if passing such an argument is a bug - perhaps the code using the framework code is expecting that code to tell the user of the error).
Even if it's possible to construct such a scenario, the software that found the problem doesn't have a deep enough understanding of the code to say "hey, if you open up the app on a file like with this in it and select this menu item and type this into the dialog box that pops up and then click 'OK', it'll crash", so it's not as if the software that's reporting this problem (non-publicly - to see the reports on an app, you have to be a "member" of the project whose code is being scanned, and sign up for an account) can give "a detailed account of how to reproduce the bug".
I submit that people who are only looking for security flaws don't have a motivation to develop a deep understanding of the software. People who are out to modify the software do. And thus there are not just more eyes, but better eyes with Free Software.
There is a class of mathematically provable software languages, and you might be able to say with surety that programs in them are secure. For the languages we usually use, you can only say that you have tested them in the ways you know of. And only a person with access to the source can say that. If you want an independent asessment, Open Source software won't stop one from happening, and won't hinder what can be said with NDAs. That's why I think it's more secure.
Bruce
Bruce Perens.
Learn grammar: "The Windows ARE broken", since all of them are.
A more apt analogy would be: There's no point in locking your door using a limp spaghetti noodle because a limp noodle makes a completely ineffective lock.
Languages like And Such, and the PHP.
Security and computer science as explained by a valley girl?
Like totally!
Everything I need to know I learned by killing smart people and eating their brains.
Not only did the article say much like its commercial counterpart, but most of the numbers it shows are actually good for open source software.
For instance, most of the projects discussed had less than 1 bug for 1000 lines of code. For instance, the Linux kernel had .127 bugs per 1000 lines, and that on over 3 million lines of code.
Also, the article talks about key projects, such as the glibc (which is basically used by everything on a Linux system) that already fixed all the issues.
Even something huge and complex as Firefox has already fixed half of the issues, and is showing progress on the rest of them (by the fact that some were already verified).
Overall, I didn't get the half glass empty tone that the summary is implying. And what I found strange is that even the comments on the site itself, and many of them on /. itself, are also taking the pessimistic view.
I thought that this news are great for open source software. Shows that it has less security issues than average, that the issues are fixed quickly, and still that some programs are certified by a company for use in security related departments such as the DHS. What could be better than that?
First off, prevent is not strictly a security flaw static-analysis checker. It is a static-analysis checker that checks for all sorts of defects. Some of which are directly related to security. Second, I have used prevent extensively over the past year and have found it to be an invaluable tool. It has a pretty low false positive rate and fixing the defects it finds means your code is better. On the code I work on, I find that we have a much lower defect count. But we also have pretty mature code and we really do attempt to make it as bullet proof as possible. But we still have defects.
My experience is with the C/C++ version of tool. We have also been evaluating the java version of the tool and it is good. But some of the free alternatives like findbugs are still better. I would use findbugs w/ prevent for java if I wanted good coverage.
"For example, MacOS and Windows had a similar number of critical security patches last year."
Willing to stipulate for the purpose of this discussion.
However, there were dozens of Windows viruses and hundreds of thousands of compromised machines, and zero MacOS viruses.
Likewise willing to stipulate.
Thus, while a certain measure of vulnerability is comparable, the likelihood of actually being attacked is infinitely highder with Windows.
I would suggest this doesn't necessarily follow. It could be. It could also be that while both fixed the same number of holes, the percentage of holes fixed was different. It could be that x holes represented 85% of the mac holes, whereas the same exact number x was only 13% of the available windows holes.
Not saying one or the other interpretation is true. Just that the facts don't necessarily lead to the conclusion posited.
Analogies have their limits, so we shouldn't try to take it too far.
Even those who historically have critized "security through obscurity" never suggested that publishing their design or secrets would lead to better security, but rather that you can't assume your that your design can't be cracked.
Of course, the preferred approach is "security through design" which has nothing to do with correcting bugs. The latter could be called "security through maintenence". Thus while we might argue about whether closed or open source produces better design, examining source code for bugs can't compensate for a design that is insecure.
There are industry estimates that say average code in production contains 2 bugs per thousand lines of code. Some say that number is much higher. How many lines do you think are in Vista?
Yes, OSS has bugs. Everything from compilers to content management systems, surely. So do proprietary programs.
The more qualified eyes you get on a bug, the better chance you have of finding and fixing it. You can do that by having a big staff that pores over code again and again. You can do it by having lots of outside help, like in the case of popular OSS projects. One thing that helps is to have a fresh set of eyes look over something, which is much easier in OSS that in closed-source applications.
BusinessWeek had an article from a guy at Coverity back in 2006 about this. In that article, Ben Chelf said that 4 of the top 15 programs on the quality scale measured by defects per thousand lines of code were OSS. He said that on average, the major-project OSS software they tested was indeed higher quality software than average. He said, though, that the absolute highest quality code was the cream-of-the-crop proprietary, closed source code from places that make things like fly-by-wire systems. Well, yeah. I'd want my airliner's fly-by-wire system completely bug-free, too.
Commercial software tends to harbor anywhere from 1 to 7 bugs per 1000 lines of code according to the National Cybersecurity Partnership's Working Group on the Software Lifecycle. Voluntary testing by Coverity requested (and probably paid for) by MySQL AB revealed that project to have all of 97 flaws, one of which could be a serious security issue. All 97 were to be fixed for the next release.
A similar study (same link) found 985 bugs in over 5,700,000 lines in the Linux kernel, or fewer than one bug per 10,000 lines of code. TFA has data on a newer version of the kernel -- 0.127 bugs per TLOC.
In Apache, 22 bugs total, 0.14 per TLOC, and three fixed so far.
PostgreSQL had 0.041 per TLOC, and have so far fixed 53 of the 90 bugs.
The glibc team fixed 83 of 83 bugs found.
OpenVPN had found one security-related bug in over 69,000 lines of code. As of later yesterday, it's officially security bug free according to the same testing people.
The list of officially security-bug free software includes Amanda, NTP, OpenPAM, OpenVPN, Overdose, Perl, PHP, Postfix, Python, Samba, and TCL.
So with Linux (0.127), glibc (0.000), Apache (0.140), PostgresSQL (0.041), Perl (0.024), PHP (0.000), and Python (0.000) powering a web server (numbers according to Coverity), you have 0.0474 defects per thousand lines of code across the server. I'd say that's pretty good.
There are numerous refutations to your "never suggested that publishing their design or secrets would lead to better security". Many experts have said precisely that.
An IT Security article on full disclosure states that as early as the middle of the 19th century locksmith Alfred C. Hobbes thought full disclosure was important to clear up the rash of lock picking people were experiencing. It goes on to discuss exactly why full disclosure works so well.
David Wagner says in an article on security: "Today, many security companies are strongly resisting this, and I think they will need to learn to accept and embrace public scrutiny as a natural and necessary part of security systems." -- David Wagner and Ian Goldberg are the ones who cracked the security of the SSL layer in Netscape 4.
IEEE article abstract stating that full source code access can have "real benefits for security", although that's not automatic and it has to be done correctly.
Bruce Schneier -- yes, THAT Bruce Schneier -- has an article on his blog that starts "Full disclosure -- the practice of making the details of security vulnerabilities public -- is a damned good idea. Public scrutiny is the only reliable way to improve security, while secrecy only makes us less secure."
Is that enough or do I need to go to the second page of this Google search?
BTW, DJB thinks that both full disclosure and isolation of trusted components are absolutely vital. He's the guy who won the right for Americans to export cryptography technology in court against the Department of Justice. He also found a timing attack against OpenSSL's AES cipher and his Unix Security Holes class of 16 students turned up 91 previously unknown holes in one semester.
As for "Security by design", that helps. However, with many programs being written in languages which allow null pointers, stack overflow, buffer overflow, and array overflow the design can be as secure as you want and the program can still be crashed. In some cases arbitrary code can still be executed. Address randomization, NX bits, run-time bounds checking, and automatic memory management can go a long way. Sanitation of inputs, static analysis, time padding, and more still have to be considered in some cases.
The tests Coverity is running are an example of static analysis. If there's a C routine that can be coerced into smashing the stack or overflowing a buffer in the heap, that can often be automatically caught and reported. Memory leaks often can be, too. They're probably also able to do at least rudimentary checks for sanitizing input values.
Thank you DHS for the contribution to FOSS!
We get all the bug fixes, and it will become that much more robust.
Too bad that Windows will never get this kind of review.
It probibly has a few less bugs per line,
but not much hope of getting those fixed.
On second thought, Mr Allen, I challenge you to compare!
I am willing to bet that FOSS software,
just because of its nature of peer review,
and from my experence of reading ALen Cox's work on the Kernel,
that it has less bugs than Windows.
So with Linux (0.127), glibc (0.000), Apache (0.140), PostgresSQL (0.041), Perl (0.024), PHP (0.000), and Python (0.000) powering a web server (numbers according to Coverity), you have 0.0474 defects per thousand lines of code across the server. I'd say that's pretty good.
I'd say your statistic is wrong. You need to multiply each average by the number of kloc per project (being careful to count those for the project version for which the averages were given), and then divide by the total kloc across all projects.
Just has to do with coding methodology. strcpy is insecure, strncpy is more so. strncpy(src, dst, sizeof(dst)) is more secure than strncpy(src, dst, size_of_dst). Those are easy to fix security bugs. Other security bugs are harder to find as you have to trace the myriad of states the app can be in during mem writes.
/* We'll just fit as much of the translated error as possible into this buffer */
strcpy is NOT insecure. It can be used insecurely.
But congratulations, you've just turned what could have been a borderline ok strcpy(src, dst) (ought to have been criticized at code review as the names of the variables are confusing) bit of code into (probably) a crash and definitely a buffer overrun if sizeof dst is larger than sizeof src.
I have lost count of the number of bugs I've had to fix after someone changed a perfectly good strcpy into strncpy. A common mistake is:
strcpy(dst, src);
becomes
strncpy(dst, src, sizeof dst);
and then you get a bug because only the first four characters of src appear in dst followed by garbage.
Of course, then it gets changed to
strncpy(dst, src, strlen(src));
because the original programmer did know what they were doing and the buffer was big enough.
Eventually we get to the brilliant:
strncpy(dst, src, strlen(src)+1);
Fantastic! What an improvement! And yes, it really does happen in what was once good production code because some idiot has heard that "strcpy is insecure".
Another one I've seen is:
dst = malloc(1000000);
strcpy(dst, "MESSAGE");
gets changed to
dst = malloc(1000000);
strncpy(dst, "MESSAGE", 1000000);
Yup, instead of writing 8 bytes, we'll write one million bytes because strcpy is insecure, but we won't fix the missing check for NULL. (there's a fairly good argument for not checking the return from malloc in much production code - if malloc actually fails then you're already so far up shit creek without a paddle that it's probably impossible to recover gracefully anyway. Obviously different considerations will apply if you're controlling a nuclear power plant than if you're writing a game)
strncpy is NOT a replacement for strcpy with a length parameter. Unfortunately strncpy has a very bad name, it should be called something like meminit_from_str() as strncpy ALWAYS writes n bytes and doesn't always write a null terminator. (I've also had to fix bugs where someone has replaced a correct use of strncpy with a version that guarantees to write the null)
strncat is a possibly safer replacement for strcat. However, the length parameter is so tricky to get right that I've seen cases where someone originally wrote strcat safely, that got changed to strncat "because it's safer" and then a bit later another change was made that caused a crash because the original change to strncat got the length parameter wrong.
extern char error_msg[][40];
char error[64];
strcpy(error, "ERROR");
strcat(error, error_msg[e]);
becomes
strncpy(error, "ERROR:", sizeof error);
strncat(error, error_msg[e], sizeof error - 6);
becomes
strncpy(error, get_translation("ERROR:", lang), sizeof error);
strncat(error, translated_error_msg(e, lang), sizeof error - strlen(error));
of course, even more common is to miss the -6 or strlen(error) completely than to remember the extra -1 that is required on the length parameter.
(The man pages are IMO, confusing for strncat as they usually say something along the lines of "appends at most n characters")
Tim.
God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
This is because the security problems with PHP aren't bugs, they designed it that way.
But hey, don't take my word for it.. go have a chat with your friend Theo de Raadt.. he'll give you the skinny on how terrible the majority of C programmers are when it comes to security issues. And don't get him started on the so called "safe" languages.
How we know is more important than what we know.
Great, great post. For an alternative to strncpy() etc,
see <http://www.courtesan.com/todd/papers/strlcpy.html>.
slashdottagsshorterthanhaikunewartform
You're right. I forgot to weight them based on the portion of the installation they'd each represent.
It's also unlikely that any real installation would have exactly those packages installed, BTW. Almost any installation will have packages from CPAN, PEAR, whatever Python's central repository is called, some extra stuff like syslog, logrotate, bash, and at least one text editor at the very minimum.
Let's be a little more accurate than multiplying by defects per thousand lines to make up for my previous late-night gaffe. Let's use the actual defect numbers of verified but unfixed and unverified defects.
Apache has 19 defects in 135,916 LOC.
glibc has 0 defects in 588,931 LOC.
Linux has 461 defects in 3,639,322 LOC.
Perl has 12 defects in 496,517 LOC.
PHP has 0 defects in 474,988 LOC.
PostgreSQL has 37 defects in 909,148 LOC.
Python has 0 defects in 282,444 LOC.
That's 6,527,266 LOC and 529 defects. That's 6527.266 TLOC. I get 0.081 defects per TLOC. That's still pretty damn good.
As I said, there's probably some other software on that server, but it starts from a pretty strong base.
I'm so much of a rabid MS hater that I'm writing this post from Firefox 3b2 on Windows XP. Get real.
;-)
;-), and they obviously have advantages over many smaller OSS projects.
Where did you pull the 1% of OSS users being programmers from? Your ass? You didn't even cite your own ass? How rude!
Yeah, there aren't enough world-class programmers to go around the millions of OSS projects out there, or even the most popular hundred thousand of them. Maybe not the ten thousand most popular. Yet over half the patches for the Linux kernel come from people other than the core development team.
In fact, the top submitter of changesets into Linux 2.6.20 only accounted for 4.8% of them. The top 20 contributors accounted for 28% of changesets. Similar numbers pop up by number of lines added. Linus only personally signed off on 13% of the changes in 2.6.20 so there's a good spread there, too.
The people developing the Linux kernel aren't just weekend coders in their parents' basements. Red Hat, IBM, Novell, Intel, Oracle, Google, University of Aberdeen, HP, Nokia, SGI, Astaro, MIPS Technologies, MontaVista, and Broadcom were among the top 20 sources of changesets. Stats of 7.7% for "no employer" and 25% for "unknown" appear, along with a few lesser-known companies. Add Sony to the list of employers of contributors by lines of code. Put Freescale in the list for the versions in the year in which versions from 2.6.16 to 2.6.20 were developed.
In all, 65% of the changes to the Linux kernel for version 2.6.20 was from corporate development. Over 1,900 people had patches make it into the 2.6.20 version of the kernel alone.
All these statistics on who develops Linux can be found at LWN.net's article called "Who Wrote 2.6.20?".
How many companies write and vet the code at Microsoft? Yes, I'm sure there are a bunch of dedicated people at Microsoft, and they do a pretty good job at making a usable OS. They're getting better about security. It's my opinion that Vista's kind of a mess particularly because they're having trouble designing for both usability and security from the ground up. They'll improve on that, too. I don't hate Microsoft's developers (maybe their marketing and legal departments
However, the biggest OSS projects really do have a lot of people who are highly skilled professional programmers writing their code. They also have an advantage of being able to attack issues most important to their varied employers using skills and development methods different from those at other corporate contributors.
It's not a black or white issue. Microsoft's got pros and cons, and so does their software. OSS has pros and cons. I have two PCs at this desk. One's XP Pro and one's Linux. I use both every day I'm in the office. I also use Linux servers and I have a Mac at another desk. At home I have XP, Linux, Solaris, Mac, and OS/2 (the OS/2 is for fun). My wife's PC has XP on it, but she can use the Linux box when she needs to. She's not an admin level user, but she can fix some issues on Windows just from having used it so much for so long.
To bash MS when they really screw something up isn't to be a "rabid MS hater". To praise them when they do something well isn't to be an MS fan. The same's true of OSS projects. Most people want their software to meet their needs and don't root for one "team" or another. Most people who do prefer a particular project are still willing to give other projects their due respect. There are very vocal fanatics in every camp, but just because they're loud and quicker to spout doesn't mean they're actually that numerous.
I haven't tried this, and indeed there isn't much real work going on in provable software languages these days. But I think that it would be possible to set theoretical constraints on a program such that it serves data and does not allow it to be modified. There might be a good Ph.D. paper in it for someone.
It's possible to prove almost anything about the programs and operating systems, from type safety and runtime guarantees to any arbitrary set of predicates you want the system to satisfy. That assumes perfect hardware, so at most a security guarantee must be probabilistic, but can be made arbitrarily close to 100% secure by using redundancy and potentially cryptography in hardware to ensure either correct results or the triggering of an error condition.
For some current examples of work in this area you might look at George Necula's work on proof carrying code, which looks pretty interesting. They also have a Java and I think even a subset of C compiler that can output proofs of type safety. I haven't tried them though.
Another big challenge is to figure out how much the security model should cover. Type safety, privilege separation and file permissions are pretty obvious things to include, but what about network security, probabilistic assumptions about cryptographic security, or information control polices like the original Common Criteria required?. It would be useful for normal users to have some sort of classification they could assign to their personal information that the OS could use to keep most processes away from it. I've been interested in capability systems for quite a while too, since they often match a provable security model and programming language a little better than the typical ACL and privilege approaches.