it-swarm.com.de

Sollte sicherheitskritischer Code wiederverwendet oder neu geschrieben werden?

Normalerweise ist die Wiederverwendung von Code beim Programmieren immer eine bessere Idee als das Schreiben einer eigenen Implementierung eines Algorithmus. Wenn es eine Implementierung schon lange gibt und sie immer noch von vielen Projekten verwendet wird, ist sie wahrscheinlich zunächst recht gut konzipiert, hat zahlreiche Tests und Fehlerbehebungen erhalten und ist vielleicht am wichtigsten, dass jemand anderes für die Wartung verantwortlich ist Dies bedeutet mehr Zeit, um sich auf das spezifische Softwareprodukt zu konzentrieren, das Sie erstellen.

Ich habe mich jedoch gefragt, ob dieses Prinzip immer noch für sicherheitskritischen Code gilt, der Aufgaben wie Verschlüsselung und Authentifizierung ausführt oder aus irgendeinem Grund mit hohen Berechtigungen ausgeführt wird. Wenn eine Implementierung eines Algorithmus von vielen Softwaresystemen gemeinsam genutzt wird, besteht für die Benutzer ein starker Anreiz, ihn zu knacken, und wenn ein Fehler darin gefunden wird, handelt es sich wahrscheinlich um eine massive Sicherheitskatastrophe. Heartbleed und Shellshock sind zwei aktuelle Beispiele, die mir in den Sinn kommen. Und für Beispiele aus geschlossenen Quellen wählen Sie etwas aus Adobe aus :)

Viele verschiedene Softwareteile, die eine einzige sicherheitskritische Bibliothek gemeinsam nutzen, machen diese Bibliothek auch zu einem bevorzugten Ziel für Angreifer, die eine Hintertür einfügen möchten. In einem großen Open-Source-Projekt mit viel Aktivität wird ein Backdoor-Commit, das auch viele andere Korrekturen (z. B. eine Bereinigung des Codestils) als Lockvogel enthält, wahrscheinlich nicht bemerkt.

Wird die Wiederverwendung von Code vor diesem Hintergrund immer noch als bewährte Methode für Code angesehen, der sicherheitskritische Aufgaben ausführt? Und wenn ja, welche Vorsichtsmaßnahmen sollten getroffen werden, um die oben genannten Schwächen dieses Ansatzes abzumildern?

55
Hadrien G.

Das Wichtigste ist Wartung . Unabhängig davon, ob Sie vorhandenen Code wiederverwendet oder Ihren eigenen geschrieben haben, erreichen Sie nur dann eine angemessene Sicherheit, wenn es irgendwo jemanden gibt, der den Code versteht und ihn beispielsweise im Hinblick auf die Entwicklung von Compilern und Plattformen über Wasser halten kann. Code ohne Fehler zu haben ist am besten, aber in der Praxis müssen Sie sich auf das nächstbeste verlassen, dh die sofortige Behebung von Fehlern (insbesondere die Fehler, die für böswillige Verwendung genutzt werden können, auch bekannt als Schwachstellen) innerhalb eines kurzen Zeitrahmens.

Wenn Sie Ihren eigenen Code schreiben, hängt der Wartungsjob direkt von Ihren eigenen Schultern ab. Und dieser Job kann sehr zeitaufwändig sein. Wenn Sie beispielsweise Ihre eigene SSL/TLS-Bibliothek schreiben und verwalten und in der Produktion verwenden möchten, müssen Sie alle Besonderheiten der kryptografischen Implementierung verstehen, insbesondere den Widerstand gegen Seitenkanalangriffe und Sie müssen veröffentlichte Angriffe und Gegenmaßnahmen im Auge behalten. Wenn Sie die Ressourcen dafür haben, sowohl zeitlich als auch kompetent, dann gut! Die Wartungskosten sind jedoch nicht zu unterschätzen. Die Wiederverwendung einer vorhandenen Bibliothek, insbesondere einer weit verbreiteten Open-Source-Bibliothek, kann auf lange Sicht erheblich billiger sein, da die Wartung von anderen Personen durchgeführt wird und eine weit verbreitete Nutzung eine externe Prüfung gewährleistet. Als Bonus können Sie nicht für die Sicherheitslücken in einer externen Bibliothek verantwortlich gemacht werden, wenn die halbe Welt sie teilt.

Zusammenfassend geht es bei der Frage nicht wirklich um Code Wiederverwendung, sondern um Wartungsaufwand Wiederverwendung.

(Ich schreibe dies alles unabhängig von den großen pädagogischen Qualitäten des Schreibens Ihres eigenen Codes. Ich ermutige Sie, Ihre eigenen Implementierungen vorzunehmen - aber sicherlich nicht, um sie tatsächlich in der Produktion zu verwenden. Dies ist für Lernen .)

66
Thomas Pornin

Umso mehr.

Sicherheitscode ist knifflig. Kryptografie-Code ist geradezu schwer, selbst wenn Sie ein ausgebildeter Kryptograf sind - und es ist unmöglich, ihn richtig zu machen, wenn Sie es nicht sind.

