Welche Funktionen in der C-Standardbibliothek fördern häufig schlechte Praktiken? [closed]

Dies wird durch diese Frage und die Kommentare zu einer bestimmten Antwort inspiriert, in denen ich das gelernt habe strncpy ist keine sehr sichere String-Handling-Funktion in C und füllt Nullen auf, bis sie erreicht nwas mir nicht bewusst war.

Konkret, um R. zu zitieren.

strncpy endet nicht mit Null und füllt den gesamten Rest des Zielpuffers mit Null auf, was eine enorme Zeitverschwendung ist. Ersteres können Sie umgehen, indem Sie Ihr eigenes Null-Padding hinzufügen, letzteres jedoch nicht. Es war nie für die Verwendung als “sichere Zeichenfolgenbehandlungsfunktion” gedacht, sondern für die Arbeit mit Feldern fester Größe in Unix-Verzeichnistabellen und Datenbankdateien. snprintf(dest, n, “%s”, src) ist das einzig korrekte “sichere strcpy” in Standard-C, aber es ist wahrscheinlich viel langsamer. Übrigens kann das Abschneiden an sich ein großer Fehler sein und in einigen Fällen zu einer Erhöhung der Berechtigungen oder DoS führen. Daher ist das Auslösen von “sicheren” Zeichenfolgenfunktionen, die ihre Ausgabe bei einem Problem abschneiden, keine Möglichkeit, es “sicher” oder ” sicher”. Stattdessen sollten Sie sicherstellen, dass der Zielpuffer die richtige Größe hat, und einfach strcpy verwenden (oder noch besser memcpy, wenn Sie die Länge des Quellstrings bereits kennen).

Und von Jonathan Leffler

Beachten Sie, dass strncat() in seiner Schnittstelle noch verwirrender ist als strncpy() – was genau ist das Längenargument noch einmal? Es ist nicht das, was Sie erwarten würden, basierend auf dem, was Sie strncpy() usw. bereitstellen – daher ist es sogar fehleranfälliger als strncpy(). Beim Kopieren von Strings bin ich zunehmend der Meinung, dass es ein starkes Argument dafür gibt, dass man nur memmove() braucht, weil man immer alle Größen im Voraus kennt und dafür sorgt, dass genügend Platz im Voraus vorhanden ist. Verwenden Sie memmove() gegenüber strcpy(), strcat(), strncpy(), strncat(), memcpy().

Ich bin also eindeutig ein wenig eingerostet in Bezug auf die C-Standardbibliothek. Daher möchte ich die Frage stellen:

Welche C-Standardbibliotheksfunktionen werden unangemessen/in einer Weise verwendet, die Sicherheitsprobleme/Codedefekte/Ineffizienzen verursachen/führen kann?

Im Interesse der Objektivität habe ich eine Reihe von Kriterien für eine Antwort:

• Bitte geben Sie, wenn möglich, gestalterische Gründe für die betreffende Funktion an, dh ihren Verwendungszweck.
• Bitte markieren Sie den Missbrauch, dem der Code derzeit ausgesetzt ist.
• Bitte geben Sie an, warum dieser Missbrauch zu einem Problem führen kann. Ich weiß, das sollte offensichtlich sein, aber es verhindert sanfte Antworten.

Bitte vermeiden Sie:

• Debatten über Namenskonventionen von Funktionen (außer wenn dies eindeutig zu Verwirrung führt).
• “Ich bevorzuge x gegenüber y” – Präferenz ist in Ordnung, wir alle haben sie, aber ich interessiere mich für tatsächliche unerwartete Nebenwirkungen und wie man sich davor schützt.

Da dies wahrscheinlich als subjektiv angesehen wird und keine eindeutige Antwort hat, melde ich mich sofort für das Community-Wiki an.

Ich arbeite auch nach C99.

Welche C-Standardbibliotheksfunktionen werden unangemessen/in einer Weise verwendet, die Sicherheitsprobleme/Codedefekte/Ineffizienzen verursachen/führen kann?

Ich werde mit dem Offensichtlichen gehen:

char *gets(char *s);

