la fonction memmove_s de string.h

**kakibend** · 18/12/2007, 11h38

Bonjour,

J'aimerai savoir si la fonction memmove_s est utilisée par l'un d'entre vous et si c'est le cas en utilisant quel compilateur?? (j'ai regardé dans gcc il n'y est pas)

Merci

**Melem** · 18/12/2007, 11h53

Ces fonctions (strcpy_s, sprintf_s) sont des extensions Microsoft à la librairie standard du C. Ce sont des améliorations, en termes de sécurité au niveau du code, des fonctions standards strcpy, sprintf, ... qui ne permettent pas par exemple de spécifier la taille du buffer qui va recevoir les données. Personnellement, j'utilise ces fonctions mais pas dans des programmes Open Source

.

**kakibend** · 18/12/2007, 11h56

Oui c'est bien ce que j'ai remarqué par contre j'aimerai l'utiliser pour linux (en open source donc) mais elle n'apparaît pas dans les librairies standards du C

Envoyé par Melem

Ces fonctions (strcpy_s, sprintf_s) sont des extensions Microsoft à la librairie standard du C. Ce sont des améliorations, en termes de sécurité au niveau du code, des fonctions standards strcpy, sprintf, ... qui ne permettent pas par exemple de spécifier la taille du buffer qui va recevoir les données. Personnellement, j'utilise ces fonctions mais pas dans des programmes Open Source

.

**Melem** · 18/12/2007, 12h05

Les fonctions de la librairie standard permettent d'écrire des programmes solides, si on sait bien se servir d'elles. Par exemple, utiliser _snprintf (C99) au lieu de sprintf, strncpy au lieu de strcpy, etc. Au pire, implémenter ses propres fonctions.

**kakibend** · 18/12/2007, 12h12

Oui je suis bien d'accord avec toi, par contre il existe desfonctions pour lesquels il existe toujours une problématique , la fonction que je recherche par exemple, memmove( ) comment tu veux la sécuriser sans réécrire le code source de memmove_s?? l'accès à la mémoire sous C est toujours problématique...

Envoyé par Melem

Les fonctions de la librairie standard permettent d'écrire des programmes solides, si on sait bien se servir d'elles. Par exemple, utiliser _snprintf (C99) au lieu de sprintf, strncpy au lieu de strcpy, etc. Au pire, implémenter ses propres fonctions.

**Thierry Chappuis** · 18/12/2007, 12h20

Envoyé par kakibend

Oui je suis bien d'accord avec toi, par contre il existe desfonctions pour lesquels il existe toujours une problématique , la fonction que je recherche par exemple, memmove( ) comment tu veux la sécuriser sans réécrire le code source de memmove_s?? l'accès à la mémoire sous C est toujours problématique...

Une version sécurisée de memmove(), c'est pas non plus la mer à boire à implanter...

Envoyé par Melem

Les fonctions de la librairie standard permettent d'écrire des programmes solides, si on sait bien se servir d'elles. Par exemple, utiliser _snprintf (C99) au lieu de sprintf, strncpy au lieu de strcpy, etc. Au pire, implémenter ses propres fonctions.

C99 parle de snprintf() et non de _snprintf(), non?

Thierry

**souviron34** · 18/12/2007, 13h45

Envoyé par kakibend

Oui je suis bien d'accord avec toi, par contre il existe desfonctions pour lesquels il existe toujours une problématique , la fonction que je recherche par exemple, memmove( ) comment tu veux la sécuriser sans réécrire le code source de memmove_s?? l'accès à la mémoire sous C est toujours problématique...

en quoi elle te pose problème cette fonction ???????????

**kakibend** · 18/12/2007, 13h47

Bentout simplement c'est qu'elle n'est pas reconnu par mon compilateur (je parle là de GCC 4.2.2) vu que le header string.h ne l'implémente pas encore pour le langage C...

Envoyé par souviron34

en quoi elle te pose problème cette fonction ???????????

**souviron34** · 18/12/2007, 13h55

je parlais de memmove..

standard etc...

En quoi elle te pose problème au niveau sécurité ??

**Melem** · 18/12/2007, 14h03

Envoyé par Thierry Chappuis

C99 parle de snprintf() et non de _snprintf(), non?

c'est ça.

Envoyé par souviron34

je parlais de memmove..

standard etc...

En quoi elle te pose problème au niveau sécurité ??

Parce qu'elle n'offre aucun moyen de spécifier la taille du buffer de destination.

**kakibend** · 18/12/2007, 14h06

Les fonctions utilisant la mémoire sous C ont toutes été déprécies en faveur des fonctions xxx_s pour empêcher les buffer overflow. Un buffer Overflow permet à un malatentioné de prendre le contrôle de la machine en passant par des droits root..et il y a beaucoup d'exemples sur le net qui expliquent ce genre d'attaque

Envoyé par souviron34

je parlais de memmove..

standard etc...

En quoi elle te pose problème au niveau sécurité ??

