Warum werden strlcpy und strlcat als unsicher angesehen?

Ich verstehe das strlcpyund strlcatwurde als sicherer Ersatz für strncpyund konzipiert strncat. Einige Menschen sind jedoch immer noch der Meinung, dass sie unsicher sind und einfach eine andere Art von Problem verursachen .

Kann jemand ein Beispiel geben, wie die Verwendung von strlcpyoder strlcat(dh einer Funktion, deren Zeichenfolgen immer null sind) zu Sicherheitsproblemen führen kann?

Ulrich Drepper und James Antill geben an, dass dies wahr ist, geben jedoch niemals Beispiele oder klären diesen Punkt.

Erstens war strlcpyes nie als sichere Version von gedacht strncpy(und strncpywar auch nie als sichere Version von gedacht strcpy). Diese beiden Funktionen sind völlig unabhängig voneinander. strncpyist eine Funktion, die überhaupt keine Beziehung zu C-Strings (dh nullterminierten Strings) hat. Die Tatsache, dass der str...Name das Präfix enthält, ist nur ein historischer Fehler. Die Geschichte und der Zweck von strncpyist bekannt und gut dokumentiert. Dies ist eine Funktion, die für die Arbeit mit sogenannten Zeichenfolgen mit fester Breite (nicht mit C-Zeichenfolgen) erstellt wurde, die in einigen historischen Versionen des Unix-Dateisystems verwendet werden. Einige Programmierer werden heute durch seinen Namen verwirrt und nehmen an, dass dies strncpyirgendwie als C-String-Kopierfunktion mit begrenzter Länge dienen soll (ein "sicheres" Geschwister vonstrcpy), was in Wirklichkeit völliger Unsinn ist und zu schlechter Programmierpraxis führt. Die C-Standardbibliothek in ihrer aktuellen Form hat keinerlei Funktion zum Kopieren von C-Strings mit begrenzter Länge. Hier strlcpypasst es hinein. Dies ist in der strlcpyTat eine echte Kopierfunktion mit begrenzter Länge, die für die Arbeit mit C-Strings entwickelt wurde. strlcpymacht alles richtig, was eine Kopierfunktion mit begrenzter Länge tun sollte. Die einzige Kritik, die man darauf richten kann, ist, dass es leider kein Standard ist.

Zweitens ist es strncatin der Tat eine Funktion, die mit C-Strings arbeitet und eine Verkettung mit begrenzter Länge ausführt (es ist in der Tat ein "sicheres" Geschwister von strcat). Um diese Funktion richtig zu verwenden, muss der Programmierer besondere Sorgfalt walten lassen, da der Größenparameter, den diese Funktion akzeptiert, nicht wirklich die Größe des Puffers ist, der das Ergebnis empfängt, sondern die Größe seines verbleibenden Teils (auch das Abschlusszeichen) wird implizit gezählt). Dies kann verwirrend sein, da der Programmierer, um diese Größe an die Größe des Puffers zu binden, daran denken muss, einige zusätzliche Berechnungen durchzuführen, die häufig zur Kritik des Puffers verwendet werden strncat.strlcatkümmert sich um diese Probleme und ändert die Schnittstelle so, dass keine zusätzlichen Berechnungen erforderlich sind (zumindest im aufrufenden Code). Die einzige Grundlage, auf der ich dies kritisieren kann, ist, dass die Funktion nicht Standard ist. Funktionen aus der strcatGruppe werden im professionellen Code aufgrund der eingeschränkten Verwendbarkeit der Idee der Rescan-basierten String-Verkettung nur selten verwendet.

Wie diese Funktionen zu Sicherheitsproblemen führen können ... können sie einfach nicht. Sie können nicht in größerem Maße zu Sicherheitsproblemen führen, als die C-Sprache selbst "zu Sicherheitsproblemen führen kann". Sie sehen, es gab eine ganze Weile ein starkes Gefühl, dass sich die C ++ - Sprache in Richtung einer seltsamen Java-Variante entwickeln muss. Dieses Gefühl wirkt sich manchmal auch auf den Bereich der C-Sprache aus, was zu einer eher ahnungslosen und erzwungenen Kritik an C-Sprachmerkmalen und den Merkmalen der C-Standardbibliothek führt. Ich vermute, dass wir uns auch in diesem Fall mit so etwas befassen könnten, obwohl ich sicherlich hoffe, dass die Dinge nicht wirklich so schlimm sind.

Ulrichs Kritik basiert auf der Idee, dass eine vom Programm nicht erkannte Zeichenfolgenabschneidung durch falsche Logik zu Sicherheitsproblemen führen kann. Um sicher zu sein, müssen Sie daher auf Kürzungen prüfen. Um dies für eine Zeichenfolgenverkettung zu tun, müssen Sie eine Überprüfung in der folgenden Richtung durchführen:

