Kommentar: Warum Freie Software kein Sicherheitsproblem darstellt

Kind mit Händen vor dem Gesicht

Bei der Diskussion um das Thema IT-Sicherheit erlebt man immer wieder, dass Freie Software als ein gesonderter Fall betrachtet wird. Oft werden Sicherheitsfehler in Freier Software fälschlicherweise dem allgemeinen Konzept der Software-Freiheit angelastet. Leider verfällt auch der Artikel „Open Source wird ein ernstes Problem“ im Handelsblatt in ein ähnliches Denkmuster. Ein Leserbrief an das Handelsblatt blieb unbeantwortet. Daher freue ich mich darüber, den Leserbrief als Gastkommentar auf netzpolitik.org veröffentlichen zu dürfen. Ich hoffe, die Veröffentlichung trägt dazu bei, dass es in Zukunft weniger solcher Missverständnisse gibt.

Dies ist ein Gastbeitrag von Björn Schießle. Björn ist stellvertretender Koordinator des deutschen Teams der Free Software Foundation Europe.

Ich war überrascht zu lesen, dass sich die Einschätzung, Freie Software (auch Open Source Software genannt) würde ein ernstes Problem für die Sicherheit darstellen, einzig und allein auf die Aussagen des Chief Security Officer von SAP stützt. Ein Unternehmen, das in den letzten Jahren nicht gerade durch seine Expertise im Bereich Freie Software auf sich aufmerksam gemacht hat. Daher wundert es mich nicht, dass ausgehend von grundsätzlich richtigen Feststellungen übereilt falsche Schlussfolgerungen gezogen werden.

Lassen Sie mich das an einem Beispiel veranschaulichen. Die Aussage, dass die Entwicklung durch Freie Software schneller und günstiger wird, ist sicher richtig. Aus wirtschaftlicher Sicht ist das einer der großen Vorteile von Freier Software. Softwareunternehmen können auf Bestehendem aufbauen. Dadurch muss nicht bei jeder Entwicklung das berühmte Rad neu erfunden werden, stattdessen kann man sich direkt auf das eigentlich Neue und Innovative konzentrieren. Unter anderem verhindert man damit, dass ähnliche Fehler wiederholt gemacht werden, stattdessen baut man auf bereits etablierte, gut getestet Bausteine auf und reduziert hierdurch sogar die Fehleranfälligkeit. Der ganz banale Schluss, dass schnellere Entwicklung zu mehr Software führt und mehr Software auch zu mehr Fehlern in Software, ist nicht überraschend. Genauso wenig sollte es aber überraschen, dass dies für jede Software gilt. Ganz unabhängig von der Lizenz. Trotzdem will am Ende wohl niemand auf die Steigerung der Produktivität durch bessere Werkzeuge, Lizenz- und Entwicklungsmodelle in der Softwareentwicklung verzichten.

Die Aussage, dass bei Freier Software niemand verantwortlich ist, Fehler zu finden und zu beheben, möchte ich ebenfalls nicht unwidersprochen stehen lassen. Eigentlich ist es hier nicht anders als bei proprietärer (unfreier) Software.

Verantwortlich ist zum einem natürlich der Entwickler. Hinter der Entwicklung von Freier Software stehen heute in den meisten Fällen Unternehmen. Hierfür muss man sich nur die Liste der Linux-Kernel Entwickler und deren Firmenzugehörigkeit einmal anschauen. Zum anderen sind Unternehmen in der Verantwortung, die Freie Software vertreiben. Hierzu gehören zum Beispiel RedHat, Canonical oder SuSE, um nur ein paar zu nennen. Nicht zuletzt ist aber auch derjenige, der die Software einsetzt, in der Verantwortung, die Qualität und Sicherheit der eingesetzten Komponenten zu überprüfen. Unter den Unternehmen, welche Freie Software einsetzen, findet man Namen wie Amazon, Facebook und Google. Diese Firmen haben große Abteilungen, welche sich ausschließlich mit der Sicherheit der eingesetzten Software beschäftigen. Dank Freier Software kommt deren Arbeit auch kleinen Unternehmen wieder zugute, welche sich keine eigene Sicherheitsabteilung leisten können. Gerade für Unternehmen, die sich keine eigene Sicherheitsabteilung leisten können, gilt: Ohne die Vereinbarung von Service Level Agreements mit einem entsprechenden Anbieter kann man letztlich die Verantwortung nicht auf andere abwälzen. Solche Vereinbarungen sind beim Einsatz von proprietärer Software von Drittanbietern selbstverständlich. Ist man nicht bereit, die Verantwortung selber zu tragen, dann sollte man an dem Punkt auch nicht beim Einsatz von Freier Software sparen.

