it-swarm-eu.dev

Open Source vs Closed Source Systeme

Mein Verständnis ist, dass Open Source-Systeme allgemein als sicherer angesehen werden als Closed Source-Systeme .

Gründe für einen Ansatz oder eine Kombination davon sind: kulturelle Normen, finanzielle, rechtliche Positionierung, nationale Sicherheit usw. - all dies hängt in gewisser Weise mit der Ansicht der Kultur über die Auswirkungen einer offenen oder geschlossenen Quelle dieses Systems zusammen.

Eines der Hauptanliegen ist die Sicherheit. Eine gängige Position gegen Open Source-Systeme ist, dass ein Angreifer Schwachstellen im System ausnutzen kann, wenn dies bekannt ist. Ein allgemeiner Standpunkt gegen Closed-Source-Systeme ist, dass mangelndes Bewusstsein bestenfalls eine schwache Sicherheitsmaßnahme ist. allgemein bezeichnet als Sicherheit durch Dunkelheit .

Die Frage ist, ob Open Source-Systeme im Durchschnitt sicherer sind als Closed Source-Systeme. Wenn möglich, zitieren Sie bitte Analysen in so vielen Branchen wie möglich, zum Beispiel: Software , Militär , Finanzmärkte usw.

Diese Frage war IT-Sicherheitsfrage der Woche .
Lesen Sie den 25. Mai 2012 Blogeintrag für weitere Details oder eigene einreichen Frage der Woche.

53
blunders

Die Vorstellung, dass Open-Source-Software von Natur aus sicherer ist als Closed-Source-Software - oder die entgegengesetzte Vorstellung - , ist Unsinn. Und wenn Leute so etwas sagen es ist oft nur FUD und treibt die Diskussion nicht sinnvoll voran.

Um dies zu begründen , müssen Sie die Diskussion auf ein spezifisches Projekt beschränken. Eine Software, die einen bestimmten Juckreiz kratzt, von einem bestimmten Team erstellt wird und eine genau definierte Zielgruppe hat. In einem solchen speziellen Fall kann möglicherweise überlegt werden, ob Open Source oder Closed Source dem Projekt am besten dienen.

Das Problem beim Pitching aller "Open Source" - gegenüber allen "Closed Source" -Implementierungen besteht darin, dass man nicht nur Lizenzen vergleicht. In der Praxis ist Open Source Begünstigt durch freiwillige Bemühungen, und geschlossene Quellen sind bei kommerziellen Bemühungen am verbreitetsten. Also vergleichen wir tatsächlich:

  • Lizenzen.
  • Zugriff auf den Quellcode.
  • Ganz anders Anreizstrukturen , gewinnorientiert versus zum Spaß.
  • Sehr unterschiedliche rechtliche Haftungssituationen.
  • Unterschiedliche und sehr unterschiedliche Teamgrößen und Teamfähigkeiten.
  • usw.

Der Versuch zu beurteilen, wie all dies für die Sicherheit aller als Open/Closed Source veröffentlichten Software funktioniert, bricht einfach zusammen. Es wird eine Meinungsäußerung, keine Tatsache.

50
Jesper M

Gepflegt Software ist sicherer als Software, die es nicht ist. Der Wartungsaufwand hängt natürlich von der Komplexität der Software und der Anzahl (und den Fähigkeiten) der Personen ab, die sie betrachten. Die Theorie hinter OpenSource-Systemen, die sicherer sind, ist, dass es "viele Augen" gibt, die den Quellcode betrachten. Dies hängt jedoch stark von der Beliebtheit des Systems ab.

Beispielsweise wurden 2008 in OpenSSL mehrere Pufferüberläufe entdeckt, von denen einige zur Remotecodeausführung führten. Diese Fehler lagen seit mehreren Jahren im Code. Obwohl OpenSSL OpenSource war und eine beträchtliche Benutzerbasis hatte (dies ist schließlich die Haupt-SSL-Bibliothek, die für HTTPS-Websites verwendet wird), reichte die Anzahl und Geschicklichkeit der Quellcode-Auditoren nicht aus, um sie zu überwinden die inhärente Komplexität der ASN.1-Decodierung (der Teil von OpenSSL, in dem die Fehler lauerten) und des OpenSSL-Quellcodes (ehrlich gesagt ist dies nicht der am besten lesbare C-Quellcode aller Zeiten).

