Der Mythos vom schnellen Patch
Die Meldungen der letzten Wochen über den Umgang mit Sicherheitslücken in Open-Source-Produkten werfen ein schlechtes Licht auf Entwickler und Distributoren. Bislang versicherten sich Open-Source-Anhänger gegenseitig die Überlegenheit ihres Entwicklungsmodells mit dem Spruch "Wenn die Lücke gemeldet wird, ist der Fix schon da." Schwachstellen würden offen diskutiert und schnellstens beseitigt -- lange bevor sie jemand ausnutzen kann. Bei Closed-Source müsse man ewig auf einen Patch warten.
Doch ein Blick hinter die Kulissen offenbart manchmal ein ganz anderes Bild. Gerade Vorzeigeprojekte wie der Linux-Kernel und der Web-Browser Mozilla behandeln Sicherheitsprobleme wie die großen Hersteller kommerzieller Software: Deckel drauf und möglichst lange nichts nach außen dringen lassen. Dennoch sickern Informationen nach draußen -- leider oft auch in die fälschen Hände. Die daraus resultierende Situation ist dann für den Anwender weitaus schlechter, als wenn man die Schwachstelle gleich öffentlich diskutiert hätte.
So auch im aktuellen Fall des uselib()-Bugs im Linux-Kernel, der zunächst nur auf der geschlossenen Mailing-Liste der Linux-Distributoren Vendor-Sec diskutiert wurde. Offenbar lasen auch Blackhats die Meldungen auf der Liste mit, unter anderem einen Proof-of-Concept-Exploit. Und während die Distributoren noch diskutierten und verschwiegen an Patches bastelten, studierten andere bereits den Exploit, mit dem man Root-Rechte auf dem Server erhält. Anwender und Administratoren bekamen von all dem nichts mit und konnten auch keine Vorsorgemaßnahmen treffen, bis jemand den Exploit öffentlich verfügbar machte. Wie viele Root-Kits in der Zwischenzeit schon heimlich installiert wurden, bleibt ungeklärt.
Das Konzept, Informationen zurückzuhalten, ist auch in den Augen von Linus Torvalds gescheitert, der sich sogar mit einer offenen, unbeschränkten Sicherheits-Mailing-Liste anfreunden könnte. Vom derzeiten Konzept würden ohnehin nur Blackhats profitieren, meint Brad Spengler vom Linux-Sicherheitsprojekt grsecurity.
Mitunter werden die Open-Source-Anwender auch gar nicht über Lücken informiert. So dokumentierte die Mozilla-Foundation beim Erscheinen von Mozilla 1.7.5 eine im Newsreader beseitigte Sicherheitslücke nicht. Erst nachdem Dritte Details darüber veröffentlichten, machten die Entwickler den Eintrag in der Fehlerdatenbank zugänglich. Mit der vollständigen Offenlegung von Lücken, auch Full Disclosure genannt, und deren schneller Behebung wollte sich die Open-Source-Gemeinde einst von den Herstellern kommerzieller Closed-Source-Software abgrenzen. Nun aber scheint es so, als würden sie in deren Fußstapfen treten: Die Revolution frisst ihre Kinder.
Ein Kommentar von Daniel Bachfeld heise Security
Klatsch, Fakten, News, Betas 5.087 Themen, 27.849 Beiträge
du mußt das relativieren!
Es ist immer noch ein erheblicher unterschied ob du als programmierer der ahnung von dem hat was er da lesen kann, bei open source den quelltext auch lesen darfst oder eben bei "kommerzieller Closed-Source-Software" nicht! (DAS war ursprünnglich mit FD genannt worden)
Der Mozilla Newsreader Bug z.b.: Full Disclosure soll doch nicht heißen, das die Leute die den Quellcode lesen können jetzt deswegen an die öffentlich keit gehen und laut rausposaunen dies und das war bisher fehlerhaft, jetzt ist es gefixt!. Weil wenn es so gemacht würde, könnten nämlich mit den veröffentlichten Infos über die Lücke die SCRIPT KIDDIES jetzt ohne eben vorher die fähigkeit zu erwerben Quellcode zu lesen/verstehen und den Bug finden und auszunutzen, die für nicht fachleute nunmehr breitgetretenen infos ausnutzen.
Mir ist ein nichtbreitgetretener Bug in Open Source lieber als bei Closed Source, weil eben bei Open Source PROGRAMMIERER überall auf der Welt als entwicklungsgemeinde am Code verbessern können.
Nehmen wir mal folgendes an:
Es gibt im so geschätzten Mozillabrowser/Geckoengine einen kapitalen Bug. Dieser fällt einem Programmierer der Open Source Community auf, dann ist der im Kreise der Programmierer auch veröffentlicht! Der muß nicht auch noch in der Computerbild auf Seite 1 stehen, solange in the wild noch soviele Buildversionen ungepatched in Gebrauch sind. Und mit breittreten werden eben die nichtwirklich fähigen Kiddies mehr als bei Open Source prinzipbedingt möglich auf die Fehler aufmerksam.
Das automatische Bugtracking System von Mozilla ist afair für jeden zur Nutzung offen.
Und deshalb gab es afair dort vor Monaten eben auch die Diskussion ob Bugs die kritisch sind eben nicht im jedermann zugänglichen Bereich behandelt werden sollen, und ob es eben dafür ne zugriffsbeschränkte Sektion geben soll.
Wegen einer "wir posaunen nicht jeden kritischen Fehler breit raus, solange in the wild soviele ungepatchte Versionen aktiv sind" Philosophie einen solchen Artikel zu verfasssen halte ich für überzogen.
Der Original Autor des Heise Artikels hat da was verwechselt wenn er derartiges Vorgehen mit "Der Mythos vom schnellen Patch" beschreibt.
Kein Seriöser Anhänger von Open Source hat behauptet das es automatisch schneller oder besser geht Fehler in Code auszumerzen als bei closed source von MS z.B.
Und dort werden kritische bugs die öffentlich bekannt sind zum beispiel teilweise auch überhaupt nicht gefixt, obwohl eben bekannt. Sowas passeirt bei OS nicht, da wird immer ein Programmierer an nem Fix basteln wenn er den Source Code hat um zu basteln
Den von Autor zitierten spruch: "Wenn die Lücke gemeldet wird, ist der Fix schon da" habe ich persönlich nicht einmal SO gehört!
Ein sehr einseitiger, sich mit den Vorteilen von Open Source nicht wirklich auseinandersetzender, von einem mutmaßlich voreingenommenen Autor geschriebener Artikel! Meiner Meinung nach.