nighthawk wrote:

Wenn ich das richtig in Erinnerung habe, forscht Coverity nur nach sicherheitsrelevanten Fehlern. Das legt ja nahe, daß auch bei Postfix ebensolche Fehler gefunden wurden. Gibt es irgendwo dazu Angaben, was genau betroffen war und in welcher Version die Fehler behoben wurden?

Zu den aktuellen Scans kann ich nichts sagen, aber Wietse hat sich in 2006 mal zu Coverity geäussert in einem kleinen Thread auf postfix-users: http://readlist.com/lists/postfix.org/postfix-users/12/62081.html

| As some may know, Postfix has a lot of sanity checks in the code, many of | which test for conditions that never happen. The reason these sanity | checks exist is that they limit the possible damage from programming | error. Knowing that Postfix was going to be 10s of thousands of lines of | code (it is more than 80,000 now), I know there were going to be errors in | the code, and therefore I was quite liberal with sanity checks throughout | the source. | | It is in two of these redundant sanity checks that Coverity found errors: | | 1) When the address verification server reads a record from the verify | database, it executes a sanity check to reject records with all zero time | stamps. Such records are never written; the test is there just in case | something is broken, so that Postfix will not blindly march on and create | chaos. The test for all zero time stamps was implemented incorrectly, | because the code tested pointer values instead of dereferencing the | pointers and testing their targets. | | 2) When the maildir delivery routine opens an output file it looks up the | file attributes via the file handle it just got. There is a sanity check | that detects if the attribute lookup fails, an error that never happens. | The code that handles the impossible error did not close the output file. | This would cause a virtual or local delivery agent to waste up to 100 file | descriptors. But for that error to happen the system would have to be so | sick that you would have more serious problems than a file descriptor | leak. | | All in all, that's a pretty good score for Coverity: two bugs in code that | tries to catch errors that never happen.

Außer der allgemeinen Tabelle im Report finde ich dazu auch nichts.

Defect Type Number of Defects Percentage NULL Pointer Dereference 6,448 27.95% Resource Leak 5,852 25.73% Unintentional Ignored Expressions 2,252 9.76% Use Before Test (NULL) 1,867 8.09% Buffer Overrun (statically allocated) 1,417 6.14% Use After Free 1,491 6.46% Unsafe use of Returned NULL 1,349 5.85% Uninitialized Values Read 1,268 5.50% Unsafe use of Returned Negative 859 3.72% Type and Allocation Size Mismatch 144 0.62% Buffer Overrun (dynamically allocated) 72 0.31% Use Before Test (negative) 49 0.21%

quelle: http://scan.coverity.com/report/Coverity_White_Paper-Scan_Open_Source_Report...

Hier geht es aber auch weniger um konkrete Exploits als um die Codequalität. So etwas wird automatisiert mit Tools zur Codeanalyse ermittelt. Dabei wird eine Art 'Metacompilat' erzeugt, dessen Laufzeitverhalten beobachtet wird. So werden memory leaks, race conditions, fehlende boundary checks u.ä. ermittelt.

Mit konkreten Angriffen, CVEs & Co hat das also (erst mal) noch nichts zu tun. Postfix schneidet im übrigen, gemessen an der Zahl der Codezeilen, hervorragend ab.