Wenn es so viele kritische Fehler in so vielen wichtigen Softwarepaketen und Unternehmen gibt - warum denken Sie dann, * könnten Sie einen besseren Job machen?

* Es sei denn natürlich, dies ist Ihr spezifisches Fachgebiet und die Sicherheitsfunktionalität ist der Kern Ihres Produkts ...

38
AviD

Interessante Frage! Ich möchte es eher vom Standpunkt der Wahrscheinlichkeit als vom Standpunkt der Best Current Practices aus beantworten.

Während Thomas und andere großartige Antworten liefern, denke ich nicht, dass sie die Kernfrage berühren - nämlich "ist eindeutiger (oder weniger verwendeter) Code mehr in der Praxis belastbar als populärer Code". Beachten Sie, dass ich absichtlich nicht "mehr sicher als populärer Code" verwendet habe. Und worauf es ankommt, ist der Sonderfall "Funktioniert Sicherheit durch Dunkelheit"?

Und (und ich weiß, dass dies keine beliebte Antwort sein wird) Ich denke, wenn wir "sicher" durch "belastbar" ersetzen, wird die Antwort möglicherweise nicht immer allgemein als "nie" akzeptiert.

Es steht fest, dass es wahrscheinlich weniger sicher (was bedeutet: Es ist sehr wahrscheinlich, dass Ihr eigener Sicherheitscode einfacher/schneller zu knacken ist als der beliebte, der zuvor viele Angriffe durchgemacht hat und von klügeren Personen behoben wurde als Du).