Eine lückenlose Überprüfung von einzelnen Komponenten, welche nicht selber entwickelt wurden, stellt heute die größte Herausforderung dar, egal ob ein Unternehmen auf Freie-Software-Komponenten aufbaut oder proprietäre Komponenten von Drittanbietern einkauft. Freie Software hat an dieser Stelle vor allem zwei Vorteile. Dadurch, dass man nicht der einzige ist, der diese Software einsetzt, erhöht sich die Wahrscheinlichkeit, dass möglichst zeitnah Fehler auch wirklich entdeckt werden. Ein weiterer wichtiger Vorteil ist, dass man bei Freier Software oft sehr viel besser nachvollziehen kann, wer welchen Programmcode eingebracht hat. Gerade moderne Entwicklerplattformen wie zum Beispiel GitHub machen dies sehr einfach. Eine Transparenz, wie man sie bei proprietärer Software meist vergeblich sucht.

Auch zeigt Freie Software seine Stärke gerade, nachdem eine Sicherheitslücke – wie aktuell DROWN – entdeckt wurde. Eine solche Entdeckung gerät bei Freier Software meist sehr schnell an die Öffentlichkeit, während Sicherheitslücken bei proprietärer Software oft eher verheimlicht werden, um dem Unternehmen nicht zu schaden. Die Art, wie es bei Freier Software gehandhabt wird, hat zwei positive Effekte. Zum einen bietet es Kriminellen weniger Spielraum, die Sicherheitslücke auf dem Schwarzmarkt zu vermarkten und auszunutzen. Zum anderen können verschiedene Parteien unabhängig den Fehler beheben und entsprechende Sicherheitsvorkehrungen treffen, während man bei proprietärer Software nur warten kann, bis der Hersteller den Fehler behebt und ein Update ausliefert.

Dass dieses System gut funktioniert, haben wir bei Heartbleed gesehen. Diese Sicherheitslücke wurde unter anderem von Google, welches selbst viel Freie Software einsetzt, entdeckt und behoben, und dann umgehend der Öffentlichkeit zugänglich gemacht. Heartbleed hat auch zur Gründung der „Core Infrastructure Initiative“ geführt, welche sehr viel Geld in Projekte investiert, die die Sicherheit von Freier Software erhöhen.

Abschließend lässt sich festhalten, dass Freie Software zwar nicht zwingend sicherer ist als proprietäre Software. Die Freiheit der Software – also die Möglichkeit diese für jeden Zweck zu verwenden, zu untersuchen, weiterzugeben und abzuändern – stellt aber eine notwendige Bedingung für Sicherheit dar. Man kann sich das wie bei einem Türschloss vorstellen. Jeder weiß wie ein solches Schloss aufgebaut ist. Viele unabhängige Experten konnten über viele Jahre das Konzept untersuchen und verbessern. Nur so war es möglich, sichere Schlösser zu entwickeln. Durch Geheimhaltung wurde noch nie langfristig und nachhaltig Sicherheit erzielt.

Deine Spende für digitale Freiheitsrechte

Wir berichten über aktuelle netzpolitische Entwicklungen, decken Skandale auf und stoßen Debatten an. Dabei sind wir vollkommen unabhängig. Denn unser Kampf für digitale Freiheitsrechte finanziert sich zu fast 100 Prozent aus den Spenden unserer Leser:innen.

