Der Haupt- und fast einzigartige Grund, warum die meiste Software im Linux-Ökosystem in C geschrieben ist, ist Tradition . Entwickler sehen in C geschriebene Software, Bibliotheken mit einer C-basierten API, und verwenden daher C, weil dies praktisch ist. Compiler sind bereits vorhanden und funktionieren gut, da das gesamte Betriebssystem in C geschrieben ist.

Nichts davon besagt, dass C gut für die Entwicklung robuster Software ist. Tatsächlich ist C ziemlich schrecklich darin. Bei C muss der Entwickler jederzeit auf viele Dinge achten. C verfügt über viele Traps, die für kleinste Fehler bereit sind, darunter:

• Ungeprüfte Array-Zugriffe, wodurch Überläufe möglich sind.
• Manuelle Speicherverwaltung, die zu einer späteren Verwendung führt -freie oder doppelt freie Fehler und Speicherlecks.
• Das gefürchtete "undefinierte Verhalten", das scheinbar vernünftige Ausdrücke amok laufen lässt (insbesondere signierte Operationen, die den darstellbaren Bereich überschreiten).

Was C wirklich gut kann, ist Folgendes:

• Interaktion mit eine vorhandene Gruppe von Bibliotheken, die eine C-API anbieten. C ist die Verkehrssprache , die die Interoperabilität zwischen Softwarekomponenten auf vielen Plattformen ermöglicht.

Was C passabel gut kann, ist:

• Schreiben von Code auf sehr niedriger Ebene (z. B. Kryptocode, der gegen Timing-Angriffe durch feste Speicherzugriffsmuster resistent ist), während versucht wird, ein gewisses Maß an Portabilität beizubehalten.

Meine Schlussfolgerung ist, dass C keine gute Idee ist, um sicherheitsrelevante Software im Allgemeinen zu schreiben, und dies schon seit einiger Zeit (mindestens ein Jahrzehnt) nicht mehr. C ist in bestimmten Kontexten immer noch gerechtfertigt, insbesondere wenn Sie auf eingebettete Plattformen abzielen (nicht eingebettet in "Smartphone", sondern eingebettet in "Smartcard"). Anstatt nach Gründen zu suchen, um sich von C zu entfernen, wäre es gerechtfertigter, nach bestimmten Gründen zu suchen, um C weiter zu verwenden.

Sie können sicheren Code in C schreiben. Es ist nur so, dass die Sprache standardmäßig unsicher ist . Die Sicherheit muss manuell mit zusätzlichem Code angegangen werden (der natürlich selbst Fehler enthalten kann).

Aus diesem Grund war C nie wirklich die beste Wahl für sicherheitskritische Software. Es wurde ohnehin in FOSS verwendet, da kostenlose Compiler dafür in der Vergangenheit auf nahezu jeder Plattform verfügbar waren (per Definition für jede Plattform, die gcc unterstützt).

Der allgemeine Rat für sicherheitskritische Software, wenn Sie nicht da sind. An eine bestimmte Sprache (wie C) gebunden ist die Verwendung von Ada. Diese Sprache befindet sich auf einer ähnlichen Abstraktionsebene wie C oder C ++, ist jedoch standardmäßig sicherheitsrelevant (z. B. automatische Überprüfung der Grenzen für alle Arrays) und bietet die Möglichkeit, Code hinzuzufügen, um Überprüfungen auszuschalten und nicht die andere andersherum.

Insbesondere gibt es eine Untergruppe von Ada namens SPARK, die speziell für sicherheitskritische Software entwickelt wurde. Es kann auch zur formalen Überprüfung von Software verwendet werden, wenn Sie sich für solche Dinge interessieren.

Zuallererst ist für Dinge wie Verschlüsselung Leistung wichtig .

Es ist der Unterschied, ob Hunderte von Benutzern oder nur 10 gleichzeitig bedient werden können. Dies hat einige Sicherheitsrelevanz: Wenn Ihre Server Probleme haben, können sie leicht mit einem DOS-Angriff entfernt werden.

Wenn Sie jemals reinen Python-Code mit nativem Code verglichen haben, werden Sie überrascht sein wie groß die Unterschiede sind.

Zweitens gibt es kein Python / Java ohne C . Unabhängig davon, welche "moderne" Sprache Sie betrachten, werden eine beträchtliche Anzahl von Bibliotheken darunter verwendet. Und raten Sie mal, die meisten davon sind C-Bibliotheken.

Wenn Sie nun eine "sicherheitskritische" Bibliothek in einer solchen Sprache schreiben, müssen Sie sich um 1. Probleme in Ihrem eigenen Code 2. Probleme in der Java / Python-Code, den Sie verwenden 3. Probleme im zugrunde liegenden C-Code (es gibt häufige Sicherheitsupdates für Java!) Und 4. Probleme in den darunter liegenden C-Bibliotheken, die sich ändern , ohne dass Sie es wissen (z. B. Betriebssystem-Updates) ). Wenn Sie sicherheitsrelevanten Code wünschen, minimieren Sie Abhängigkeiten.

Die Menge an C darunter nimmt zu und nicht ab . Dies mag nicht offensichtlich erscheinen. Aber Numpy, Tensorflow, JavaFX, ... diese verwenden alle viel C-Code darunter, wegen der Leistung .

Viele Probleme könnten durch sorgfältiges Engineering und vermieden werden ausführliche Programmierung. Zum Beispiel wurde der OSX-Fehler "goto fail" dadurch verursacht, dass Programmierer nicht die bewährte Methode befolgten, immer Klammern zu verwenden ...

  wenn (a) goto fail; goto fail; etwas anderes  

ist in den meisten Sprachen (außer Python, wo Sie für dasselbe Problem zwei Leerzeichen weniger benötigen) ein leicht zu übersehender Fehler, der einfach mit Ausführlichkeit vermieden werden kann:

  if (a) {goto fail; goto fail;} etwas anderes  

Es ist nicht so, als ob Python sehr hilfreich wäre, um solche Probleme zu vermeiden (tatsächlich würden Java-Compiler Sie vor nicht erreichbarem Code warnen - Python nicht, und C-Compiler können dies, wenn sie vom Benutzer aktiviert werden) ... Am Ende Entwicklerdisziplin bleibt ein Schlüsselfaktor.

C-Code erfordert normalerweise viel mehr Sorgfalt beim Schreiben. Das ist nicht eine schlechte Sache für die Qualität. Der Hauptnachteil ist, dass es langsamer zu entwickeln ist.

C wird seit über 20 Jahren von Millionen von Menschen verwendet. Die Sicherheitslücken, wie die mit scanf () , sind bekannt und dokumentiert, und es gibt etablierte und stark getestete Problemumgehungen.

Eine neuere Sprache, z. B. Perl 6 oder Python 3 wurde nur für kurze Zeit verwendet, nur wenige Personen sind Experten in diesen Bereichen, es können Sicherheitslücken bestehen, die noch nicht gefunden wurden, und kritische Überprüfungen und Dokumentationen sind spärlich.

Diese beiden neueren Sprachen sind es viel 'größer' als C mit weitaus mehr Fähigkeiten, und es kann sehr viel mehr als 20 Jahre dauern, bis alle möglichen Programmierkonstrukte verwendet wurden, und wir können uns ihrer Sicherheit sicher sein.

Es ist niedrig und standardmäßig völlig unsicher. Natürlich ist es möglich, sichere Software zu schreiben - aber Sie müssen gut darin sein. OTOH: C ist auf niedriger Ebene und Sie müssen keine Bibliotheken einschließen, die möglicherweise eigene Sicherheitsprobleme haben - dies könnte sei gut. Auch sollte man nicht vergessen, dass eine "sichere" Sprache bedeutet, dass es sich um Programme handelt, die wiederum ein mögliches Sicherheitsproblem darstellen.

Persönlich Ich würde wahrscheinlich die Verwendung von Rust empfehlen, da es ausreichend niedrig sein kann und sich auch auf die Sicherheit konzentriert.

Ich würde keinen nicht nativen Code verwenden ( dh nicht Java, C # usw.), es sei denn, Sie liefern Ihre eigene Laufzeit. Das Gleiche gilt natürlich für jede Bibliothek, auf die Sie verlinken, aber dies kann im Gegensatz zu nicht nativem Code vermieden werden.

Alles in allem sollten Sie sich auf den geringstmöglichen Code konzentrieren, d. H. Machen Sie es so einfach wie möglich und vertrauen Sie keinem anderen Code. Wenn Sie dies jedoch vermeiden können, vertrauen Sie nicht darauf, dass Sie sicheren Code schreiben - dies ist normalerweise nicht gut.

Der Grund für die Persistenz von C ist keine Tradition, sondern eine Portabilität und eine sehr zulässige API + lib. Ja, es denkt für Sie nicht wie ein hochrangiger Müll, die Sprache wurde in der festen Überzeugung erstellt, dass es nur ein Werkzeug zur Umsetzung Ihrer Idee ist. Wenn die Idee selbst schlecht / mit Fehlern gestaltet ist, nicht nur Sicherheitslücken - keine Sprache wird sie vollständig retten. Ja, einige neue "Produkte", die auf dummen Programmierern basieren, werden versuchen , das Problem am besten zu verhindern, aber sie werden nicht erfolgreich sein, nicht bei allen Problemen. Verwenden Sie Gehirn, Standard, Debugger und valgrind - und Sie werden C lieben für das, was es ist.