Des soucis à la chaîne

À la différence de memcpy qui prend en paramètre la quantité de mémoire à copier (dans l’hypothèse que le buffer de sortie soit assez grand), la fonction strcpy copiera successivement les octets du buffer d’entrée vers le buffer de sortie jusqu’à trouver une valeur sentinelle, le fameux ‘\0’. La porte ouverte à de nombreuses exploitations et à une API qui a bien évolué au fil du temps.

1. strcpy

La page de manuel de strcpy(3) insiste lourdement sur ce sujet : c’est à la charge du développeur d’allouer un buffer assez grand pour contenir la chaîne copiée. Si ce n’est pas le cas, l’écriture a lieu sur les octets qui suivent, typiquement si le buffer de destination a été alloué sur la pile, cela permet d’écraser les valeurs qui suivent, et potentiellement de changer le chemin d’exécution pris par le programme. Si l’entrée est contrôlée par l’utilisateur (lue sur le réseau, dans les arguments, sur l’entrée standard, etc.), c’est la porte ouverte à une attaque de type out-of-bound write (CWE-787), qui fait top 1 au classement des vulnérabilités de code 2023 tenu par https://cwe.mitre.org. Et on parle là d’une fonction validée par le standard C89 et POSIX.1-2001, donc qui est là pour rester et qui est au fondement de ce château de cartes qu’on appelle l’informatique.

Bien sûr, des évolutions ont été proposées, alors parlons un peu de strncpy.

2. strncpy

Estampillée POSIX.1-2008, strncpy ajoute un troisième argument à strcpy, argument qui désigne le nombre de caractères qui seront écrits dans le buffer de sortie. Si la taille de la chaîne d’entrée est plus petite que cette valeur, le buffer est rempli d’octets de bourrage positionnés à zéro, ce qui permet d’éviter une fuite d’information : les valeurs précédemment stockées dans ce buffer sont toutes écrasées. Par contre si la taille de la chaîne d’entrée est plus grande que la valeur du troisième argument, une simple troncation est effectuée et aucun octet de terminaison n’est ajouté. Seul le test explicite du dernier octet écrit permet de savoir si une troncation a eu lieu.

Ce comportement permet d’éviter des écritures hors du buffer en rendant la taille de ce dernier explicite, mais la chaîne résultante peut ne plus être valide (le standard fait d’ailleurs la distinction entre une string et une character sequence). Une lecture subséquente de ce buffer en faisant l’hypothèse qu’il possède un octet de terminaison résultera en… une lecture hors des bornes, soit un out-of-bound read (CWE 125), qui ne fait que top 7 au classement des vulnérabilités de code 2023. Maigre progrès.

Bien sûr, des évolutions ont été proposées, alors parlons un peu de strlcpy.

3. strlcpy

strlcpy est une fonction spécifique à OpenBSD apparue avec OpenBSD 2.4, dans le but de corriger les erreurs de conception associées à strncpy. Elle a la même signature que cette dernière, mais garantit l’écriture d’un octet à zéro, même en cas de troncation. Et contrairement à strncpy qui renvoie un pointeur vers l’argument de destination (pour faciliter le chaînage avec d’autres fonctions), strlcpy renvoie le nombre d’octets écrits, en excluant l’octet nul, ce qui permet de détecter facilement la troncation.

On notera avec amusement cette phrase issue de la page de manuel de strlcpy, après un exemple d’optimisation du chaînage d’un strlcpy avec un strlcat :

However, one may question the validity of such optimizations, as they defeat the whole purpose of strlcpy() and strlcat(). As a matter of fact, the first version of this manual page got it wrong.

Reste que strlcpy est spécifique à OpenBSD. Bien sûr, des évolutions ont été proposées, alors parlons un peu de strcpy_s. Mais pas avant un petit détour par stpecpy.

4. stpecpy

Vous n’avez jamais entendu parler de cette fonction ? Normal, elle n’existe pas. Et pourtant, elle a sa page de manuel, qui nous apprend que (traduction libre) « specpy(3) est la plus efficace des fonctions de copie de chaîne qui effectue une troncation ». Mais aussi que « cette fonction n’est fournie dans aucune bibliothèque, lisez la section des exemples pour en trouver une implémentation de référence ». On va de surprise en surprise ! Petite friandise pour le lecteur :

5. strcpy_s

La fonction strcpy_s existe depuis un certain temps sous Windows, en tant qu’extension spécifique. Mais elle fait aussi partie du standard C11.

La version Windows a le même comportement que strlcpy, sauf qu’elle renvoie un code d’erreur si le buffer source ou le buffer de destination sont des pointeurs nuls, si la taille est de zéro, ou si une troncation devait avoir lieu (auquel cas le pointeur de destination est positionné à la chaîne vide). Le comportement est spécifiquement indéfini si le buffer d’entrée et de sortie se chevauchent, ce qui était implicite pour toutes les fonctions précédentes de par l’usage du mot clef restrict.

La version C11 reprend et normalise le comportement de la version Windows. Elle n’est disponible que si la macro __STDC_LIB_EXT1__ est définie et que la macro __STDC_WANT_LIB_EXT1__ est positionnée à 1 par l’utilisateur avant d’inclure <string.h>.

Conclusion

D’après [1], le choix d’utiliser une valeur sentinelle pour encoder la taille d’une chaîne de caractères plutôt que d’utiliser des Pascal string (c’est-à-dire une structure contenant la taille de la chaîne suivie de chacun des octets de la chaîne), serait « l’erreur d’un octet la plus coûteuse de l’histoire » (de l’informatique).

Pour ma part, je ne peux que constater avec émerveillement à quel point la copie de chaîne a traversé les standards, faisant d’elle un témoin des différentes étapes de raffinement d’une API, ce qui nous permet au minimum de conclure que, oui, concevoir une bonne API est une activité complexe qui demande du savoir-faire et de l’expérience, expérience qu’il est difficile d’avoir quand on conçoit un des premiers langages de haut niveau pour des machines qui n’ont pas exactement les mêmes caractéristiques que l’ordinateur portable utilisé pour rédiger cet article.

Et pour les curieux, je ne peux que conseiller au lecteur d’invoquer :

Référence

[1] Kamp, Poul-Henning , « The most expensive One-Byte mistake », ACM Queue 9, 25 juillet 2011