Closed-Source-Systeme haben im Durchschnitt, viel weniger Leute, die Fragen und Antworten geben. Viele Closed-Source-Systeme haben jedoch bezahlt Entwickler und Tester, die sich ganztägig für den Job engagieren können. Dies ist der offenen/geschlossenen Frage nicht wirklich inhärent; Einige Unternehmen beschäftigen Mitarbeiter für die Entwicklung von OpenSource-Systemen, und es ist denkbar, dass eine Closed-Source-Software kostenlos erstellt wird (dies ist im Fall von "Freewares" für Windows relativ häufig). Es besteht jedoch immer noch eine starke Korrelation zwischen bezahlten Testern und geschlossener Quelle (Korrelation impliziert keine Kausalität, dies bedeutet jedoch nicht, dass Korrelationen ebenfalls ignoriert werden sollten).

Auf der anderen Seite macht es Closed Source einfacher, Sicherheitsprobleme zu verbergen, was natürlich schlecht ist.

Es gibt Beispiele für Open- und Closed-Source-Systeme mit vielen oder sehr wenigen Sicherheitsproblemen. Die OpenSource * BSD-Betriebssysteme ( FreeBSD , NetBSD und OpenBSD und einige andere) haben eine sehr gute Erfolgsbilanz in Bezug auf die Sicherheit. Dies gilt auch für Solaris, selbst wenn es sich um ein Closed-Source-Betriebssystem handelte. Andererseits hat Windows in dieser Angelegenheit einen schrecklichen Ruf.

Zusammenfassung: Meiner Meinung nach wird die Idee "OpenSource impliziert Sicherheit" überbewertet. Was wichtig ist, ist die Zeit (und die Fähigkeit), die für die Verfolgung und Behebung von Sicherheitsproblemen aufgewendet wird, und dies ist meistens orthogonal zur Frage der Offenheit der Quelle. Allerdings, Sie wollen nicht nur ein sicheres System, Sie wollen auch ein System, das Sie positiv wissen sicher sein (nicht eingebrochen zu werden ist wichtig, aber in der Lage zu sein auch nachts schlafen). Für diese Rolle haben OpenSource-Systeme einen kleinen Vorteil: Es ist einfacher zu überzeugen, dass es keine absichtlich verborgene Sicherheitslücke gibt, wenn das System OpenSource ist. Aber Vertrauen ist eine fliegende Sache, wie die jüngste Tragikomödie um die angebliche Hintertüren in OpenBSD gezeigt hat (soweit ich weiß, stellte sich heraus, dass es sich um einen roten Hering handelt, aber konzeptionell kann ich es nicht sein sicher, es sei denn, ich überprüfe den Code selbst).

37
Thomas Pornin

Ich denke, die einfachste und einfachste Einstellung dazu ist die Softwareentwicklung. Das Argument lautet normalerweise: Open Source Software ist sicherer, weil Sie siehe Quelle!

Haben Sie das Software-Engineering-Wissen, um den Kernel von oben nach unten zu verstehen? Sicher, Sie können sich einen solchen Treiber ansehen, aber wissen Sie genau, was wirklich gesagt wird: "Ah ja, da muss ein Fehler sein"?

Hier ist ein interessantes Beispiel: Vor nicht allzu langer Zeit ist in einem der Beta-Kernel ein Null-Zeiger-Dereferenzierungsfehler aufgetreten, der eine ziemlich große Sache war, die der Typ von grsecurity (PaX-Patches) entdeckt hat:

Es wurde in einem Code wie diesem eingeführt:

pointer = struct->otherptr;

if ( pointer == NULL )
{
    /* error handling */
}

/* code continues, dereferencing that pointer
   which with the check optimised out, can be NULL. Problem. */

und der pointer == NULL check wurde vom Compiler zu Recht optimiert - da ein Nullzeiger nicht auf eine Struktur mit Mitgliedern dereferenziert werden kann, macht es keinen Sinn, dass der Zeiger in der Funktion jemals null ist. Der Compiler entfernt dann die Prüfung, die der Entwickler erwartet hat.

Ergo sieht der Quellcode für ein so großes Projekt zwar korrekt aus - ist es aber eigentlich nicht.

Das Problem ist der Wissensstand, der hier benötigt wird. Sie müssen nicht nur mit (in diesem Fall) C, Assembly, dem jeweiligen Kernel-Subsystem und allem, was mit der Entwicklung von Kerneln einhergeht, ziemlich vertraut sein, sondern auch verstehen, was Ihr Compiler tut.