if (destlen + sourcelen > dest_maxlen)
{
    /* Bug out */
}

Nun strlcattut effektiv diese Prüfung, wenn der Programmierer das Ergebnis zu überprüfen , erinnert sich - so Sie können es sicher verwenden:

if (strlcat(dest, source, dest_bufferlen) >= dest_bufferlen)
{
    /* Bug out */
}

Ulrichs Argument ist, dass Sie, da Sie destlenund sourcelenum sie haben müssen (oder sie neu berechnen müssen, was strlcateffektiv ist), genauso gut das effizientere verwenden memcpykönnen:

if (destlen + sourcelen > dest_maxlen)
{
    goto error_out;
}
memcpy(dest + destlen, source, sourcelen + 1);
destlen += sourcelen;

(Im obigen Code dest_maxlenist die maximale Länge der Zeichenfolge, in der gespeichert werden kann dest- eine weniger als die Größe des destPuffers. dest_bufferlenIst die volle Größe der dest buffer).

Wenn Leute sagen, " strcpy()ist gefährlich, verwenden Sie strncpy()stattdessen" (oder ähnliche Aussagen über strcat()usw., aber ich werde strcpy()hier als meinen Fokus verwenden), bedeuten sie, dass es keine Grenzen beim Einchecken gibt strcpy(). Eine zu lange Zeichenfolge führt daher zu Pufferüberläufen. Sie sind richtig. Mit strncpy()in diesem Fall wird Pufferüberläufe zu verhindern.

Ich denke, strncpy()das behebt wirklich keine Fehler: Es löst ein Problem, das von einem guten Programmierer leicht vermieden werden kann.

Als C - Programmierer, Sie müssen die Zielgröße kennen , bevor Sie Zeichenfolgen zu kopieren versuchen. Dies ist auch die Annahme in strncpy()und strlcpy()'s letzten Parametern: Sie geben ihnen diese Größe. Sie können auch die Quellgröße kennen, bevor Sie Zeichenfolgen kopieren. Wenn das Ziel nicht groß genug ist, rufen Sie nicht anstrcpy() . Ordnen Sie den Puffer entweder neu zu oder tun Sie etwas anderes.

Warum mag ich nicht strncpy()?

• strncpy() ist in den meisten Fällen eine schlechte Lösung: Ihre Zeichenfolge wird ohne vorherige Ankündigung abgeschnitten. Ich würde lieber zusätzlichen Code schreiben, um dies selbst herauszufinden, und dann die Vorgehensweise ausführen, die ich ausführen möchte, anstatt eine Funktion entscheiden zu lassen mir über was zu tun ist.
• strncpy()ist sehr ineffizient. Es schreibt in jedes Byte im Zielpuffer. Sie brauchen diese Tausenden '\0'am Ende Ihres Ziels nicht.
• Es wird keine Beendigung geschrieben, '\0'wenn das Ziel nicht groß genug ist. Sie müssen dies also trotzdem selbst tun. Die Komplexität ist die Mühe nicht wert.

Nun kommen wir zu strlcpy(). Die Änderungen von strncpy()machen es besser, aber ich bin nicht sicher, ob das spezifische Verhalten von strl*ihre Existenz rechtfertigt: Sie sind viel zu spezifisch. Sie müssen noch die Zielgröße kennen. Es ist effizienter als strncpy()weil es nicht unbedingt in jedes Byte im Ziel schreibt. Aber es löst ein Problem, das gelöst werden kann, indem man : *((char *)mempcpy(dst, src, n)) = 0;.

Ich glaube nicht, dass jemand das sagt strlcpy()oder strlcat()zu Sicherheitsproblemen führen kann, was er (und ich) sagen, dass sie zu Fehlern führen können, zum Beispiel wenn Sie erwarten, dass die vollständige Zeichenfolge anstelle eines Teils davon geschrieben wird.

Das Hauptproblem hierbei ist: Wie viele Bytes müssen kopiert werden? Der Programmierer muss dies wissen und wenn er es nicht tut strncpy()oder strlcpy()nicht retten wird.

strlcpy()und strlcat()sind nicht Standard, weder ISO C noch POSIX. Ihre Verwendung in tragbaren Programmen ist daher unmöglich. Tatsächlich strlcat()gibt es zwei verschiedene Varianten: Die Solaris-Implementierung unterscheidet sich von den anderen für Randfälle mit der Länge 0. Dies macht sie noch weniger nützlich als sonst.

Ich denke, Ulrich und andere denken, dass es ein falsches Gefühl der Sicherheit geben wird. Das versehentliche Abschneiden von Zeichenfolgen kann Auswirkungen auf die Sicherheit anderer Teile des Codes haben (wenn beispielsweise ein Dateisystempfad abgeschnitten wird, führt das Programm möglicherweise keine Vorgänge für die beabsichtigte Datei aus).