**kakibend** · 18/12/2007, 14h07

Envoyé par Melem

c'est ça.

Parce qu'elle n'offre aucun moyen de spécifier la taille du buffer de destination.

Voilà! Taille de buffer de destination non spécifié == Buffer Overflow

**Melem** · 18/12/2007, 14h15

Envoyé par kakibend

Bentout simplement c'est qu'elle n'est pas reconnu par mon compilateur (je parle là de GCC 4.2.2) vu que le header string.h ne l'implémente pas encore pour le langage C...

Tout d'abord, il n'y a pas d'implémentation de fonction dans un fichier .h. Un fichier d'en-tête ne contient que des déclarations de fonctions, des définitions de types, de macros, etc. L'implémentation c'est dans les fichiers .c. Ensuite, comme je l'ai déja dit plus haut ces fonctions sont des extensions de Microsoft à la librairie du C, elles ne sont pas tenues à être connues de tous les compilateurs. Et enfin, si tu veux des fonctions "sécurisées" tu n'as qu'à implémenter les tiennes. Mais jusqu'où va cette sécurité en fait? Si le programme est bien écrit, il n'y a pas vraiment de différence à utiliser memcpy ou memcpy_s ...

**jowo** · 18/12/2007, 14h18

Envoyé par kakibend

Voilà! Taille de buffer de destination non spécifié == Buffer Overflow

Parle-t-on de la même fonction?

#include <string.h>

void *memmove (void *dest, const void *src, size_t n);

DESCRIPTION
La fonction memmove() copie n octets de la zone de mémoire src vers la zone dest. Les deux zones peuvent se chevaucher.

Il est clair que si on lui balance n'importe quoi comme paramètres, on aura des petits soucis.

**Melem** · 18/12/2007, 14h22

Envoyé par kakibend

Les fonctions utilisant la mémoire sous C ont toutes été déprécies en faveur des fonctions xxx_s pour empêcher les buffer overflow. Un buffer Overflow permet à un malatentioné de prendre le contrôle de la machine en passant par des droits root..et il y a beaucoup d'exemples sur le net qui expliquent ce genre d'attaque

Le risque du buffer overflow face à un utilisateur mal intentionné se situe au niveau des entrées, pas dans les entrailles du programme. Dans un programme bien conçu il n'y a aucun risque d'un tel danger même en utilisant strcpy ou memcpy etc.

**souviron34** · 18/12/2007, 14h22

et quand tu fais un strcpy , strcat, ou n'importe quelle fonction ???

En C en général il faut savoir ce qu'on fait...

Comme dirait Emmanuel, c'est pas pour les frileux...

Si tu fais une copie ou un mouvement mémoire sans savoir dans quoi tu le places, too bad...

Les fonctions de la bibliothèque sont génériques, utilisées partout..

Libre à toi de refaire ce que tu veux, mais je trouve particulièrement ... de vouloir remplacer des fonctions standards.. plutôt que de bien les utiliser..

**souviron34** · 18/12/2007, 14h27

Envoyé par kakibend

Les fonctions utilisant la mémoire sous C ont toutes été déprécies en faveur des fonctions xxx_s pour empêcher les buffer overflow. Un buffer Overflow permet à un malatentioné de prendre le contrôle de la machine en passant par des droits root..et il y a beaucoup d'exemples sur le net qui expliquent ce genre d'attaque

mdrrrr

j'aimerais bien :

Primo que tu me montres un lien disant que ces fonctions sont "dépréciées"
Secondo - à part pour M$, et c'est dû à son système de sécurité lâche, et non à l'utilisation de telle ou telle fonction de bibliothèques standards de langages standards - un exemple de prise de contrôle d'une machine par un memmove

**Melem** · 18/12/2007, 14h27

Envoyé par jowo

#include <string.h>

void *memmove (void *dest, const void *src, size_t n);

DESCRIPTION
La fonction memmove() copie n octets de la zone de mémoire src vers la zone dest. Les deux zones peuvent se chevaucher.

Il est clair que si on lui balance n'importe quoi comme paramètres, on aura des petits soucis.

Bien dit. Et pareil pour les fonctions xxx_s.

**kakibend** · 18/12/2007, 15h30

Totalement d'accord avec toi mais il ne faut pas nier quand même qu'il existe des fonctions "plus sécurisée" qu'est-ce qui empêche de les utiliser dans ce cas si ces fonctions sont normalisées??

Envoyé par souviron34

et quand tu fais un strcpy , strcat, ou n'importe quelle fonction ???

En C en général il faut savoir ce qu'on fait...

Comme dirait Emmanuel, c'est pas pour les frileux...

Si tu fais une copie ou un mouvement mémoire sans savoir dans quoi tu le places, too bad...

Les fonctions de la bibliothèque sont génériques, utilisées partout..

Libre à toi de refaire ce que tu veux, mais je trouve particulièrement ... de vouloir remplacer des fonctions standards.. plutôt que de bien les utiliser..