Lassen Sie uns hier klar sein.

unsicher ist eine Frage des Kontexts , nicht der "Verwendung" einer bestimmten Funktion. Wenn ich memcpy unsicher in einem Prozess verwende, der als Benutzer ausgeführt wird und wenig zu verlieren hat, keine Setuid oder solche Flags, ist das "Schlimmste", was ich tun kann, eine Shell für diesen Benutzer zu erhalten und von dort aus fortzufahren. Um eine Eskalation von Berechtigungen zu erreichen, müssen Sie etwas angreifen, das Sie täuschen können, um Ihnen höhere Berechtigungen zu gewähren.
1. C / C ++ sind keine "gefährlichen Werkzeuge". Sie sind Werkzeuge. Fügen Sie eine entsprechende Metapher über gefährliche DIY-Geräte ein.
ol>

Tatsache ist, wie Rook bereits gesagt hat, dass C / C ++ und andere solche auf die Maschine kompilierten Sprachen einen Platz in der Welt haben. Sie dienen zum Erstellen schneller Systeme, Betriebssysteme, Systemdienste usw. Sie bieten Ihnen die Möglichkeit, Ihren eigenen Speicher nach Belieben zu verwalten. Sie haben die Kontrolle.

Wenn Sie keine Form der automatischen Speicherverwaltung einführen, können Sie nicht wirklich herausfinden, ob Sie den zugewiesenen Speicher überschritten haben. Also, ok, lasst uns einen Container vorstellen. Jetzt muss jeder Speicherzugriffsaufruf, der jemals war, überprüft werden. Ist es in Umfang für diese bestimmte Funktion? Wie viele Objekte zeigen darauf? Wo sind sie im Geltungsbereich? Kann ich Zeiger außerhalb des Bereichs der ursprünglichen Referenz haben und wenn ja, wie verfolge ich diese? Sehr schnell haben Sie eine virtuelle Maschine und damit eine verwaltete Sprache.

Wie in StackOverflow gezeigt wurde, ist es auch möglich, memcpy_s auf eine Art und Weise aufzurufen das ist sowieso unsicher. Es löst das grundlegende Problem nicht wirklich, sondern macht es nur etwas schwieriger, Fehler zu machen.

Das ist der Unterschied. C / C ++ ist eine ausgefallene Assembly mit all der Leistung, die Sie für alles benötigen. Java / Python usw. schützen Sie davor zu einem Preis: Geschwindigkeit und Leistung.

Sie haben im Laufe des heutigen Tages wiederholt gesagt (ich habe auch die SO-Version befolgt), dass Sie immer noch keine Antwort darauf haben, wie Sie sich mit C / C ++ auf anderen Systemen wie Linux sicher entwickeln. Zunächst einmal habe ich mit VS2005 / 2008 gewöhnlich CRT_SECURE_NO_DEPRECATE festgelegt, aber trotzdem können Sie Folgendes tun:

1. Sie fragen nach StackOverflow. Sie nehmen zur Kenntnis, lernen, lesen und lesen erneut.
2. Ihr Compiler ist (meistens) Ihr Freund. Hör es dir an. Verwenden Sie Warnungen. Verwandle sie in Fehler. Also cl / W4 und gcc -Wall -Werror -pedantic -std = c99 . Ja, es ist OTT in Bezug auf Fehlermeldungen. Aber wenn Sie nicht jeden einzelnen erklären und begründen können, warum Sie ihn ignorieren, verstehen Sie Ihren eigenen Code nicht.
3. Überprüfen Sie Ihre Speicherzuordnung. Der Standardaufruf von valgrind überprüft Ihre Zuordnungen und Freigaben, damit Sie keinen Speicher verlieren. Wenn Sie Speicherlecks haben, haben Sie nicht genug über Ihren Code nachgedacht. Dies ist ein gutes Zeichen dafür, dass Sie Fehler nacheinander, ungültige Grenzwerte usw. usw. haben.
4. Verwenden Sie erneut valgrind . Ich habe das gerade aufgegriffen, aber schauen Sie, es gibt einen experimentellen Über- / Unterlaufprüfer in Valgrind. Hier erfahren Sie, ob Sie beispielsweise am Ende des Stapels abstürzen (möglich, da dort die meisten lokalen Variablen zugewiesen sind) oder außerhalb des Heaps brk () .
5. Verwenden Sie Schiene , auch als sichere Flusen bezeichnet, und notieren Sie sich deren Ausgabe. Wenn Sie keine Ausgabe erklären können, verstehen Sie Ihren Code nicht.