26 Ergänzungen

  1. Hm, ist jetzt freie Software vergleichbar mit einem ABUS Türschloss?
    Wenn ja, mit welcher Sicherheitsstufe?
    Klingt ein wenig blöd die Frage, aber ich bin interessiert und habe wenig Ahnung von den IT technischen Begriffen. Ich fand die Darstellung mit dem Schlüssel bei dieser Schlüsseltechnologie als sehr hilfreich.
    Lieben Gruß SUSI

    1. Diese Art, zu fragen kenne ich eigentlich nur von Juristen oder Diplomsoziologen.
      Mithin also von Personen, die ihr Handicap zur Berufung gemacht haben.

  2. Das Problem wird leider sein, dass die Adressaten des Handelsblattes vermutlich nicht bei Netzpolitik nachlesen – und dass sie dann eher dem Qualitätsjournalisten Postinett auf den Leim gehen ..

    Es ist doch vollkommen grotesk, proprietärer Software gerade im Bereich der Sicherheit irgendwelche Vorteile andichten zu wollen! Gerade wenn es z.B. um Verschlüsselung geht, ist proprietäre Software nur eins: Lächerlich!

    Für meinen Geschmack geht der Antwort-Brief zu sehr auf Details ein, der die Handelsblatt-Adressaten schnell aussteigen lässt. Denn diejenigen, die diesen Brief verstehen, die kennen das Problem und die muss man nicht mehr überzeugen. Es geht um die oberflächlichen, IT-fernen Entscheider – und die muss man vermutlich mit kurzen unlösbaren Widersprüchen konfrontieren, wie z.B. dem RSA-Beispiel: „Wer (viel) bezahlt, wird beschissen und kann sich nicht wehren. Wer freie Software nutzt, hat die Auswahl und wird sogar noch vor ‚übel riechenden‘ Varianten gewarnt!“

    Man sollte dem Handelsblatt und Herrn Postinett die Sicherheitsrealität der Firma „RSA Security Inc.“ immer und immer wieder aufs Brot schmieren, wenn die mit solchen Märchen anfangen! Und man sollte sie konkret fragen, mit welchen Voodoo-Fähigkeiten sie den Binärdateien ansehen wollen, ob sich da nun Backdoors oder üble Programmierfehler verbergen. Denn sie werden garantiert niemals die Chance bekommen, den Quellcode von unabhängiger Seite prüfen zu lassen und müssen sich blind auf die Loyalität der Anbieter verlassen – die im proprietären Modell Kundenzufriedenheit und dessen Sicherheitsinteressen vollkommen unabhängig von den eigenen Profit-Interessen priorisieren können ..

    1. Ich finde es schon wichtig, dass eine solche Replik notfalls auch an dieser Stelle veröffentlicht wird. Denn was der Mensch getrennt hat, fügt die Suchmaschine wieder zusammen. Schöner wäre es natürlich gewesen, der sogenannte Qualitätsjournalismus hätte sich getraut, ein Widerwort zuzulassen.

      Auch die Sorgfalt der Argumentation spricht nicht gegen diese Replik. Zwar ist das, was dort angeführt wird, altbekannt, aber offensichtlich nicht jedem. Und dass IT-Entscheider Informationen nur in Häppchenform zu sich nehmen, kann ich nicht glauben. Und wenn nur die Entscheider überzeugt werden, die insoweit eben anders sind, als der „durchschnittliche“ IT-Entscheider, hat sich diese Mühe gelohnt.

      Schlagworte kann jeder, wir bringen Argumente!

  3. Es gab Zeiten, da verkaufte SAP (Ständig Andere Probleme) mehr Probleme als die Firma beseitigen konnte. Es stellte sich die Frage, ob man eine Business Intelligence Strategy habe und diese klug anwenden könne, zumal die Zukunft von SAP (submit and pray) gesichert werden sollte.

    Nomen est Omen, dachten sich kluge Köpfe, und kauften TomorrowNow im Land der unbeschränkten Möglichkeiten. Im zurückliegenden Hier und Jetzt klickte dann ein noch klügerer Finger bei Oracle auf Download, was man hier
    https://en.wikipedia.org/wiki/Oracle_Corporation_v._SAP_AG#Background
    kurz und unterhaltsam nachlesen kann. Für gesteigerte Lust sei an dieser Stelle das händische Visualisieren der Zahlen mit den vielen Nullen auf Büttenpapier anempfohlen.

    Mit freia Softwehr wär des net passiert. Aber mia kännet älles ausser … ?

    1. SAP hat auch schon mal ein DBMS an die Open Source Community übereignet, lass mal die Kirche im Dorf. SAP Software ist halt ein Bastelkit, wer es beschafft weiss eigentlich, was er sich antut.

  4. Das Problem ist nicht Free bzw. Closed Source. Sondern viel eher das was dahinter steht. Es geht im Grunde um Vertrauen. Sprich, vertraue ich der Quelle, mit wem habe ich es zu tun.

    OpenSource ist ein wahrhaft toller Gedanke. Frei, offen, kontrolliert durch alle. In der Praxis reicht es oftmals aus das etwas OS ist um Vertrauen herzustellen. Die Möglichkeiten der Kontrolle werden so gut wie nicht genutzt. Heartbleed und Konsorten haben uns das dramatisch vor Augen geführt.

    Auf der anderen Seite ist natürlich Closed-Source auch nicht per se Vertrauenswürdig.

    1. > In der Praxis reicht es oftmals aus das etwas OS ist um Vertrauen herzustellen. (sic)!
      Uuups!

      Vertrauen in Software kann nur durch OpenSource entstehen, weil unmittelbare Kontrolle möglich ist.
      Ein Vertrauen in proprietäre Software ist direkt faktisch nicht möglich, denn hier kann lediglich eine Anleihe auf die Reputation des Herstellers oder der Handelsmarke genommen werden.

      Heartbleed wird oft als Argument gegen OpenSource angeführt. Dabei hat gerade dieses Beispiel gezeigt wie effizient OpenSource funktioniert. Ein Fehler wurde von Dritten gefunden und dann sehr schnell beseitigt. Ein ähnlicher Fehler müsste bei proprietärer Software vom Hersteller selbst gefunden werden.

      Heartbleed löste in der OpenSource community ein verstärktes Problembewusstsein aus, das zu verstärkten Code-reviews vor allem bei sicherheitsrelevanten libraries führte und auch weiterhin anhält.

      Zu vergleichbaren Bemühungen in der geschlossenen Welt kann man nur bemerken: Dann macht mal schön, und übrigens noch viel Erfolg dabei!

      Security by obscurity hat nur eine sehr beschränkte Reichweite. Dies trifft auch für Bugfixes zu. Selbst in namhaften Softwareschmieden besteht gelegentlich die Neigung ernste Sicherheitsmängel dem Kunden zu verschweigen, weil die öffentliche Kontrolle fehlt.
      Minor Bugfixes umfasst dann auch schwere Bugs, die vor den Kunden verheimlicht werden. Geschlossene Gesellschaften züchten geradezu Mentalitäten, wie wir sie bei VW kennengelernt haben (der vorsätzliche Betrug ist hier ausdrücklich NICHT gemeint).

      1. Ja, und es kommt vor, dass eine gewisse Firma per Lizenz und Vertrag seinem IDS-Hersteller verbietet was zu finden, weil ein bekannter Fehler in der Software schon seit einem Jahr besteht bedeuten würde dass die Software Fehler hätte. Und damit ein Sicherheitsproblem.
        Also wird der Fehler von Sicherheitssystemen nicht „gefunden“, und vom Anbieter des anderen Systems nicht behoben. Bleibt aber erst mal bestehen.

    2. Der Vorteil bei Open Source ist, dass ich einen patch selbst einspielen kann, egal was irgendwer dazu meint oder liefert.

  5. Software kann in Netzwerken unabhängig vom Hersteller zum Problem werden. Meinen ersten Showdown hatte ich mit dem Sendmail-Programm von Sun Microsystems in SunOS und Digital Equipment in Ultrix (beides kommerzielle Firmen, für die jüngeren, die die nicht mehr kennen) im Jahre 1988, als der Sohn des NSA-Mitarbeiters Morris ein prächtigen Wurm schrieb, den er aus dem Labor seine Informatikstudiums in das damalige Internet entließ, dass innerhalb von 245 Stunden dahin schmolz. Morris flog von der Uni, ist aber heute promoviert.
    Der Detlef Borchers war so nett, für Heise 2013 an das 25-jährige Jubiläum dieses tödlichen Exploits kommerzieller Software zu erinnern.
    http://www.heise.de/ix/artikel/Vertreibung-aus-dem-Paradies-1981722.html
    Hartbleed war zwar eine Enttäuschung dahingehend, dass bei Open Source auch nicht zu viele Menschen den Code prüfe, aber die Reparatur war einfacher als mit kommerziellem Code.
    Letzlich ist Software in die Mitte der Gesellschaft gekommen, so wie der TÜV im 19. Jahrhundert kam, als zu viele Dampfkesselanlagen den Bürgern um die Ohren flogen (was im heutigen Sprachgebrauch Peanuts waren, wenn man sie mit Fukushima, Three Miles Island oder Tschernobyl vergleicht).
    Der Handelsblatt-Autor hätte ruhig etwas mehr recherchieren können statt schräge Überschriften zu verwenden.

  6. Danke für Euren aufschlußreichen Artikel. Aber auch ich bin in technischer Hinsicht nicht gerade eine Könnerin. Diese freie Software, wie von Euch beschrieben, könnte sicher ein Nutzen für die User sein. Aber ich habe große Bedenken, daß Regierungen zusammen mit Konzernen diesen Status ausnutzen. Aber wenn ich es richtig verstanden habe, können sie dies natürlich dann auch noch, so wie bisher auch schon. Diese Manipulationen könnten dann aber möglicherweise auch leichter aufgedeckt werden.

    1. Du sagst es genau richtig. Bei Freier Software kann in vielen Fällen jede einzelne der tausenden Codezeilen einem Autor zugeordnet werden und die Änderungschronik lückenlos nachvollzogen werden. Bei proprietärer (unfreier) Software kann die Allgemeinheit nichts nachvollziehen, alles ist im Dunklen. So können ungewollte Änderungen auch gar nicht erst unabhängig gesucht und entdeckt werden.

    2. Sowohl Regierungen als auch Konzerne können sich an Freier Software bedienen. Das ist sogar insoweit gewollt, dass „jedermann“ wirklich „alle“ bedeutet.

      Aber Regierungen können Freie Software nur bei ahnungslosen Nutzern als trojanisches Pferd missbrauchen. Gute Distributionen erzeugen nämlich nachvollziehbare Verantwortlichkeit durch Offenlegung des gesamten Quellcodes, durch kryptografische Methoden wie Hashes und Signaturen und neuerdings auch beispielsweise durch „reproducible builds“.

      Das Vertrauen der Anwender ist nämlich die Basis der Arbeit der Freien-Software-Gemeinschaft und man tut alles, dass dieses Vertrauen auf einer möglichst weitgehenden Kontrolle durch die Anwender basieren kann.

      Und natürlich kontrolliert man sich auch gegenseitig.

    3. Die Regierungen mit den Konzernen benutzen in der Vergangenheit und jetzt NICHT FREIE Software um die Menschen zu bespitzeln.
      Die machen da keinen halt.
      Nur weil Snowden das der Welt erzählt hat hören die ja nicht auf.
      Deshalb kann man nur mit eigen Initiative entgegen halten.

  7. Heutzutage wird von freier Software weggeschwenkt hin zu „da ist keine Firma dahinter“. und da wirklich wenig bis keine Firmen auf Linux/für Linux software schreiben, hilft das alles nicht. Firmen und Behörden wollen eine Firma als Ansprechpartner und notfalls als Schuldigen haben. Inhouse will man das nicht stemmen.

    und dann redhat nehmen, macht es auch nicht besser. es gibt zuwenige fachanwendungen. leider.
    fragt mich gerne dazu aus, ich weiss leider bescheid…

    1. Ja genau, weil die ganze Kompetenz aus dem billigen Ausland dazu gekauft wird. IT darf nichts kosten.
      Da geht es nur um Juristisches, nicht um echte Ahnung von der Materie.

      Das hat genau genommen mit OpenSource nicht mal was zu tun. Nur um die Verantwortlichen geht das hier. Und da die Entscheidungsträger nirgends und überhaupt keine Ahnung haben, lassen sie sich von der Lobby beraten.
      Und wenn was schief geht, dann haben die so viel Geld gemacht, dass man sich erst einen teuren Gerichtsstreit leisten kann, und danach noch die „Garantie“ erfüllen kann.
      Da wird ein Mist getrieben Leute! Und der Dumme zahlt das.

  8. Ja, den „Beitrag“ über die Sicherheit und OpenSource habe ich auch glesen.
    Klar wird das so eingestuft, da verdient ein M$SAPler ja nichts mehr. Das genaue GEGENTEIL ist ja wohl eher der Fall!
    Wer keine Ahnung hat, NICHT den Lobbyisten glauben! Linux ist ja jetzt eher sicher als M$.
    Fast auf jedem Handy/Router/Set-top Box läuft es. Und durch die Menge an Programmieren werden Fehler eher schneller als bei den Kommerziellen behoben.
    Wenn ich mir in meiner Täglichen Arbeit die Scheße mit der Closed-Source Software ansehe!!!! und dafür bezahlt überhaupt wer? Sicherheitssysteme deren Nutzer „Admin“ ist, und das Passwort auch?! Dafür zahlt wer? Systeme, die einen offenen Telnet-Port „einprogrammiert“ haben? Und wo das läuft wollt ihr nicht wissen. Lizenzen um die 1000€ für Sicherheitsrelevantes Zeug.
    Da ist mir mein OpenSource schon lieber.

    „4 Augen sehen mehr als 2“ heißt es doch. Und genau das ist die Stärke.

  9. Theoretisch ist es ja richtig, dass ich den Code kontrollieren kann und somit sicherstellen kann, dass keine Hintertüren eingebaut wurden. Theoretisch. Aber wenn ich mir überlege, wie viele Zeilen Code ich tagtäglich in Form der Programme, die ich starte, nutze, dann ist das für mich alleine unmöglich.
    Klar, man könnte sich das jetzt aufteilen und wenn ich ein Programm durchgesehen habe, „zertifiziere“ ich es, aber das ist dann so vertrauenswürdig wie ein Zertifikat bei einem Closed Source Projekt. Vielleicht sogar weniger.
    Jetzt gehen wir mal davon aus, dass das Code durchsehen kein Problem ist, dann müsste ich theoretisch den Sourcecode herunterladen und diesen selbst kompilieren. Das kann man machen, aber mal ehrlich, wer tut das in 100% der Fälle? Ob ich mir die Binarys eines Open, oder Closed Source Projekt lade macht keinen Unterschied. Ich muss vertrauen.

    Ich habe nichts gegen Freie Software, ganz im Gegenteil. Aus Entwicklersicht ist es toll Tools nutzen und anpassen zu können und diese nicht selbst schreiben zu müssen. Aber der Sicherheitsvorteil ist nur durch extremen Aufwand und Knowhow gegeben. Das ist leider ziemlich praxisfern.

    1. Wenn Du davon ausgehst, daß nur DU das machst/machen sollst, ist deine Annahme sicher berechtigt. Ist es aber nicht eher so, daß es dann viele sind, die sich darum kümmern? Sicher kommt es dabei zu Überschneidungen und damit auch zu Verschwendung an Arbeit. Aber genau das bedeutet auch wieder Sicherheit, weil vier Augen…
      Das gibt sicher nicht die „absolute“ Sicherheit. Die wird es aber nie und nirgendwo geben. Das sollte aber nie der Grund sein, die Flinte in den Korn zu werfen.
      Ich traue jedenfalls dem öffentlichen Kram mehr, als dem Geheimen. Das extrapoliere ich einfach aus meinem Handwerk. Tolle Produkte, wo sich Hersteller und Entwickler zu bedeckt halten, treten da hinter denen zurück, bei denen man entweder gleich Volldeklarationen liefert oder man zumindest fruchtbare Gespräche mit der Entwicklungsabteilung führen kann.

  10. Ich bin ein großer Fan von Verschwörungstheorien. Aber die Dichotomie freie vs. unfreie Software eignet sich nicht dafür. Wenn wir hier im Internet uns austauschen können, dann ist das eine Folge davon, dass die US-Regierung bei der Privatwirtschaft die TCP/IP beauftragt hatte. Und den USA ist es nun mal üblich, dass öffentlich bezahlte Forschungsprodukte (im Bund) in die Public Domain müssen. So kann seit den frühen achtigziern jeder Commercial aber auch die Linux-Community den TCP/IP-Code frei nutzen. Schon damals konnte man in der Regel nicht nachvollziehen, wer welchen Code im Einzelnen geschrieben hatte.
    Software wie Auto fahren: meistens geht es gut, manchmal hat man ein Problem.
    Dabei ist dann egal, ob man einen VW mit manipulierter Abgeassoftware hat oder sein Fahrzeug mit Open Source aus dem 3D-Drucker selbst gedruckt hat zu Grenzkosten von fast Null.
    Von daher war auch die einseitige Auslegung in der Zeitung eher unsachlich.

  11. @Stephan
    zitat:
    „Aber wenn ich mir überlege, wie viele Zeilen Code ich tagtäglich in Form der Programme, die ich starte, nutze ( … )“

    volle zustimmung.

    als beispiel möchte ich libreoffice ( userspace ) anführen. alleine das compilieren auf einer ( !!! ) sehr fein abgestimmten ( gentoo ) 64bit-maschine mit acht kernen kann bis zu drei stunden dauern ( ohne ccache und compiler-verteilung auf zusätzliche maschinen innerhalb des local networks ), will heissen, der source-code ist… riesig.

    eine lücke, obwohl der source-code sehr struktiert ist, zu entdecken… nicht möglich.

    der kernel, also linux, wiederum obwohl inzwischen auch ein riesen biest, wird sehr wohl auf lücken ( händisch ) geprüft.

    folgende strategie wird, nicht nur auf libreoffice bezogen, angewandt:

    zunächst wird z. b. tripwire und/oder auch rkhunter, ebenfalls händisch geprüft, auf dem o. a. rechner installiert und die ergebnisse ausgewertet.

    eine dedizierte ( reine ) firewall wiederum beobachtet, resp. sperrt nicht authorisierte aus- und eingehende pakete.

    diese werden wiederum ausgewertet.

    auch werden stress-tests mit z. b. kali linux auf diese maschine angesetzt, die wiederum ausgewertet werden.

    dies kostet zeit sowohl rechner- als auch lebenszeit.

    sobald jedoch einer oder mehrere „exploit“ erkannt werden, wird den verantwortlichen maintainer/Innen die dementsprechende info gegeben.

    will heissen. natürlich gibt es unter opensource sicherheitslücken. jedoch werden sie nach dem erkennen um einiges schneller geschlossen als bei closedsource basierten maschinen.

    1. Der für mich wesentliche Punkt ist, dass Freie Software eben die vier Freiheiten bietet. Proprietäre tut das nicht und bietet darüber hinaus keinen Mehrwert. Damit ist die Entscheidung ganz klar.
      Und Open Source ist nicht Freie Software, vergleicht einfach mal was die FSF an Lizenzen anerkennt und was die OSI als Open Source anerkennt. Es gibt Überschneidungen, aber keine Identität zwischen den beiden Mengen.

  12. Hi,

    Warum wird eigentlich nicht Kritik am SAP CSO geübt. Das aktuelle Hauptprodukt ist SAP R/3 ECC 6.0. Man kann man mit einem „/h“ alles im Quelltext lesen, sofern man eine Debugging Berechtigung für seinen User besitzt. Mit der Transaktion „SE38“ kann man ALLES!!! im Quelltext nachlesen.

    Der Quelltext ist somit propietär lizenziert, aber IMMER offen lesbar. Also SAP würde das Sicherheitsproblem welches der SAP CSO openSSL unterstellt ja genauso betreffen.

    Im ganzen muss man aber sagen. Im Handelsblatt werden Meinungen und Marketing-Spins von Wirtschaftsunternehmen abgedruckt und als unabhängiger Journalismus verkauft. Dann darf man sich auch nicht wundern wenn man auch die Meinung der propietären Firmen dort liest.

    lg

Dieser Artikel ist älter als ein Jahr, daher sind die Ergänzungen geschlossen.