Pourquoi ce code est-il vulnérable aux attaques par débordement de tampon?

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

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

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

Ce code est vulnérable à une attaque par débordement de tampon, et j'essaie de comprendre pourquoi. Je pense que cela a à voir avec le fait d' lenêtre déclaré un shortau lieu d'un int, mais je ne suis pas vraiment sûr.

Des idées?

Sur la plupart des compilateurs, la valeur maximale de an unsigned shortest 65535.

Toute valeur au-dessus de cela est bouclée, donc 65536 devient 0 et 65600 devient 65.

Cela signifie que de longues chaînes de la bonne longueur (par exemple 65600) passeront le contrôle et déborderont de mémoire tampon.

Permet size_tde stocker le résultat de strlen(), non unsigned shortet de le comparer lenà une expression qui code directement la taille de buffer. Donc par exemple:

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

Le problème est ici:

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

Si la chaîne est supérieure à la longueur du tampon cible, strncpy la copiera toujours. Vous basez le nombre de caractères de la chaîne comme le nombre à copier au lieu de la taille du tampon. La bonne façon de procéder est la suivante:

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

Cela limite la quantité de données copiées à la taille réelle de la mémoire tampon moins un pour le caractère de fin nul. Ensuite, nous définissons le dernier octet du tampon sur le caractère nul en tant que sauvegarde supplémentaire. La raison en est que strncpy copiera jusqu'à n octets, y compris le null de fin, si strlen (str) <len - 1. Sinon, le null n'est pas copié et vous avez un scénario de plantage car maintenant votre tampon a un non terminé chaîne.

J'espère que cela t'aides.

EDIT: Après un examen plus approfondi et des contributions d'autres personnes, un codage possible pour la fonction suit:

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);
  }

Puisque nous connaissons déjà la longueur de la chaîne, nous pouvons utiliser memcpy pour copier la chaîne de l'emplacement référencé par str dans le tampon. Notez que d'après la page de manuel de strlen (3) (sur un système FreeBSD 9.3), ce qui suit est indiqué:

 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.

Ce que j'interprète comme étant que la longueur de la chaîne n'inclut pas le null. C'est pourquoi je copie len + 1 octets pour inclure la valeur null, et le test vérifie que la longueur <taille du tampon - 2. Moins un car le tampon commence à la position 0, et moins un autre pour s'assurer qu'il y a de la place pour le nul.

EDIT: Il s'avère que la taille de quelque chose commence par 1 tandis que l'accès commence par 0, donc le -2 avant était incorrect car il renverrait une erreur pour tout ce qui> 98 octets mais il devrait être> 99 octets.

EDIT: Bien que la réponse à propos d'un court non signé soit généralement correcte car la longueur maximale pouvant être représentée est de 65 535 caractères, cela n'a pas vraiment d'importance car si la chaîne est plus longue que cela, la valeur s'enroulera. C'est comme prendre 75,231 (qui est 0x000125DF) et masquer les 16 premiers bits vous donnant 9695 (0x000025DF). Le seul problème que je vois avec ceci est les 100 premiers caractères après 65 535 car la vérification de la longueur autorisera la copie, mais elle ne copiera que les 100 premiers caractères de la chaîne dans tous les cas et la valeur null terminera la chaîne . Ainsi, même avec le problème de bouclage, le tampon ne sera toujours pas débordé.

Cela peut ou non poser en soi un risque de sécurité en fonction du contenu de la chaîne et de l'utilisation que vous en faites. S'il ne s'agit que d'un texte simple lisible par l'homme, il n'y a généralement pas de problème. Vous obtenez juste une chaîne tronquée. Cependant, si c'est quelque chose comme une URL ou même une séquence de commandes SQL, vous pourriez avoir un problème.

Même si vous utilisez strncpy, la longueur de la coupure dépend toujours du pointeur de chaîne passé. Vous n'avez aucune idée de la longueur de cette chaîne (l'emplacement du terminateur nul par rapport au pointeur, c'est-à-dire). Appeler strlenseul vous ouvre donc à la vulnérabilité. Si vous voulez être plus sûr, utilisez strnlen(str, 100).

Le code complet corrigé serait:

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;
}

La réponse avec l'emballage est juste. Mais il y a un problème qui, je pense, n'a pas été mentionné si (len> = 100)

Eh bien, si Len valait 100, nous copierions 100 éléments et nous n'aurions pas de \ 0 à la fin. Cela signifierait clairement que toute autre fonction dépendant de la chaîne correctement terminée marcherait bien au-delà du tableau d'origine.

La chaîne problématique de C est insoluble à mon humble avis. Vous feriez toujours mieux d'avoir des limites avant l'appel, mais même cela n'aidera pas. Il n'y a pas de vérification des limites et donc les débordements de tampon peuvent toujours et se produiront malheureusement

Au-delà des problèmes de sécurité liés à l'appel strlenplus d'une fois, il ne faut généralement pas utiliser de méthodes de chaîne sur des chaînes dont la longueur est précisément connue [pour la plupart des fonctions de chaîne, il n'y a qu'un cas vraiment étroit où elles doivent être utilisées - sur des chaînes pour lesquelles un maximum la longueur peut être garantie, mais la longueur précise n'est pas connue]. Une fois que la longueur de la chaîne d'entrée est connue et que la longueur du tampon de sortie est connue, il faut déterminer la taille d'une région à copier et l'utiliser ensuite memcpy()pour effectuer réellement la copie en question. Bien qu'il soit possible que strcpycela soit plus performant memcpy()lors de la copie d'une chaîne de seulement 1 à 3 octets ou plus, sur de nombreuses plates memcpy()- formes, il est susceptible d'être plus de deux fois plus rapide lorsqu'il s'agit de chaînes plus volumineuses.

Bien qu'il existe certaines situations où la sécurité se ferait au détriment des performances, c'est une situation où l'approche sécurisée est également la plus rapide. Dans certains cas, il peut être raisonnable d'écrire du code qui n'est pas sécurisé contre les entrées au comportement étrange, si le code fournissant les entrées peut garantir qu'elles se comportent correctement, et si la protection contre les entrées mal conduites entraverait les performances. S'assurer que les longueurs de chaîne ne sont vérifiées qu'une seule fois améliore à la fois les performances et la sécurité, bien qu'une chose supplémentaire puisse être faite pour aider à protéger la sécurité même lors du suivi manuel de la longueur de la chaîne: pour chaque chaîne qui devrait avoir un nul à la fin, écrivez plutôt le null à la fin. que de s'attendre à ce que la chaîne source l'ait. Ainsi, si l'on écrivait un strdupéquivalent:

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;
}

Notez que la dernière instruction pourrait généralement être omise si le memcpy avait traité des len+1octets, mais si un autre thread devait modifier la chaîne source, le résultat pourrait être une chaîne de destination non terminée par NUL.