Versteh mich nicht falsch, ich stimme Linus zu, dass mit genügend Augen alle Käfer flach sind. Das Problem ist das Wissen im Gehirn hinter den Augen. Wenn Sie 30 Whiz Kids für die Entwicklung Ihres Produkts bezahlen, Ihr Open-Source-Projekt jedoch nur 5 Personen hat, die die Codebasis wirklich kennen, ist die Wahrscheinlichkeit, dass die Closed-Source-Version weniger Fehler enthält, bei einer relativ ähnlichen Komplexität eindeutig höher .

Dies gilt natürlich auch für jedes Projekt, das im Laufe der Zeit vorübergehend ist, wie Thomas Pornin erläutert.

Update bearbeitet, um Verweise darauf zu entfernen, dass gcc falsch ist, da dies nicht der Fall war.

17
user2213

Ich denke, die Prämissen, die am häufigsten zur Unterscheidung zwischen Closed und Open Source verwendet werden, sind ziemlich gut definiert. Viele davon sind hier aufgelistet, beide haben ihre Befürworter. Es überrascht nicht, dass die Befürworter von Closed Source diejenigen sind, die es verkaufen. Die Befürworter von Open Source haben es auch zu einem netten und ordentlichen Geschäft gemacht (abgesehen von einigen wenigen, die es als Religion angenommen haben).

Die Pro Open Source-Bewegung spricht die Grundlagen an, und wenn es um Sicherheit im Allgemeinen geht, sind hier die Punkte, die am besten in die Diskussion passen:

  1. Die Prämisse der Anpassung
  2. Die Lizenzverwaltungsvoraussetzung
  3. Die Open Format-Prämisse
  4. Die Prämisse von Many Eyes
  5. Die Quick Fix-Prämisse

Ich denke, die letzten beiden wurden von anderen hier ziemlich prägnant behandelt, also werde ich sie in Ruhe lassen.

  1. Die Anpassungsvoraussetzung
    In Bezug auf die Sicherheit bietet die Customization Premise Unternehmen, die die Software übernehmen, die Möglichkeit, zusätzliche Sicherheitskontrollen auf einer vorhandenen Plattform zu erstellen, ohne eine Lizenz sichern oder einen Anbieter zur Reparatur überreden zu müssen etwas von ihnen. Es befähigt Unternehmen, die eine Lücke sehen müssen oder sehen, um die Gesamtsicherheit eines Produkts zu erhöhen. SELinux ist ein perfektes Beispiel. Sie können dem NSA) dafür danken, dass er dies der Community zurückgegeben hat.

  2. Die Lizenzverwaltungsvoraussetzung
    Oft wird darauf hingewiesen, dass Sie bei Verwendung von F/OSS-Technologien keine Technologielizenzen mit Dritten verwalten müssen (oder wenn Sie dies tun, ist dies weitaus weniger.), Und dies kann für vollständig Open gelten Quellökosysteme. Viele Lizenzen (insbesondere die GPL) stellen jedoch Anforderungen an Distributoren, und die meisten realen Umgebungen sind heterogene Mischungen von Closed- und Open Source-Technologien. Während dies letztendlich die Softwareausgaben senkt, kann die Verfügbarkeit der Quelle dazu führen, dass einige Unternehmen OSS-Lizenzen verletzen, indem sie die Quelle privat halten, wenn sie verpflichtet sind, die Quelle freizugeben. Dies kann letztendlich die Prämisse des Lizenzmanagements in eine Haftung verwandeln (dies ist das Closed-Source-Argument gegen Lizenzen wie die GPL.)

  3. The Open Format Premise
    Dies ist eine große Sache, der ich eher zustimme, also werde ich mich kurz fassen, um nicht zu predigen. In 30 Jahren möchte ich eine Datei öffnen können, die ich geschrieben habe. Wenn die Datei mit proprietären DRM-Steuerelementen "geschützt" ist und die Software, auf die ich zugreifen muss, nicht mehr verkauft wird, hat die Schwierigkeit beim Zugriff auf meine eigenen Inhalte dramatisch zugenommen. Wenn es ein Format gibt, das zum Erstellen meines Dokuments verwendet wird, das offen ist und in einem Open Source-Produkt von vor 30 Jahren verfügbar ist, kann ich es wahrscheinlich finden und legal verwenden. Einige Unternehmen springen auf den Bandwagen "Open Formats", ohne auf den Open Source-Bandwagen zu springen, daher halte ich dieses Argument für ziemlich gut.

Es gibt eine Sechste Prämisse, die ich nicht aufgelistet habe, weil sie nicht gut diskutiert wird. Ich neige dazu, daran festzuhalten (nenne es Paranoia). Ich denke, die sechste Prämisse ist die Feder in der Kappe der Verteidigungsabteilungen auf der ganzen Welt. Es wurde der Welt geschrieben, als ein Teil der Windows 2000-Quelle durchgesickert war.

