Hallo zusammen!
Kurz und bündig - wie aussagekräftig sind solche Meldungen?
CU
Olaf
Programmieren - alles kontrollieren 4.942 Themen, 20.719 Beiträge
angelpage 
Olaf19 „Firefox: 655 Fehler, 71 Sicherheitslücken?“
Hallo Olaf,
"wo gehobelt wird, fallen Späne" oder "Nur der, der nichts tut, macht keine Fehler" - diese Sprichwörter gelten doch schon immer. Weshalb sollte das ausgerechnet beim Firefox anders sein. Auch Linux hat eine ähnliche Bewertung ... Wen wunderts?
Dabei hat nur ein! Unternehmen allein diese Fehler und Sicherheitslücken festgestellt. Einige sind sicher überbewertet, aber andere fehlen noch.
Klar sollte nur auch in diesem Forum sein, dass das eben (leider) auch für den Internet Explorer (7 - sollte mal probiert werden) und Windows gilt.
Allen Nickles eine schöne Woche
Olaf19 angelpage „Hallo Olaf, wo gehobelt wird, fallen Späne oder Nur der, der nichts tut, macht...“
Hi Manfred,
prinzipiell ist mir das natürlich alles klar ;-) Nur kamen mir die Zahlen etwas hoch vor, z.B. spricht Secunia nur von 35 potenziellen Problemen, von denen 31 schon gepatcht sein sollen.
Weiß aber nicht, ob die Vorgehensweisen vergleichbar sind, deswegen interessierte mich das Ganze einmal aus Programmierer-Sicht, daher das Post auf diesem Board und nicht auf "DSL, Internet, Modems".
CU
Olaf
xafford Olaf19 „Firefox: 655 Fehler, 71 Sicherheitslücken?“
wie aussagekräftig sind solche Meldungen?
Dazu muss man ungefähr wissen, wie die eingesetzten Programme zur Fehlersuche arbeiten. Diese Programme machen eine rein symantische Prüfung anhand des Quelltextes und suchen spezielle Auffälligkeiten, wie z.B. ein strcpy() oder memcpy(), also sie suchen nach bestimmten anfälligen Funktionen, gängigen Fehlern, zu kleinen Puffern, fehlenden Überprüfungen von Parameterlängen, angeforderten Ressourcen, die nicht wieder frei gegeben werden...
Diese Art der Suche hat natürlich ein paar arge Einschränkungen, so können Fehler in Codeteilen entdeckt werden, die unter Umständen gar nicht mitkompiliert werden, oder bei der Kompilierung wegfallen. Zudem können Fehler im Code entdeckt werden, die gar nicht auftreten können, z.B. weil der Fehler in einer Funktion ist, deren Parameter schon vor der Übergabe in einer anderen Funktion auf Gültigkeit überprüft werden. Zudem gibt es auch Fehler, die diese Tools gar nicht aufspüren können, weil diese Fehler z.B. in der Programmlogik selbst stecken, wie z.B. die neu entdeckte Lücke in PHP mit ini_restore().
Dazu muss man ungefähr wissen, wie die eingesetzten Programme zur Fehlersuche arbeiten. Diese Programme machen eine rein symantische Prüfung anhand des Quelltextes und suchen spezielle Auffälligkeiten, wie z.B. ein strcpy() oder memcpy(), also sie suchen nach bestimmten anfälligen Funktionen, gängigen Fehlern, zu kleinen Puffern, fehlenden Überprüfungen von Parameterlängen, angeforderten Ressourcen, die nicht wieder frei gegeben werden...
Diese Art der Suche hat natürlich ein paar arge Einschränkungen, so können Fehler in Codeteilen entdeckt werden, die unter Umständen gar nicht mitkompiliert werden, oder bei der Kompilierung wegfallen. Zudem können Fehler im Code entdeckt werden, die gar nicht auftreten können, z.B. weil der Fehler in einer Funktion ist, deren Parameter schon vor der Übergabe in einer anderen Funktion auf Gültigkeit überprüft werden. Zudem gibt es auch Fehler, die diese Tools gar nicht aufspüren können, weil diese Fehler z.B. in der Programmlogik selbst stecken, wie z.B. die neu entdeckte Lücke in PHP mit ini_restore().
Olaf19 xafford „wie aussagekräftig sind solche Meldungen? Dazu muss man ungefähr wissen, wie...“
Danke, das war es was ich wissen wollte. Das würde auch die große Differenz zum Ergebnis von Secunia erklären oder wenigstens plausibel erscheinen lassen.
THX
Olaf