Wenn Sie jedoch keine große/beliebte Website sind, ist es auch so, dass Sie potenziellen Crackern viel weniger interessant sind, wenn sie den Code/Aufwand, der für das Knacken von Ihnen aufgewendet wurde, nicht wiederverwenden können, und dieser Aufwand ist nicht trivial ( Dies bedeutet, dass Ihre Site bei automatisiert Nichtvalidierungsparameter/SQL-Injection-Tests nicht zusammenbricht. Dies funktioniert offensichtlich nicht, wenn Sie gezielt eingesetzt werden (Industriespionage usw.), aber die überwiegende Mehrheit der Angriffe in diesen Tagen scheint tatsächlich eine automatisierte Untersuchung für beliebte Software zu sein.

Wenn die Frage also nicht "was sicherer ist", sondern "was weniger wahrscheinlich geknackt wird" lautet, könnte die Antwort tatsächlich "es kommt darauf an" lauten. Hier einige Beispiele:

Beispiel 1 : Stellen Sie sich einen Microsoft Windows 8.1-Computer (oder was auch immer heutzutage beliebt ist) vor, der derzeit keine bekannten Sicherheitslücken aufweist, gekauft, aber nie aktualisiert wurde und mit dem Internet verbunden ist. Stellen Sie sich auch das jahrzehntealte Windows 3.11 mit Winsock vor, das nie gepatcht wurde, mit bekannten Hunderten von Sicherheitslücken, die mit dem Internet verbunden sind. Beide werden auf die gleiche Weise verwendet. Ignorieren Sie zum Zwecke der Diskussion die Qualität des Zugriffs ... Die Frage ist, in welche wird früher eingebrochen?

Während es offensichtlich ist, dass 3.11 viel weniger sicher ist, gibt es in der Wildnis kaum Exploits, die darauf abzielen. Es könnte also durchaus sein, dass es einen äußerst beliebten 0-Tage-Exploit für 8.1 gibt, bevor 3.11 einen archaischen Exploit trifft, der es schafft, darauf zu laufen.

Beispiel 2 : Stellen Sie sich vor, Sie haben das neueste Joomla CMS auf einem Webserver ohne bekannte aktuelle Exploits und ein handgemachtes Perl-Skript, das CMS-ähnliche Dinge ausführt, mit bekannten ausnutzbaren Fehlern (aber keiner von ihnen ist derzeit verdächtig verfügbare automatisierte Tests). Was hat nach einem Jahr größere Chancen, dass es ausgenutzt wird?

Während anekdotische Beweise in wenigen Dutzend (bis Hunderten) Fällen, die ich in den letzten Jahrzehnten hatte, in den allermeisten Fällen populäre Software ausgenutzt wurden, während die veralteten bis heute ungestört laufen.

Weitere erwägenswerte Dinge:

  • wenn gängige Software automatisch aktualisiert (oder von Administratoren IMMER umgehend aktualisiert wird), werden die Schwachstellen eines solchen gängigen Codes erheblich reduziert (aber aufgrund von 0-Tage- und unveröffentlichten Exploits nicht beseitigt) und haben daher einen großen Vorteil
  • umgekehrt, wenn Software keine Wartung erhält, nicht populär (wie selbst geschrieben), kann man tatsächlich weniger verdächtig für Probleme sein
  • schuld - es kann oft vorteilhaft sein, beliebte Software zu verwenden. Wenn die halbe Welt betroffen ist, werden Sie nicht annähernd so viel Schuld bekommen, als wären Sie ein einzelner Programmierer. Dies ist besonders wichtig, wenn Sie mit Geld arbeiten. Es ist oft "besser", weniger sicher zu sein, aber die Schuld verschieben zu können, als sicherer zu sein, aber die Kosten selbst tragen zu müssen, wenn der Exploit zuschlägt.
  • arbeit - bereits von anderen erwähnt, populäre Software wird sich in den allermeisten Fällen von selbst reparieren, Sie müssen nur aktualisieren - was viel weniger Arbeit ist, als selbst Fehler zu finden und zu beheben (erfordert aber immer noch einige Wartung)
  • ein weiterer Vorteil für selbst geschriebene Software ist häufig die Reduzierung des Massencodes (was zu weniger Fehlern führt), da Sie normalerweise die meisten Funktionen oder Anpassungsmöglichkeiten nicht benötigen. Zum Beispiel werden die Leute Joomla verwenden, selbst wenn sie nur eine einfache "Template News Site" benötigen, die in der Praxis mit ein paar Dutzend Codezeilen erreicht werden könnte. Selbst wenn Sie als Programmierer nicht halb so gut sind wie die versierten, die an gängiger Software arbeiten (so dass Sie eine deutlich höhere Anzahl von Fehlern pro Codezeile haben), können Sie aufgrund der Größenordnung oft immer noch mit großem Vorsprung gewinnen ( oder wenige!) weniger Code zum Schreiben/Verwalten
15
Matija Nalis

Die einfache Antwort lautet: Rollen Sie nicht Ihre eigene Sicherheit.

Das besteht aus zwei Teilen. Algorithmus und Implementierung.

Was den Algorithmus betrifft, ist das Erstellen eines eigenen Verschlüsselungsalgorithmus schrecklich. Selbst wenn Sie sich auf dem Gebiet der Kryptographie auskennen, sind Sie immer noch nicht in der Lage, einen neuen Algorithmus zu erstellen. Wenn Sie nicht über ein Expertenteam verfügen, das daran arbeitet, rollen Sie keinen eigenen Algorithmus. Um diesen Punkt nach Hause zu fahren, schauen Sie sich einige der jüngsten Algorithmen an, die geknackt wurden, und wie sie geknackt wurden. Was auf den ersten Blick gut aussieht, hat Schwächen, die ich mir nie vorgestellt hätte.

Was die Implementierung betrifft, ist das Erstellen einer eigenen Implementierung eines guten Algorithmus nicht so schrecklich wie das Erstellen eines eigenen Algorithmus. Wenn Sie jedoch kein Profi sind, tun Sie dies nicht. Ein Fehler bei der Implementierung und es spielt keine Rolle, wie gut der Kernalgorithmus war. In diesem Fall müssen Sie sich die Frage stellen, ob Sie besser sind als die vielen Experten, die daran gearbeitet haben, eine erstklassige Sicherheitsbibliothek zusammenzustellen.

Was ist wahrscheinlicher. Dass Sie Ihren eigenen Algorithmus und Ihre eigene Implementierung ohne Fehler oder Schwächen rollen können oder dass der von Ihnen verwendete Algorithmus und die Implementierung eine Hintertür haben werden?

Wenn Sie mit der Implementierung einen perfekten Algorithmus erstellen könnten, wäre das Risiko der Hintertür kein Problem. Das ist aber nicht realistisch.

Es gibt auch die Frage, die Sie Ihrem Manager/Aktionär/ect. Erklären möchten. Dass es eine Hintertür in einem erstklassigen vertrauenswürdigen Softwarepaket gab, in dem die gesamte Branche herumläuft, oder dass Ihr persönlicher Versuch einer besseren Sicherheit schrecklich gescheitert ist. Ich persönlich würde viel lieber erklären, dass ich die Entscheidung getroffen habe, die Fachleute in der gesamten Branche getroffen haben, und der einzige Grund, warum dies fehlgeschlagen ist, war ein massives Problem, das selbst multinationale Unternehmen betrifft.

Trotzdem stimme ich Thomas zu, dass der Versuch, es selbst zu tun, eine gute Lernerfahrung ist, solange es nie das Licht der Produktion erblickt.

12
Lawtonfogle

Die Sicherheit wird nicht unbedingt verbessert, wenn der Code nach leicht abweichenden Anweisungen kompiliert wird. Sicherheit ist:

  1. Algorithmus
  2. Implementierung
  3. Prüfung
  4. Instandhaltung

Wenn Sie keine besseren, sichereren Algorithmen schreiben - was jahrelange Forschung erfordern kann - und Ihren Code nicht überprüft und entsprechend gepatcht werden, ist es sehr unwahrscheinlich, dass eine etwas andere Implementierung Sie sicher macht.

Heartbleed, Shellshock, BEAST, POODLE und andere wichtige SSL/TLS-Probleme sind aufgrund von Problemen aufgetreten, die CRC und selbstreferenziellen Algorithmen selbst inhärent sind, und aufgrund fehlender erfahrener Code-Audits nicht aufgrund der Implementierung .

Wenn Sie nicht wirklich verstehen, wie sie fehlgeschlagen sind, sollten Sie definitiv keinen eigenen Sicherheitscode schreiben. Sie werden mehr Probleme hinzufügen als lösen.

2