Die Prämisse der Haftung für geschlossene Quellen
Wenn ein Unternehmen im Laufe der Jahrzehnte über mehrere Releases hinweg eine geschlossene Quellcodebibliothek oder API erstellt hat, hatten kleine Gruppen von Einzelpersonen während der gesamten Produktion Zugriff auf diese Quelle. Einige davon sind Prüfungsgruppen von Drittanbietern und Entwickler, die zu anderen Unternehmen/Regierungen gewechselt sind. Wenn dieser Code ausreichend statisch ist, um die Kompatibilität aufrechtzuerhalten, wie dies bei einer Closed-Source-Vorteilsprämisse der Fall ist, können einige Schwachstellen viele Jahre lang unangekündigt bleiben. Diejenigen, die Zugriff auf diese geschlossene Quelle haben, haben die Freiheit, Code-Analyse-Tools dagegen auszuführen, um diese Schwachstellen zu untersuchen. Die Fehler-Repositories dieser Software-Entwicklungs-Shops sind voll von "kleinen" Fehlern, die zu Exploits führen können. Alle diese Informationen stehen vielen internen Personen zur Verfügung.

Angreifer wissen das und wollen diese Informationen für sich. Dies stellt ein riesiges Ziel für die interne Infrastruktur Ihres Unternehmens dar, wenn Sie einer dieser Shops sind. Und so wie es aussieht, werden Ihre Entwicklungsprozesse zu einer Sicherheitshaftung. Wenn Ihr Unternehmen groß genug und Ihre Codebasis gut genug verteilt ist, können Sie sogar ein Ziel für menschliche Infiltrationsbemühungen sein. An diesem Punkt wird die Charlie Miller-Technik: Bestechung eines Entwicklers mit genügend Geld und er wird Ihnen schreiben, dass ein nicht nachweisbarer Fehler eine eindeutige Möglichkeit ist.

Das bedeutet nicht, dass es auch nicht auf die gleiche Weise in OSS-Produkte gelangt. Es bedeutet nur, dass Sie über eine Reihe von Daten verfügen. Wenn diese freigegeben werden, können sie Schwachstellen in Ihrer Installationsbasis aufdecken. Wenn Sie es privat halten, entsteht eine Codierungsschuld gegenüber den von Ihren Kunden installierten Systemen, die Sie nicht sofort zurückzahlen können.

13
Ori

Sie sollten sich diese Papiere ansehen:

Das Ergebnis ist, dass offen oder geschlossen ungefähr gleichwertig ist, je nachdem, wie viel Tests mit ihnen durchgeführt werden. Und mit "Testen" meine ich nicht, was ein durchschnittlicher "Tester" für Unternehmensdrohnen tut, sondern eher wie vor Ort.

3
Bruce Ediger

Seien wir ehrlich, wenn jemand behauptet, Open Source sei sicherer als Closed Source, verallgemeinert er, was heute in Server-/Desktop-Betriebssystemen wie Linux (Open Source) und Mac/Windows (proprietär, Closed Source) passiert.