6. Verdauen Sie den C Secure Coding Standard nach innen. Hier besonders relevant:

   • STR31-C. Stellen Sie sicher, dass der Speicher für Zeichenfolgen ausreichend Platz für Zeichendaten und den Nullterminator bietet.

     Das Kopieren von Daten in einen Puffer, der nicht groß genug ist, um diese Daten aufzunehmen, führt zu einem Pufferüberlauf. Obwohl dies nicht auf nullterminierte Byte-Strings (NTBS) beschränkt ist, treten bei der Bearbeitung von NTBS-Daten häufig Pufferüberläufe auf. Um solche Fehler zu vermeiden, beschränken Sie Kopien entweder durch Abschneiden oder stellen Sie vorzugsweise sicher, dass das Ziel ausreichend groß ist, um die zu kopierenden Zeichendaten und das Nullterminierungszeichen aufzunehmen.

   • STR35-C. Kopieren Sie keine Daten von einer unbegrenzten Quelle in ein Array mit fester Länge

     Funktionen, die unbegrenzte Kopien ausführen, erfordern häufig, dass externe Eingaben eine angemessene Größe haben. Solche Annahmen können sich als falsch erweisen und einen Pufferüberlauf verursachen. Aus diesem Grund muss bei der Verwendung von Funktionen, die möglicherweise unbegrenzte Kopien ausführen, Vorsicht walten lassen.

     Splint bietet Ihnen eine Anleitung ähnlich der von CERT. Beachten Sie, dass memcpy im ersten Beispiel von STR35-C als kompatible Lösung betrachtet wird.

7. Wenn Sie C ++ verwenden, verwenden Sie std :: string und boost :: shared_ptr (und verwandte; verwenden Sie das entsprechende). Es gibt absolut kein Argument dafür, malloc'ing und memcpy Zeichenfolgen in C ++ zu speichern, außer für die Interaktion mit C. Selbst dann string.c_str () Bitte überlassen Sie die Manipulationen C ++.
8. Verknüpfen Sie nach Möglichkeit dynamisch. Wenn Sie einen Code von Drittanbietern statisch mit Ihrer App verknüpft haben und dies ein Sicherheitsproblem darstellt, haben Sie es auch und müssen Ihr Bild ebenfalls neu verteilen. Freigegebene Objekte sind im Allgemeinen nicht nur bequemer, Sie erhalten auch standardmäßig Sicherheitsupdates. Ich weiß, dass es Fälle gibt, in denen Sie dies nicht können. Deshalb sage ich "wo möglich".
9. Bauen Sie dies in Ihren Entwicklungszyklus ein.
10. Ich hoffe, Sie haben nichts verpasst.
11. Bleiben Sie über relevante Aktualisierungen der Sicherheitsgemeinschaft auf dem Laufenden.
12. Sei nett zur Sicherheitsgemeinschaft. Bestätigen Sie die Sicherheitslücken und ergreifen Sie Maßnahmen, um sie zu beheben. Jeder Code hat (oder hatte sie) Fehler, wenn es sich lohnt, sie auszuführen. So einfach ist das.
ol>

Letztendlich glaube ich nicht, dass das Problem durch "sichere" Funktionen gelöst wird. Ich denke, das Problem wird durch die Verwendung einiger anständiger Tools, einen ordnungsgemäßen Entwicklungsprozess, der schlechten Code aus kritischen Versionen (späte Betas und Release-Kandidaten) ablehnt, und schließlich durch ein Bewusstsein für bewährte Verfahren / aktuelle Probleme gelöst.

Schließlich ist memcpy_s nicht Teil des C99-Standards. Es ist eine Erweiterung der C-Bibliothek (wie in keinem Teil des Kerns) und daher nicht garantiert auf der Plattform, die ich verwende. memcpy ist. Für ein Softwareprojekt, das plattformübergreifend kompiliert werden muss, ist dies wahrscheinlich der entscheidende Faktor für die zu verwendende Funktion.

Und insbesondere, was ist mit Nicht-MS-Plattformen - einschließlich Linux- und sogar Nicht-VS-Compilern unter Windows ...

Es gibt ein plattformübergreifendes Open-Source-Projekt namens CoreFoundation Lite als Teil von Apples Core OS, das C-Typen für die sichere Bearbeitung von Byteblöcken, Zeichenfolgen und anderen grundlegenden Datentypen bereitstellt. Relevant für diese Diskussion implementieren sie Typprüfung, Grenzwertprüfung, Speicherverwaltung und unterscheiden zwischen veränderlichen und unveränderlichen Objekten.

Empfohlene Problemumgehungen (außer einfach mehr Grenzwertprüfung durchzuführen ...)?

Microsoft unsafe.h bietet übrigens GCC-Unterstützung. Auf diese Weise verwenden Sie das gift -Pragma von GCC, um einen Fehler zu verursachen, wenn Sie eine unsichere Funktion verwenden. Ich habe darüber zusätzlich in einem Buch geschrieben, das ich geschrieben habe (Haftungsausschluss: Ich habe es geschrieben).

Oder sind wir alle dazu verdammt, unsere Verwendung von memcpy weiterhin zu wiederholen?

Grundsätzlich lautet die Lösung "Tu das nicht". Sogenannte sichere Implementierungen können Sie daran hindern, über Speicher zu kritzeln, der nicht Ihnen gehört, aber dennoch viele "Missbrauchsfälle" offen lassen. Die Überprüfung von Grenzen ist nur ein kleiner Teil des Problems. Nehmen wir zum Beispiel an, Sie malloc (1024) und beschließen, einen Zeiger auf Byte 56 zu erstellen und diesen als Referenz auf eine bestimmte Struktur zu behandeln, die 16 Byte lang ist. Wenn Sie dann ("sicher") 58 Bytes auf den ursprünglichen Zeiger kopieren, ist der Kopiervorgang erfolgreich, aber Ihre Struktur ist fehlerhaft. Können Sie den Bruch erkennen? Vielleicht nicht: Es könnte immer noch wie eine gültige Struktur aussehen (insbesondere wenn Sie eine magische Zahl am Ende setzen oder keine magische Zahl haben).

Die Probleme " Stack Smashing "und" Heap Corruption "sind eigentlich Sonderfälle des Problems" Speicher als großen, untypisierten Beutel mit Bytes behandeln ". Einige andere Beispiele für dieses Problem sind:

• STR30-C. Versuchen Sie nicht, Zeichenfolgenliterale zu ändern Während veränderbare und unveränderliche C-Zeichenfolgen aus der Perspektive "Big Bag of Bytes" gleich aussehen, führt der Versuch, ein Zeichenfolgenliteral an Ort und Stelle zu bearbeiten, zu undefiniertem Verhalten. Der Code kann jedoch nicht erkennen, ob ein char * ein Zeichenarray oder ein Zeichenfolgenliteral darstellt. Daher muss der gesamte Aufwand für die Sicherstellung des korrekten Verhaltens durch Aufrufen von Code behoben werden.
• MEM01-C. Speichern Sie einen neuen Wert in Zeigern unmittelbar nach free () , da es möglich ist, auf einen Speicherblock zu verweisen, der nicht mehr Ihnen gehört, und im Allgemeinen ist es schwer zu sagen, ob er gültig ist oder nicht nicht.
• MEM05-C. Vermeiden Sie große Stapelzuweisungen Diese ist besonders witzig, wenn Sie mit jemandem zu tun haben, der behauptet, Sie müssten nur Ihre Grenzen korrigieren, und der Rest fällt zusammen. Mit diesem Problem können Sie vollständig intern konsistenten und korrekten Code haben, der den Stapel dennoch zerschmettert.

Die Liste wird fortgesetzt: Siehe den Rest des CERT C Secure Coding Standard.

