Sinon, je vous rappelle qu'il y a MISC, *LE* magazine de la sécurité, dont le 3ème numéro est en kioske depuis le 29 Juin :)
Et concernant son contenu, pas de mauvaise surprise au moins...
Et bien si justement, puisqu'avec un strcpy on prend le risque d'avoir le buffer copié plus grand que celui de destination. Il ne faut pas réfléchir plus loin, PAS DE strcpy.
Evidémment, pas de strcpy. La dessus on est tous d'accord ;)
Par contre, les fonctions strn*, comme l'explique pappy, peuvent elles aussi, si elles sont mal employées etre des sources de danger.
A partir du moment que ta chaine peut etre non-terminée, tu cours des risques insensés à l'utiliser.
Le problème c'est que la personne qui a programmé ne sait pas lire la page de man
Certes, mais si tt le monde lisait correctement les mans et programmaient sans failles, y'aurait pas de problème et on vivraient tous dans le meilleur des mondes :)
Je rappelle pour info que le man de strcpy lui aussi prévient des dangers d'une mauvaise utilisation de cette derniere.
A là limite, si quitte à proposer une alternative à strcpy, autant proposer les fonctions strl*(et encore, il arrive bien souvent que la taille spécifiée en 3ème paramètre soit fournie de façon dangereuse par le programmeur(qu'elle soit manipulable)...)...
Réfléchis 3 secondes...
strcpy est utilisé, certes.
Mais si les choses se passaient bien, arg1 serait copié dans buffer. arg1 a une taille de 8 octets, buffer de 12. C'est pas le fait que strcpy soit utilisé qui pose problème ici.
La problématique ici, c'est les 2 appels successif à strncpy sans 0 terminal.
qui entraine le fait que arg1 se retrouve avec une taille supérieure à 8.
# MISC
Posté par Iluvatar . En réponse à la dépêche Login Hors Série "Spécial Sécurité". Évalué à 10.
Et concernant son contenu, pas de mauvaise surprise au moins...
[^] # Re: Un autre ? Pas de pb :)
Posté par Iluvatar . En réponse à la dépêche Failles de sécurité dans openssl. Évalué à 1.
utilisée ne pose pas de problème.
Pourtant, démontrer que
char buf[42];
strcpy(buf, "hello");
n'est pas vulnérable ne démontre pas pour autant que strcpy est une *bonne* fonction.
Il faut juste noter que strncpy, tout comme strcpy sont des fonctions souvent mal utilisées, et ce malgré les avertissements dans les mans respectifs.
[^] # Re: un exemple
Posté par Iluvatar . En réponse à la dépêche Failles de sécurité dans openssl. Évalué à 4.
Evidémment, pas de strcpy. La dessus on est tous d'accord ;)
Par contre, les fonctions strn*, comme l'explique pappy, peuvent elles aussi, si elles sont mal employées etre des sources de danger.
A partir du moment que ta chaine peut etre non-terminée, tu cours des risques insensés à l'utiliser.
Le problème c'est que la personne qui a programmé ne sait pas lire la page de man
Certes, mais si tt le monde lisait correctement les mans et programmaient sans failles, y'aurait pas de problème et on vivraient tous dans le meilleur des mondes :)
Je rappelle pour info que le man de strcpy lui aussi prévient des dangers d'une mauvaise utilisation de cette derniere.
A là limite, si quitte à proposer une alternative à strcpy, autant proposer les fonctions strl*(et encore, il arrive bien souvent que la taille spécifiée en 3ème paramètre soit fournie de façon dangereuse par le programmeur(qu'elle soit manipulable)...)...
[^] # Re: Un autre ? Pas de pb :)
Posté par Iluvatar . En réponse à la dépêche Failles de sécurité dans openssl. Évalué à 0.
Un seul mot, In-dis-pen-sable! :)
[^] # Re: un exemple
Posté par Iluvatar . En réponse à la dépêche Failles de sécurité dans openssl. Évalué à 0.
strcpy est utilisé, certes.
Mais si les choses se passaient bien, arg1 serait copié dans buffer. arg1 a une taille de 8 octets, buffer de 12. C'est pas le fait que strcpy soit utilisé qui pose problème ici.
La problématique ici, c'est les 2 appels successif à strncpy sans 0 terminal.
qui entraine le fait que arg1 se retrouve avec une taille supérieure à 8.