Mit seiner bemerkenswerten Besonderheit, dass es einfach unmöglich ist, es angemessen zu verwenden.

Ein häufiger Fallstrick bei der strtok() Funktion soll davon ausgehen, dass die geparste Zeichenfolge unverändert bleibt, während sie tatsächlich das Trennzeichen durch ersetzt '\0'.

Ebenfalls, strtok() wird durch nachfolgende Aufrufe verwendet, bis die gesamte Zeichenfolge tokenisiert ist. Einige Bibliotheksimplementierungen speichern strtok()den internen Status von in einer globalen Variablen, was zu bösen Überraschungen führen kann, wenn strtok() wird von mehreren Threads gleichzeitig aufgerufen.

Das CERT C Secure Coding Standard listet viele dieser Fallstricke auf, nach denen Sie gefragt haben.

In fast allen Fällen atoi() nicht verwendet werden (gilt auch für atof(), atol() und atoll()).

Dies liegt daran, dass diese Funktionen Out-of-Range-Fehler überhaupt nicht erkennen – sagt der Standard einfach “Wenn der Wert des Ergebnisses nicht dargestellt werden kann, ist das Verhalten undefiniert.”. Sie können also nur dann sicher verwendet werden, wenn Sie nachweisen können, dass die Eingabe sicherlich innerhalb des Bereichs liegt (z. B. wenn Sie eine Zeichenfolge der Länge 4 oder weniger an übergeben atoi()es darf nicht außerhalb des Bereichs liegen).

Verwenden Sie stattdessen eine der strtol() Familie von Funktionen.

Erweitern wir die Frage auf Schnittstellen im weiteren Sinne.

errno:

technisch ist nicht einmal klar, was es ist, eine Variable, ein Makro, ein impliziter Funktionsaufruf? In der Praxis auf modernen Systemen ist es meistens ein Makro, das sich in einen Funktionsaufruf verwandelt, um einen Thread-spezifischen Fehlerzustand zu haben. Es ist böse:

• da es für den Aufrufer zu einem Overhead führen kann, auf den Wert zuzugreifen, um den “Fehler” zu überprüfen (der möglicherweise nur ein außergewöhnliches Ereignis ist).
• weil es an einigen Stellen sogar vorschreibt, dass der Aufrufer diese “Variable” löscht, bevor er eine Bibliothek aufruft
• weil es eine einfache Fehlerrückgabe implementiert, indem es einen globalen Zustand der Bibliothek festlegt.

Der kommende Standard erhält die Definition von errno ein bisschen gerader, aber diese Hässlichkeiten bleiben

Es gibt oft ein strtok_r.

Wenn Sie für realloc den alten Zeiger verwenden müssen, ist es nicht so schwierig, eine andere Variable zu verwenden. Wenn Ihr Programm mit einem Zuordnungsfehler fehlschlägt, ist das Aufräumen des alten Zeigers oft nicht wirklich notwendig.

ich würde setzen printf und scanf ziemlich weit oben auf dieser Liste. Die Tatsache, dass Sie die Formatierungsspezifizierer genau richtig erhalten müssen, macht diese Funktionen schwierig zu verwenden und extrem leicht falsch zu machen. Es ist auch sehr schwierig, Pufferüberläufe beim Auslesen von Daten zu vermeiden. Darüber hinaus hat die “String-Schwachstelle im printf-Format” wahrscheinlich unzählige Sicherheitslücken verursacht, wenn gut gemeinte Programmierer Client-spezifizierte Strings als erstes Argument für printf angeben, nur um viele Jahre später festzustellen, dass der Stack zerstört und die Sicherheit kompromittiert ist.

Jede der Funktionen, die den globalen Zustand manipulieren, wie z gmtime() oder localtime(). Diese Funktionen können einfach nicht sicher in mehreren Threads verwendet werden.

BEARBEITEN: rand() ist in der gleichen Kategorie, wie es scheint. Zumindest gibt es keine Garantien für Thread-Sicherheit, und auf meinem Linux-System warnt die Manpage, dass es nicht-reentrant und nicht-threadsicher ist.