Die umfassende Antwort lautet: Verwenden Sie C (oder C ++) nicht mehr! Es ist ein archaisches und geradezu gefährliches Werkzeug. Wechseln Sie zu einer Sprache mit integrierter Sicherheit (Java, C #, Schema, OCaml, Python ... die Auswahl ist groß).

Ein Pufferüberlauf ist ein Fehler unter den generischen Fehlerklassen, die als "the" bekannt sind Der Programmierer weiß nicht genau, was er tut. " Eine Sprache mit Grenzüberprüfung (oder sogar die Verwendung von memcpy_s () ) entfernt solche Fehler nicht. Dies führt nur zu weniger schwerwiegenden Konsequenzen (z. B. wird eine Ausnahme ausgelöst, die normalerweise eine sofortige Thread-Beendigung impliziert). Es ist wie ein Sicherheitsgurt: Ein Sicherheitsgurt verhindert keine Autounfälle, sondern versucht nur, Sie am Leben zu erhalten, während Ihr Auto in Vergessenheit gerät. Sie sollten daher gebundene Schecks (insbesondere in Sprachen, in denen solche Schecks auf transparente Weise enthalten sind) aus demselben Grund verwenden, aus dem Sie immer den Sicherheitsgurt anlegen sollten.

Wie bei C: memcpy_s () und sein ilk sind tatsächlich in ISO / IEC TR 24731 (einem Standard aus dem Jahr 2005) definiert, sodass sie irgendwann in C- und C ++ - Compiler versickern sollen. Aber es scheint, dass derzeit nur Microsoft sie vorantreibt. Für die "String" -Funktionen ( strcpy () und strcat () ) gibt es Standardfunktionen (C99) ( strncpy () und strncat () ) und einige BSD-Betriebssysteme (hauptsächlich OpenBSD) verwenden Varianten mit einer etwas benutzerfreundlicheren API ( strlcpy () und strlcat () ). Keine dieser Funktionen behebt jedoch den Fehler, dh der Programmierer versucht, Daten in einen zu kleinen Puffer zu legen. Sie machen den Programmierer lediglich auf die Tatsache aufmerksam, dass sein Puffer möglicherweise eine unzureichende Größe hat.

Der Linux-Kernel ruft viele tausend sogenannte unsichere Funktionen wie strcpy () und strcat () auf, der Puffer läuft jedoch über Diese Codebasis ist sehr ungewöhnlich. Tatsächlich werden "unsichere Funktionen" zum Kopieren von statischem Text bevorzugt, da dies den Overhead verringert. Sie können "sichere Funktionsaufrufe" auf unsichere Weise verwenden: strncpy (dest, source, strlen (source)); . Die Auswahl der Funktionen hat keinen Einfluss darauf, wie sicher das System ist.

Dieses Problem lässt sich mit modernen Speicherschutzsystemen besser lösen. Diese sind implizit und der Code muss nicht neu geschrieben werden. In moderner Software mit Kanarienvögeln sind ASLR- und NX-Zonen Pufferüberläufe allein nicht sehr hilfreich. Dangling-Zeiger wurden in 2010 pwn2own für Windows 7 und IE8 und der letzte Flash-0-Tag überhaupt nicht für einen Pufferüberlauf verwendet.

Aber was ist mit "reinem" C (dh nicht C ++)?

Ich glaube nicht, dass Funktionen wie memcpy_s wirklich als "sicherer" Ersatz für memcpy gelten. Aber so oder so sind sie gleichermaßen in reinem 'C' anwendbar, es gibt nicht viel, was 'C ++' an ihnen ist. Sie sind auch nicht plattformspezifisch (in dem Sinne, dass es nicht allzu schwierig ist, eine tragbare Version von ihnen zu schreiben, auch wenn Sie sich nicht darauf verlassen können, dass sie Teil der Plattform-C-Bibliothek sind).

As Aus Sicherheitsgründen sind memcpy & co so definiert , dass sie willkürliches Kritzeln im Speicher ermöglichen. Dafür sind sie gedacht, und das Hinzufügen von Größenparametern wird dies nicht ändern.

Gleichzeitig halte ich es (noch) nicht für sinnvoll, "Nicht 'C' / C ++ verwenden" zu sagen, da es immer noch viele Systeme gibt, in denen eine 'C' -ähnliche Sprache die Sprache ist einzige praktische Option.

Die eigentliche Frage ist wohl, ob es eine sicherere Alternative zum Puffermanagement gibt, die eher ein Sicherheitsnetz als memcpy hat und von C und C ++ aus verwendet werden kann. Ja sicher. Eine 'C'-API oder C ++ - Klasse könnte definiert werden, um Grenzen überprüfte Puffer und Arrays zuzuweisen, zu verwalten und darauf zuzugreifen. Genau darauf greift der Interpreter für Java VM et al. Zu.

Dort Es gibt auch Sprachen wie Objective-C, die noch keinen verwalteten Code haben und die einen Großteil der Sicherheitsaspekte des verwalteten Codes aufweisen, obwohl memcpy usw. verfügbar sind. Dies liegt daran, dass das Kakao-Framework dazu neigt, sicherere Alternativen zu fördern und zumindest zuzulassen.

Eine weitere 'sichere' API für die Behandlung von Zeichenfolgen in C ist Daniel J Bernsteins Zeichenfolgenbibliothek. Dank an André Pang, der mich darauf hingewiesen hat.

Menschen werden niemals aufhören, Fehler zu machen. Selbst in sogenannten "sicheren Implementierungen" und einer Liste von Sprachen, die Thomas Pornin erwähnt hat, wird es einen Platz für eine gewisse Verwundbarkeit geben. In der aktuellen Antwort möchte ich nicht auf die Besonderheiten von C / C ++ eingehen - es wird als Ergänzung zu dem, was bereits gesagt wurde, nicht viel Sinn machen. An dieser Stelle möchte darauf hingewiesen werden, dass eine andere Lösung nicht darin besteht, Fehler selbst zu verhindern, sondern die Folgen der Ausbeutung zu mindern. Das ist nur ein weiterer Teil dessen, was aus Sicherheitsgründen getan werden kann. Schauen Sie sich als bestes Beispiel den Browser von Google Chrome an - er hat Sandboxing implementiert. Eine weitere Möglichkeit sind Compiler-Sicherheitsoptionen und Ausnutzungsminderungen auf Betriebssystemebene. Dies sind die Konsequenzen dessen, was in einem allerersten Satz gesagt wurde, und eine Bestätigung der Tatsache, dass die Einführung von Fehlern ein unvermeidlicher Bestandteil jeder Softwareentwicklung ist.