Warum ist dieser Code anfällig für Pufferüberlaufangriffe?

int func(char* str)
{
   char buffer[100];
   unsigned short len = strlen(str);

   if(len >= 100)
   {
        return (-1);
   }

   strncpy(buffer,str,strlen(str));
   return 0;
}

Dieser Code ist anfällig für einen Pufferüberlaufangriff, und ich versuche herauszufinden, warum. Ich denke, es hat damit zu tun, lendass man als a shortstatt als deklariert wird int, aber ich bin mir nicht sicher.

Irgendwelche Ideen?

Bei den meisten Compilern beträgt der Maximalwert von a unsigned short65535.

Jeder darüber liegende Wert wird umbrochen, sodass 65536 zu 0 und 65600 zu 65 wird.

Dies bedeutet, dass lange Zeichenfolgen mit der richtigen Länge (z. B. 65600) die Prüfung bestehen und den Puffer überlaufen.

Verwenden Sie size_tdiese Option , um das Ergebnis von strlen()nicht zu speichern unsigned shortund lenmit einem Ausdruck zu vergleichen , der die Größe von direkt codiert buffer. Also zum Beispiel:

char buffer[100];
size_t len = strlen(str);
if (len >= sizeof(buffer) / sizeof(buffer[0]))  return -1;
memcpy(buffer, str, len + 1);

Das Problem ist hier:

strncpy(buffer,str,strlen(str));
                   ^^^^^^^^^^^

Wenn die Zeichenfolge größer als die Länge des Zielpuffers ist, kopiert strncpy sie weiterhin. Sie verwenden die Anzahl der Zeichen der Zeichenfolge als die zu kopierende Anzahl anstelle der Größe des Puffers. Der richtige Weg, dies zu tun, ist wie folgt:

strncpy(buffer,str, sizeof(buff) - 1);
buffer[sizeof(buff) - 1] = '\0';

Dadurch wird die Menge der kopierten Daten auf die tatsächliche Größe des Puffers minus eins für das Null-Abschlusszeichen begrenzt. Dann setzen wir das letzte Byte im Puffer als zusätzlichen Schutz auf das Nullzeichen. Der Grund dafür ist, dass strncpy bis zu n Bytes kopiert, einschließlich der abschließenden Null, wenn strlen (str) <len - 1. Wenn nicht, wird die Null nicht kopiert und Sie haben ein Absturzszenario, da Ihr Puffer jetzt nicht abgeschlossen ist Zeichenfolge.

Hoffe das hilft.

BEARBEITEN: Nach weiterer Prüfung und Eingabe durch andere folgt eine mögliche Codierung für die Funktion:

int func (char *str)
  {
    char buffer[100];
    unsigned short size = sizeof(buffer);
    unsigned short len = strlen(str);

    if (len > size - 1) return(-1);
    memcpy(buffer, str, len + 1);
    buffer[size - 1] = '\0';
    return(0);
  }

Da wir die Länge der Zeichenfolge bereits kennen, können wir memcpy verwenden, um die Zeichenfolge von der Position, auf die str verweist, in den Puffer zu kopieren. Beachten Sie, dass auf der Handbuchseite für strlen (3) (auf einem FreeBSD 9.3-System) Folgendes angegeben ist:

 The strlen() function returns the number of characters that precede the
 terminating NUL character.  The strnlen() function returns either the
 same result as strlen() or maxlen, whichever is smaller.

Was ich so interpretiere, dass die Länge der Zeichenfolge nicht die Null enthält. Aus diesem Grund kopiere ich len + 1 Bytes, um die Null einzuschließen, und der Test prüft, ob die Länge <Größe des Puffers - 2 ist. Minus eins, da der Puffer an Position 0 beginnt, und minus eins, um sicherzustellen, dass Platz vorhanden ist für die Null.

BEARBEITEN: Es stellt sich heraus, dass die Größe von etwas mit 1 beginnt, während der Zugriff mit 0 beginnt. Daher war die -2 vorher falsch, da sie einen Fehler für alles> 98 Bytes zurückgeben würde, aber> 99 Bytes sein sollte.

BEARBEITEN: Obwohl die Antwort auf eine vorzeichenlose Kurzform im Allgemeinen korrekt ist, da die maximal darstellbare Länge 65.535 Zeichen beträgt, spielt dies keine Rolle, da der Wert umbrochen wird, wenn die Zeichenfolge länger ist. Es ist, als würde man 75.231 (das ist 0x000125DF) nehmen und die oberen 16 Bits maskieren, was 9695 (0x000025DF) ergibt. Das einzige Problem, das ich dabei sehe, sind die ersten 100 Zeichen nach 65.535, da die Längenprüfung das Kopieren zulässt, aber in allen Fällen nur bis zu den ersten 100 Zeichen der Zeichenfolge kopiert und die Zeichenfolge mit Null beendet wird . Selbst mit dem Wraparound-Problem wird der Puffer immer noch nicht überlaufen.

Dies kann an sich ein Sicherheitsrisiko darstellen oder nicht, abhängig vom Inhalt der Zeichenfolge und dem, wofür Sie sie verwenden. Wenn es sich nur um geraden Text handelt, der von Menschen gelesen werden kann, gibt es im Allgemeinen kein Problem. Sie erhalten nur eine abgeschnittene Zeichenfolge. Wenn es sich jedoch um eine URL oder sogar eine SQL-Befehlssequenz handelt, liegt möglicherweise ein Problem vor.

Auch wenn Sie verwenden strncpy, hängt die Länge des Cutoffs immer noch vom übergebenen Zeichenfolgenzeiger ab. Sie haben keine Ahnung, wie lang diese Zeichenfolge ist (dh die Position des Nullterminators relativ zum Zeiger). Wenn Sie strlenalleine anrufen, sind Sie anfällig für Sicherheitslücken. Wenn Sie sicherer sein möchten, verwenden Sie strnlen(str, 100).

Vollständiger Code korrigiert wäre:

int func(char *str) {
   char buffer[100];
   unsigned short len = strnlen(str, 100); // sizeof buffer

   if (len >= 100) {
     return -1;
   }

   strcpy(buffer, str); // this is safe since null terminator is less than 100th index
   return 0;
}

Die Antwort mit der Verpackung ist richtig. Aber es gibt ein Problem, von dem ich denke, dass es nicht erwähnt wurde, wenn (len> = 100)

Nun, wenn Len 100 wäre, würden wir 100 Elemente kopieren und hätten kein nachfolgendes \ 0. Dies würde eindeutig bedeuten, dass jede andere Funktion in Abhängigkeit von der richtigen Endzeichenfolge weit über das ursprüngliche Array hinausgehen würde.

Die Zeichenfolge problematisch von C ist meiner Meinung nach unlösbar. Sie sollten immer einige Grenzen vor dem Anruf haben, aber selbst das wird nicht helfen. Es gibt keine Überprüfung der Grenzen und so können und werden Pufferüberläufe immer passieren ....

Abgesehen von den Sicherheitsproblemen, die mit dem mehrmaligen Aufrufen verbunden strlensind, sollte man im Allgemeinen keine String-Methoden für Strings verwenden, deren Länge genau bekannt ist [für die meisten String-Funktionen gibt es nur einen wirklich engen Fall, in dem sie verwendet werden sollten - für Strings, für die maximal Länge kann garantiert werden, aber die genaue Länge ist nicht bekannt]. Sobald die Länge der Eingabezeichenfolge bekannt ist und die Länge des Ausgabepuffers bekannt ist, sollte man herausfinden, wie groß eine Region kopiert werden soll, und dann verwenden memcpy(), um die betreffende Kopie tatsächlich durchzuführen. Obwohl es möglich ist, dass beim Kopieren einer Zeichenfolge mit nur etwa 1 bis 3 Byte eine strcpyOutperformance memcpy()erzielt wird, ist dies auf vielen Plattformen memcpy()bei größeren Zeichenfolgen wahrscheinlich mehr als doppelt so schnell.

Obwohl es einige Situationen gibt, in denen Sicherheit zu Lasten der Leistung gehen würde, ist dies eine Situation, in der der sichere Ansatz auch der schnellere ist. In einigen Fällen kann es sinnvoll sein, Code zu schreiben, der nicht gegen Eingaben mit seltsamem Verhalten gesichert ist, wenn der Code, der die Eingaben liefert, sicherstellen kann, dass sie sich gut verhalten, und wenn der Schutz vor Eingaben mit schlechtem Verhalten die Leistung beeinträchtigen würde. Wenn Sie sicherstellen, dass die Zeichenfolgenlängen nur einmal überprüft werden, verbessern Sie sowohl die Leistung als auch die Sicherheit. Sie können jedoch eine zusätzliche Maßnahme ergreifen, um die Sicherheit auch bei manueller Verfolgung der Zeichenfolgenlänge zu gewährleisten: Schreiben Sie für jede Zeichenfolge, für die eine nachfolgende Null erwartet wird, die nachfolgende Null explizit als zu erwarten, dass die Quellzeichenfolge es hat. Wenn man also ein strdupÄquivalent schreibt :

char *strdupe(char const *src)
{
  size_t len = strlen(src);
  char *dest = malloc(len+1);
  // Calculation can't wrap if string is in valid-size memory block
  if (!dest) return (OUT_OF_MEMORY(),(char*)0); 
  // OUT_OF_MEMORY is expected to halt; the return guards if it doesn't
  memcpy(dest, src, len);      
  dest[len]=0;
  return dest;
}

Beachten Sie, dass die letzte Anweisung im Allgemeinen weggelassen werden kann, wenn der Memcpy len+1Bytes verarbeitet hat. Wenn jedoch ein anderer Thread die Quellzeichenfolge ändert, kann das Ergebnis eine nicht NUL-terminierte Zielzeichenfolge sein.