LAMP Lights the OSS Security Way 178
Kevin Young wrote to mention a ZDNet article which goes into some detail on new results from a Department of Homeland security initiative. It's called the 'Open Source Hardening Project', and (funded to the tune of $1.24 Million) the goals of the initiative are to use a commercial tool for source code analysis to buck up the security base of many OSS projects. LAMP (the conglomeration of Linux, Apache, MySQL, and PHP/Perl/Python) was a 'winner' in the eyes of the project. From the article: "In the analysis, more than 17.5 million lines of code from 32 open-source projects were scanned. On average, 0.434 bugs per 1,000 lines of code were found, Coverity said. The LAMP stack, however, 'showed significantly better software quality," with an average of 0.29 defects per 1,000 lines of code, the technology company said.'"
Old news (Score:2, Informative)
Dupe (Score:1, Informative)
Re:Huh? (Score:2, Informative)
Re:Solution for the time being... (Score:3, Informative)
If you are relying on this type of architecture, where one machine does all the work, interoperability with seperate databases is probably not even needed.
But if you're working with a project that needs replication and such, then you really can't rely on DB and web server being the same machine. Sometimes you have to sell your software as an installable product and make it work on multiple DB platforms. Sometimes you have to write to foreign databases using ODBC.
Simplifying queries isn't an extensible solution. For instance, it is intuitive to use
"LIMIT 10,20" (MySQL) instead of using "TOP 20 WHERE ID >= 10" (T-SQL). No simplification will fix that branch, and its kind of obvious that one of the solutions makes more sense. (Or, alternatively, how MySQL will by default install rules fill in blank strings in most fields if no data is provided for them, instead of throwing an error.)
They did test OpenBSD. (Score:3, Informative)
Re:Maybe I've been reading too much politics latel (Score:4, Informative)
Spot on, as you can see on scan.coverity.com [coverity.com]:
- PHP features 205 defects for 431,327locs, or 0.475 defects/kloc
- Perl has 91 defects for 431,327locs, or 0.19 defects/kloc
- Python is very slightly lower than perl (but with a noticeably smaller codebase) at 49 defects for 259,908locs or 0.189 defects/kloc
- Apache-httpd features 32 defects in 127,817 locs, or 0.25 defect/klock
MySQL isn't featured (Ruby is also a noticeable absent), but PostgreSQL stands at 296 defects for 815,748 locs, or 0.363 defects/kloc, and the lightweight SQLite has 16 defects for 60,722 locs or 0.263 defect/klock.Re:YEAH RIGHT! (Score:2, Informative)
* The Amanda developers (as far as I know) were not contacted that Amanda was on the list before it became news. But, Coverity _was_ quick and friendly about giving Amanda developers full access to the bug list for Amanda when we registered.
* Their checks do go beyond simple static checking; they are looking at possible values of index variables at different points in the code to assess potential overflows, and they are tracking malloc/free pretty well. You can find papers about their techniques on Dawson Engler's page at Stanford. There's no doubt that they are holding the clue stick here.
For Amanda specifically, the majority, 76 out of 108 issues found, were malloc/free mismatches. In addition, there were 9 dead-code determinations, 16 potential null pointer dereferences, 3 cases of a function returning -1 into an length variable that is used without checking, 1 uninitialized variable, and 3 array overflows cases, for 108 problems in ~89kloc, or ~1.2/kloc.
Of the 3 array overflow reports, 1 was a false positive, and 2 were cases inside the report generator where the dump level read from the logs was not range checked before per-level statistics were updated. So a corrupted log could cause the report to fail, but no buffer-overflow security holes.
In summary, I'd say the results are quite useful. Thanks to Coverity and our Homeland Security Big Brothers for funding these scans.
James da Silva
PHP could soon have lowest bugs/KLOC! (Score:2, Informative)
Well, I know a way where you can leave PHP in that stack and still make the bugs/KLOC figure go down REALLY fast. All I need is for someone to check in this simple fix:
[BTW, I suggest using an optimization setting for the compiler so that redundant code is removed.]It has long been known that bugs/KLOC is a convenient, but not necessarily informative, statistic. A few seconds with google might prove enlightening: