Pourquoi strlcpy et strlcat sont-ils considérés comme non sécurisés ?

Question

Je comprends que strlcpy et strlcat ont été conçus comme des remplacements sûrs des strncpy et strncat . Cependant, certaines personnes sont encore d'avis qu'elles sont l'insécurité, et simplement causer un autre type de problème .

Quelqu'un peut-il donner un exemple de l'utilisation de strlcpy ou strlcat (c'est-à-dire une fonction qui toujours null termine ses chaînes de caractères) peut entraîner des problèmes de sécurité ?

Ulrich Drepper et James Antill affirment que c'est vrai, mais ne fournissent jamais d'exemples ni ne clarifient ce point.

Answer 1

Tout d'abord, strlcpy n'a jamais été conçu comme une version sécurisée de strncpy (et strncpy n'a jamais été conçu comme une version sécurisée de strcpy ). Ces deux fonctions ne sont absolument pas liées. strncpy est une fonction qui n'a aucune relation avec les chaînes de caractères C (c'est-à-dire les chaînes de caractères à terminaison nulle). Le fait qu'elle ait l'attribut str... dans son nom est juste une erreur historique. L'histoire et le but de strncpy est bien connue et bien documentée. Il s'agit d'une fonction créée pour travailler avec les chaînes de caractères dites "à largeur fixe" (et non avec les chaînes de caractères C) utilisées dans certaines versions historiques du système de fichiers Unix. Certains programmeurs sont aujourd'hui déroutés par son nom et supposent que la fonction strncpy est en quelque sorte censé servir de fonction de copie de chaînes de caractères C de longueur limitée (une sœur "sécurisée" de la fonction strcpy ), ce qui, en réalité, est un non-sens total et conduit à de mauvaises pratiques de programmation. La bibliothèque standard du C, dans sa forme actuelle, n'a aucune fonction pour la copie de chaînes de caractères C de longueur limitée. C'est là que les strlcpy s'adapte. strlcpy est en effet une véritable fonction de copie de longueur limitée créée pour travailler avec des chaînes C. strlcpy fait correctement tout ce qu'une fonction de copie de longueur limitée devrait faire. La seule critique que l'on puisse lui adresser est qu'elle n'est, malheureusement, pas standard.

Deuxièmement, strncat d'autre part, est en effet une fonction qui fonctionne avec des chaînes C et effectue une concaténation de longueur limitée (il s'agit en effet d'une fonction "sécurisée" de la fonction strcat ). Pour utiliser cette fonction correctement, le programmeur doit faire preuve d'une attention particulière, car le paramètre size que cette fonction accepte n'est pas vraiment la taille du tampon qui reçoit le résultat, mais plutôt la taille de sa partie restante (de plus, le caractère de terminaison est compté implicitement). Cela peut prêter à confusion, car pour lier cette taille à celle du tampon, le programmeur doit se souvenir d'effectuer quelques calculs supplémentaires, ce qui est souvent utilisé pour critiquer la fonction strncat . strlcat s'occupe de ces questions, en modifiant l'interface de sorte qu'aucun calcul supplémentaire ne soit nécessaire (du moins dans le code d'appel). Encore une fois, la seule critique que l'on puisse formuler à ce sujet est que la fonction n'est pas standard. De plus, les fonctions de strcat est quelque chose que vous ne verrez pas très souvent dans le code professionnel en raison de l'utilité limitée de l'idée même de concaténation de chaînes de caractères basée sur le rescan.

Quant à savoir comment ces fonctions peuvent entraîner des problèmes de sécurité... Elles ne le peuvent tout simplement pas. Elles ne peuvent pas conduire à des problèmes de sécurité dans une plus grande mesure que le langage C lui-même peut "conduire à des problèmes de sécurité". Vous voyez, pendant un certain temps, il y a eu un fort sentiment que le langage C++ doit évoluer dans la direction d'une sorte de saveur bizarre de Java. Ce sentiment se répand parfois dans le domaine du langage C également, ce qui donne lieu à des critiques plutôt maladroites et forcées des caractéristiques du langage C et de la bibliothèque standard C. Je soupçonne que nous pourrions avoir affaire à quelque chose de ce genre dans ce cas également, même si j'espère vraiment que les choses ne sont pas si mauvaises.

Answer 2

La critique d'Ulrich repose sur l'idée qu'une troncature de chaîne non détectée par le programme peut entraîner des problèmes de sécurité, par le biais d'une logique incorrecte. Par conséquent, pour être sûr, vous devez vérifier la troncature. Faire cela pour une concaténation de chaînes de caractères signifie que vous effectuez une vérification du type de celle-ci :

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

Maintenant, strlcat effectue effectivement cette vérification, si le programmeur n'oublie pas de vérifier le résultat - donc vous peut l'utiliser en toute sécurité :

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

Le point de vue d'Ulrich est que puisque vous devez avoir destlen et sourcelen (ou de les recalculer, ce qui est ce que fait l'UE). strlcat ), vous pouvez tout aussi bien utiliser la méthode plus efficace de la memcpy de toute façon :

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

(Dans le code ci-dessus, dest_maxlen est la longueur maximale de la chaîne de caractères qui peut être stockée dans le fichier dest - un de moins que la taille de la dest tampon. dest_bufferlen est la taille complète de la dest buffer ).

Answer 3

Quand les gens disent, " strcpy() est dangereux, utilisez strncpy() au lieu de" (ou des déclarations similaires sur strcat() etc., mais je vais utiliser strcpy() ici comme mon point de mire), ils signifient qu'il n'y a pas de vérification des limites dans strcpy() . Ainsi, une chaîne trop longue entraînera un dépassement de la mémoire tampon. Ils sont corrects. Utilisation de strncpy() dans ce cas, empêchera les dépassements de tampon.

J'ai l'impression que strncpy() ne corrige pas vraiment les bugs : il résout un problème qui peut être facilement évité par un bon programmeur.

En tant que programmeur C, vous doit connaître la taille de la destination avant d'essayer de copier des chaînes de caractères. C'est l'hypothèse dans strncpy() et strlcpy() Vous pouvez également connaître les derniers paramètres de l'utilisateur : vous leur fournissez cette taille. Vous pouvez également connaître la taille de la source avant de copier les chaînes de caractères. Ensuite, si la destination n'est pas assez grande, n'appelez pas strcpy() . Soit vous réallouez le tampon, soit vous faites autre chose.

Pourquoi je n'aime pas strncpy() ?

• strncpy() est une mauvaise solution dans la plupart des cas : votre chaîne de caractères va être tronquée sans que vous le sachiez. Je préfère écrire du code supplémentaire pour déterminer moi-même ce qu'il en est et ensuite prendre la décision que je souhaite prendre, plutôt que de laisser une fonction décider pour moi de ce qu'il faut faire.
• strncpy() est très inefficace. Il écrit sur chaque octet du tampon de destination. Vous n'avez pas besoin de ces milliers de '\0' à la fin de votre destination.
• Il n'écrit pas une terminaison '\0' si la destination n'est pas assez grande. Vous devez donc de toute façon le faire vous-même. La complexité de cette opération n'en vaut pas la peine.

Maintenant, nous en arrivons à strlcpy() . Les changements de strncpy() l'améliorer, mais je ne suis pas sûr que le comportement spécifique des strl* justifie leur existence : ils sont beaucoup trop spécifiques. Il faut toujours connaître la taille de la destination. C'est plus efficace que strncpy() parce qu'il n'écrit pas nécessairement sur chaque octet de la destination. Mais il résout un problème qui peut être résolu en faisant : *((char *)mempcpy(dst, src, n)) = 0; .

Je ne pense pas que quelqu'un dise que strlcpy() ou strlcat() peuvent entraîner des problèmes de sécurité, ce qu'ils (et moi) disent, c'est qu'ils peuvent entraîner des bogues, par exemple, lorsque vous vous attendez à ce que la chaîne complète soit écrite au lieu d'une partie de celle-ci.

La question principale ici est : combien d'octets faut-il copier ? Le programmeur doit le savoir, et s'il ne le sait pas.., strncpy() ou strlcpy() ne le sauvera pas.

strlcpy() et strlcat() ne sont pas standard, ni ISO C ni POSIX. Leur utilisation dans des programmes portables est donc impossible. En effet, strlcat() a deux variantes différentes : l'implémentation de Solaris est différente des autres pour les cas limites impliquant la longueur 0. Cela le rend encore moins utile qu'autrement.

Answer 4

Je pense qu'Ulrich et d'autres pensent que ça va donner un faux sentiment de sécurité. Troncature accidentelle des chaînes de caractères peut ont des implications en matière de sécurité pour d'autres parties du code (par exemple, si un chemin d'accès au système de fichiers est tronqué, le programme peut ne pas effectuer d'opérations sur le fichier prévu).

Answer 5

Il existe deux "problèmes" liés à l'utilisation des fonctions strl :

1. Vous devez vérifier les valeurs de retour pour éviter la troncature.

Les rédacteurs du projet de norme c1x et Drepper, soutiennent que les programmeurs ne vérifieront pas la valeur de retour. Drepper dit que nous devrions d'une manière ou d'une autre connaître la longueur, utiliser memcpy et éviter complètement les fonctions de chaîne de caractères. Le comité de normalisation soutient que la fonction sécurisée strcpy devrait retourner une valeur non nulle en cas de troncature, sauf indication contraire de l'utilisateur. _TRUNCATE drapeau. L'idée est que les gens sont plus susceptibles d'utiliser if(strncpy_s(...)).

2. Ne peut pas être utilisé sur des non-strings.

Certaines personnes pensent que les fonctions de chaîne de caractères ne devraient jamais se planter, même lorsqu'elles reçoivent des données erronées. Cela affecte les fonctions standard telles que strlen qui, dans des conditions normales, se planteront. La nouvelle norme comprendra de nombreuses fonctions de ce type. Les contrôles ont bien sûr un impact sur les performances.

L'avantage par rapport aux fonctions standard proposées est que vous pouvez savoir combien de données vous avez manqué avec strl fonctions.