Warum wirkt sich Malware eher auf letztere und nicht auf erstere aus? Aus mehreren Gründen, von denen ich denke, dass der wichtigste der erste ist (entlehnt von diese andere Antwort auf eine Frage, die als Duplikat dieser Frage markiert ist ):

  1. Die vom Benutzer im Fall einer Linux-Distribution (oder eines anderen Open-Source-Betriebssystems) installierte Software wird normalerweise von einer zentralen Organisation (dh in der Bei Ubuntu wird es von Canonical erstellt und von ihm gehostet. Hier werden Binärdateien gehostet, die aus Quellen zusammengestellt wurden, die von der Open Source-Community kuratiert/überwacht wurden. Dies bedeutet, dass die Wahrscheinlichkeit, dass der Benutzer infizierte Software installiert, oder dass die OpenSource-Community böswillige Codeänderungen akzeptiert, viel geringer ist als bei Mac/Windows, wo der Benutzer normalerweise Software von vielen verschiedenen Stellen im Web installiert oder von vielen verschiedenen Anbietern aus AppStores. Es besteht auch das Risiko, dass die Server des Unternehmens (z. B. Canonical) gehackt werden. Dieses Risiko ist jedoch gering, da diese Unternehmen erstklassige IT-Experten für die Ausführung ihrer Server beschäftigen.
  2. Die Anzahl der Benutzer von Linux (oder anderen OpenSource-Betriebssystemen) ist viel geringer als die von Windows/Mac-Benutzern . Daher ziehen es Malware-Ersteller vor, sie nicht als Ziel festzulegen (als Vorteil)/Kostenverhältnis ist in diesem Fall niedriger).
  3. Da Linux nur ein Kernel ist , gibt es verschiedene Distributionen, aus denen Sie auswählen können . Daher müssten Malware-Ersteller größere Anstrengungen unternehmen, um ihren Schadcode zu erstellen mit vielen von ihnen kompatibel sein (daher ist das Nutzen-Kosten-Verhältnis in diesem Fall niedriger).
  4. Die Linux-Quellen (oder andere Open Source-Betriebssysteme) können von jedem gesehen/geändert werden. Das heißt, wenn eine Sicherheitslücke gefunden wird, kann jeder einen Fix dafür schreiben (es gibt keine Lieferantenbindung, Sie sind nicht an eine bestimmte Organisation gebunden, auf die Sie warten müssen, um einen Fix zu entwickeln) Sicherheitspatches treten früher auf als in Fällen mit proprietärer Software. (In der Praxis gibt es jedoch normalerweise keinen Unterschied, da die Unternehmen, die proprietäre Plattformen wie Windows und MacOS betreiben, große Unternehmen sind, die zufällig kompetent genug sind.)
0
knocte

Jim Fruchtermans OpenSource.com-Artikel " Ist Ihre Open Source-Sicherheitssoftware weniger sicher? " bietet eine sehr gute Analogie dafür, wie Open Source, obwohl Angreifer wissen, wie es funktioniert, die Software für Endbenutzer sicherer macht ::

Stellen Sie sich die Verschlüsselung als eine gesperrte Kombination vor, die für Ihre Daten sicher ist. Sie können der einzige sein, der über die Kombination verfügt, oder Sie können sie anvertrauen, um einige enge Mitarbeiter auszuwählen. Das Ziel eines Safes ist es, zu verhindern, dass unbefugte Personen Zugriff auf seine Inhalte erhalten. Dies können Einbrecher sein, die versuchen, wertvolle Geschäftsinformationen zu stehlen, Mitarbeiter, die versuchen, vertrauliche Gehaltsinformationen über ihre Kollegen zu erhalten, oder Betrüger, die vertrauliche Informationen erhalten möchten, um einen Betrug zu begehen. In jedem Fall möchten Sie, dass der Safe Ihre Sachen sicher hält und unbefugte Personen fernhält.

Nehmen wir jetzt an, ich wähle einen Safe für meine Wertsachen. Entscheide ich mich für Safe Number One, das mit Stahlwänden von einem halben Zoll, einer Zoll dicken Tür und sechs Verriegelungsbolzen beworben wird und von einer unabhängigen Behörde getestet wird, um zu bestätigen, dass der Inhalt bei einem Brand zwei Stunden lang überlebt? Oder wähle ich Safe Nummer Zwei, einen Safe, dem der Anbieter einfach vertrauen soll, weil die Designdetails des Safes ein Geschäftsgeheimnis sind? Es könnte sicher sein, dass Nummer zwei aus Sperrholz und dünnem Blech besteht. Oder es könnte sein, dass es stärker ist als Safe Number One, aber der Punkt ist, dass ich keine Ahnung habe.

Stellen Sie sich vor, Sie haben die detaillierten Pläne und Spezifikationen von Safe Nummer Eins, die ausreichen, um eine genaue Kopie dieses Safes zu erstellen, wenn Sie über die richtigen Materialien und Werkzeuge verfügen. Macht das Safe Nummer Eins weniger sicher? Nein, tut es nicht. Die Sicherheit von Safe Number One beruht auf zwei Schutzmaßnahmen: der Stärke des Designs und der Schwierigkeit, meine Kombination zu erraten. Wenn ich die detaillierten Pläne habe, kann ich oder sichere Experten feststellen, wie gut das Design ist. Es hilft festzustellen, dass der Safe keine Designfehler oder eine zweite "Hintertür" -Kombination aufweist, außer meiner selbst gewählten Kombination, die den Safe öffnet. Denken Sie daran, dass ein gutes sicheres Design es dem Benutzer ermöglicht, seine eigene Kombination zufällig auszuwählen. Das Wissen um das Design sollte einem Angreifer überhaupt nicht helfen, die zufällige Kombination eines bestimmten Safes mit diesem Design zu erraten.

0
Geremia