Memcpy () dans la programmation sécurisée?

Je suis récemment tombé sur un article qui prétend que Microsoft interdit la fonction memcpy() dans ses magasins de programmation sécurisés. Je comprends les vulnérabilités inhérentes à la fonction, mais est-il nécessaire d’interdire totalement son utilisation?

Les programmes que j’écris doivent-ils éviter memcpy() ou simplement s’assurer qu’ils sont utilisés en toute sécurité? Quelles alternatives existent offrant une fonctionnalité similaire mais plus sûre?

Microsoft fournit des alternatives à memcpy et wmemcpy qui valident leurs parameters.

memcpy_s dit: “Hmm, avant que je lis cette adresse, laissez-moi vérifier par moi-même que ce n’est pas un pointeur nul; et avant d’écrire à cette adresse, je recommencerai ce test. Je comparerai également le nombre d’octets I ont été priés de copier à la taille revendiquée de la destination; si et seulement si l’appel réussit tous ces tests dois-je effectuer la copie. ”

memcpy dit “Insérez la destination dans un registre, insérez la source dans un registre, insérez le nombre dans un registre, effectuez MOVSB ​​ou MOVSW.” (Exemple sur les géocités, pas longtemps pour ce monde: http://www.geocities.com/siliconvalley/park/3230/x86asm/asml1013.html )

Edit: pour un exemple dans la nature de l’approche de votre rêve par rapport à la mémoire, considérons OpenSolaris, où memcpy est défini (pour certaines configurations) en termes de bcopy , et bcopy (pour certaines configurations) est …

 void 33 bcopy(from, to, count) 34 #ifdef vax 35 unsigned char *from, *to; 36 int count; 37 { 38 39 asm(" movc3 12(ap),*4(ap),*8(ap)"); 40 } 41 #else 42 #ifdef u3b /* movblkb only works with register args */ 43 unsigned char *from, *to; 44 int count; 45 { 46 asm(" movblkb %r6, %r8, %r7"); 47 } 48 #else 49 unsigned char *from, *to; 50 int count; 51 { 52 while ((count--) > 0) 53 *to++ = *from++; 54 } 55 #endif 

Edit: Merci, Millie Smith! Voici ce qui était sur la page geocities que j’ai liée ci-dessus:

MOVS

L’instruction movs est utilisée pour copier la chaîne source dans la destination (oui, copier, pas déplacer). Cette instruction a deux variantes: movsb et movsw. Movsb (“move ssortingng byte”) se déplace d’un octet à la fois, tandis que movsw se déplace de deux octets à la fois.

Puisque nous souhaitons déplacer plusieurs octets à la fois, ces instructions movs sont effectuées par lots en utilisant le préfixe rep. Le nombre de mouvements est spécifié par le registre CX. Voir l’exemple ci-dessous:

 : lds si, [src] les di, [dest] cld mov cx, 100 rep movsb : 

Cet exemple copiera 100 octets de src vers dest. Si vous remplacez movsb par movsw, vous copiez plutôt 200 octets. Si vous supprimez le préfixe rep, le registre CX n’aura aucun effet. Vous allez déplacer un octet (si c’est movsb, ou 2 octets s’il est movsw).

Une tronçonneuse, si elle est utilisée correctement, est sans danger. Même chose avec memcpy (). Mais dans les deux cas, si vous frappez un clou, il peut voler et vous blesser.

En résumé, memcpy () est requirejs pour l’informatique de bas niveau et ne disparaîtra pas, mais pour la programmation de haut niveau, vous n’en avez pas besoin. Il n’y a pas de memcpy () en Python.

Ne t’embête pas. Les alternatives de Microsofts ne sont pas tellement meilleures. La valeur principale est que cela rend votre code inaccessible à Linux. Microsoft gagne beaucoup plus sur le système d’exploitation vendu à vos clients que sur la copie de Visual C ++ que vous avez achetée.

L’article lui-même décrit une alternative plus sûre: memcpy_s, qui vous oblige à spécifier la longueur maximale de la cible. Lorsque ce nombre est fourni indépendamment du nombre d’octets à copier, il sert de barrière pour empêcher le débordement de mémoire tampon. Bien sûr, vous pouvez en abuser en donnant le même numéro aux deux.

En interdisant memcpy () dans mon code, je suis un meilleur programmeur et mon application plus sûre ou tout simplement plus incompatible. Je ne sais pas si MS veut vraiment changer quoi que ce soit ou simplement rendre tout nouveau code C incompatible avec d’autres compilateurs. Btw. MS fait cette astuce sur de nombreuses fonctions et c’est assez énervant. strcpy -> strcpy_s -> SsortingngCchCopy.

Je pense que C devrait laisser une option au programmeur pour tirer son propre pied. La gestion manuelle de la mémoire est sécurisée si elle est effectuée correctement.

Vous l’avez dit vous-même: “Microsoft interdit la fonction memcpy () dans ses magasins de programmation sécurisés , je comprends les vulnérabilités inhérentes à cette fonction “,

memcpy () et une pléthore d’autres fonctions standard sont connues pour causer des vulnérabilités, alors pourquoi un magasin de programmation sécurisé autoriserait-il leur utilisation lorsqu’une amélioration (même incrémentale) est sortingviale?

Sans aucun doute, dans leurs efforts pour améliorer la sécurité de leurs propres produits, les examens du code ont clairement indiqué que ces fonctions étaient responsables d’une part importante des vulnérabilités, des débordements de mémoire tampon, etc. Au lieu de créer des enveloppes à usage interne, elles les ont introduites dans la bibliothèque standard et ajouté un avertissement du compilateur (pas une interdiction) pour le bénéfice de tous.

L’alternative est d’appeler memcpy_s

Si vous utilisez des versions plus anciennes, telles que C99 ou C ++ 98, ou sous Solaris, vous ne pouvez pas utiliser memcpy_s, à moins que la bibliothèque Safe C ne soit installée.

memcpy_s () est une implémentation spécifique à Microsoft qui n’existe pas sur les implémentations non-MS, y compris ANSI, antérieure à C11, selon leurs propres normes.

Je vais laisser de côté le contenu pro-MS et anti-MS, car ce n’est pas pertinent.

memmove () est de toute façon une meilleure solution car elle a résolu le problème du chevauchement. memmove_s () est plus robuste, mais encore une fois, uniquement si vous êtes en C11 ou plus tard.

Vous êtes censé utiliser memcpy_s () à la place. Le même type de versions existe pour une variété d’autres fonctions considérées comme non sécurisées.