Es gibt zwei "Probleme" im Zusammenhang mit der Verwendung von strl-Funktionen:

1. Sie müssen die Rückgabewerte überprüfen, um ein Abschneiden zu vermeiden.

Die c1x Standard Draft Writer und Drepper argumentieren, dass Programmierer den Rückgabewert nicht überprüfen werden. Drepper sagt, wir sollten irgendwie die Länge kennen und memcpy verwenden und String-Funktionen insgesamt vermeiden. Das Standardkomitee argumentiert, dass der sichere strcpy beim Abschneiden ungleich Null zurückgeben sollte, sofern das _TRUNCATEFlag nichts anderes angibt . Die Idee ist, dass Leute eher if (strncpy_s (...)) verwenden.

2. Kann nicht für Nicht-Strings verwendet werden.

Einige Leute denken, dass String-Funktionen niemals abstürzen sollten, selbst wenn falsche Daten eingegeben werden. Dies betrifft Standardfunktionen wie strlen, die unter normalen Bedingungen fehlerhaft sind. Der neue Standard wird viele solcher Funktionen enthalten. Die Schecks haben natürlich eine Leistungsstrafe.

Der Vorteil der vorgeschlagenen Standardfunktionen besteht darin, dass Sie wissen, wie viele Daten Sie mit strl- Funktionen verpasst haben .

Ich glaube nicht , strlcpyund strlcatsind betrachten unsicher oder es am wenigsten es ist nicht der Grund , warum sie nicht in glibc enthalten - schließlich, glibc enthält Strncpy und sogar strcpy.

Die Kritik war, dass sie angeblich ineffizient und nicht unsicher sind .

Laut dem Secure Portability- Papier von Damien Miller:

Die API strlcpy und strlcat überprüft die Grenzen des Zielpuffers ordnungsgemäß, beendet sie in allen Fällen nicht und gibt die Länge der Quellzeichenfolge zurück, sodass das Abschneiden erkannt werden kann. Diese API wurde von den meisten modernen Betriebssystemen und vielen eigenständigen Softwarepaketen übernommen, darunter OpenBSD (woher sie stammt), Sun Solaris, FreeBSD, NetBSD, den Linux-Kernel, rsync und das GNOME-Projekt. Die bemerkenswerte Ausnahme ist die GNU-Standard-C-Bibliothek glibc [12], deren Betreuer sich entschieden weigert, diese verbesserten APIs aufzunehmen, und sie als „schrecklich ineffizienten BSD-Mist“ bezeichnet.[4], obwohl zuvor nachgewiesen wurde, dass sie schneller sind als die APIs, die sie ersetzen [13]. Infolgedessen behalten über 100 der im OpenBSD-Portsbaum enthaltenen Softwarepakete ihre eigenen strlcpy- und / oder strlcat-Ersetzungen oder gleichwertigen APIs bei - kein idealer Zustand.

Aus diesem Grund sind sie in glibc nicht verfügbar, aber es stimmt nicht, dass sie unter Linux nicht verfügbar sind. Sie sind unter Linux in libbsd verfügbar:

• https://libbsd.freedesktop.org/

Sie sind in Debian und Ubuntu und anderen Distributionen verpackt. Sie können auch einfach eine Kopie nehmen und in Ihrem Projekt verwenden - es ist kurz und unter einer zulässigen Lizenz:

• http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/string/strlcpy.c?rev=1.11

Sicherheit ist kein Boolescher Wert. C-Funktionen sind nicht vollständig "sicher" oder "unsicher", "sicher" oder "unsicher". Bei falscher Verwendung kann eine einfache Zuweisungsoperation in C "unsicher" sein. strlcpy () und strlcat () können sicher verwendet werden, ebenso wie strcpy () und strcat () sicher verwendet werden können, wenn der Programmierer die erforderlichen Zusicherungen für eine korrekte Verwendung bietet.

Der Hauptpunkt bei all diesen C-String-Funktionen, Standard und nicht so Standard, ist das Niveau, bis zu dem sie die sichere Verwendung erleichtern . strcpy () und strcat () sind nicht trivial sicher zu verwenden; Dies wird durch die Häufigkeit bewiesen, mit der C-Programmierer im Laufe der Jahre Fehler gemacht haben und böse Sicherheitslücken und Exploits aufgetreten sind. strlcpy () und strlcat () sowie strncpy () und strncat (), strncpy_s () und strncat_s () sind etwas einfacher sicher zu verwenden, aber dennoch nicht trivial. Sind sie unsicher / unsicher? Bei falscher Verwendung ist nicht mehr als memcpy ().