Fonctions critiques C

Le
diablo
Salut tout le monde !

Je cherche juste une liste de fonctions C critiques, du genre scanf etc,
en bref, les fonctions à surveiller de très près quand on code
pour éviter les buffer overflow et failles en tout genre.

Ty :)
--
-uTb#`diablo PWed by GNU/Linux Debian on Diablo
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
espie
Le #1599899
In article diablo
Salut tout le monde !

Je cherche juste une liste de fonctions C critiques, du genre scanf etc,
en bref, les fonctions à surveiller de très près quand on code
pour éviter les buffer overflow et failles en tout genre.


http://www.dwheeler.com/flawfinder/

constitue un debut "simple".

Pour les failles en general, il n'y a pas de fonctions particulieres a
surveiller, il faut faire attention tout le temps.

Quelques conseils en vrac, relativement independants du langage.

- avoir un vrai modele de securite. Typiquement, tu manipules de l'information.
Il faut savoir d'ou elle vient. Et tu l'utilises pour accomplir certaines
actions. Le tout dans un certain contexte. Il faut lister les diverses
identites (roles) impliquees: qui donne quoi comme info, qui peut faire
quoi, et essayer d'en sortir le modele le plus simple possible.

- avoir une gestion d'erreurs simple ET testee. Verifier tous les cas
d'erreurs, et etre sur de ce qui se passe en cas de probleme.

- tous les trous techniques viennent d'une ambiguite dans le code: on peut
le lire selon son fonctionnement normal, a un certain niveau d'abstraction,
et on peut le lire de facon transverse, en passant a un niveau d'abstraction
different. Par exemple, les buffer-overflow correspondent a deux visions de
la memoire, une niveau machine, et une niveau algorithmique qui ne coincident
pas, et les race conditions correspondent a deux visions du deroulement
du programme... il faut s'habituer a avoir `plusieurs lectures' de son code.
Pour limiter la casse, il faut s'assurer qu'on a bien prevu tous les cas.
La facon la plus simple, c'est de limiter le nombre de cas: faire des tests
clairs de taille de tampon, histoire d'etre sur qu'on ne debordera pas;
rajouter les bonnes barrieres entre processus/thread, histoire d'etre sur
d'avoir toutes les executions possibles; avoir le code de gestion d'erreur
le plus simple possible, histoire de limiter le nombre de chemins a tester...

Cote genie logiciel, il est bon d'avoir du code le plus standard possible.
Si on a des idiomes surs, il faut les utiliser, s'arranger pour qu'ils
aient toujours la meme apparence dans le code, histoire que toute
deviation saute aux yeux. Les grosses astuces sont l'ennemi de la securite:
elles rendent le code complique a lire, et on risque de se focaliser sur
un point de detail et de passer a cote d'un gros probleme.

Il y a une regle des 90%. Dans un logiciel, 90% du code est sans importance
pour la performance du logiciel. C'est les 10% qui restent qui sont importants.
C'est donc une bonne idee de `blinder' son code, d'ecrire les choses de la
facon la plus simple possible, et ensuite de se focaliser sur les 10% ou
les performances se trouvent (en utilisant des outils, parce que c'est pas
du tout intuitif). Pour la securite, c'est un peu pareil... il y a 10% du
logiciel qui sont vraiment critiques, ou il faut reflechir a ce qu'on fait,
et 90% du logiciel ou on peut faire du code tres standard et tres simple.
La encore, des outils peuvent aider. Les tests de couverture sont tres
importants: s'assurer qu'on sait comment passer par 100% du code.... c'est
toujours dans le 1% non teste (et donc faux) que le pirate va passer.

Je crois aussi beaucoup aux bienfaits de l'audit: montrer son code a d'autres
personnes est une excellente facon d'eviter les ennuis, et d'apprendre de
nouvelles techniques. ;-)

diablo
Le #1755586
In article diablo
Salut tout le monde !

Je cherche juste une liste de fonctions C critiques, du genre scanf etc,
en bref, les fonctions à surveiller de très près quand on code
pour éviter les buffer overflow et failles en tout genre.


http://www.dwheeler.com/flawfinder/

constitue un debut "simple".

Pour les failles en general, il n'y a pas de fonctions particulieres a
surveiller, il faut faire attention tout le temps.

Quelques conseils en vrac, relativement independants du langage.

- avoir un vrai modele de securite. Typiquement, tu manipules de l'information.
Il faut savoir d'ou elle vient. Et tu l'utilises pour accomplir certaines
actions. Le tout dans un certain contexte. Il faut lister les diverses
identites (roles) impliquees: qui donne quoi comme info, qui peut faire
quoi, et essayer d'en sortir le modele le plus simple possible.

- avoir une gestion d'erreurs simple ET testee. Verifier tous les cas
d'erreurs, et etre sur de ce qui se passe en cas de probleme.

- tous les trous techniques viennent d'une ambiguite dans le code: on peut
le lire selon son fonctionnement normal, a un certain niveau d'abstraction,
et on peut le lire de facon transverse, en passant a un niveau d'abstraction
different. Par exemple, les buffer-overflow correspondent a deux visions de
la memoire, une niveau machine, et une niveau algorithmique qui ne coincident
pas, et les race conditions correspondent a deux visions du deroulement
du programme... il faut s'habituer a avoir `plusieurs lectures' de son code.
Pour limiter la casse, il faut s'assurer qu'on a bien prevu tous les cas.
La facon la plus simple, c'est de limiter le nombre de cas: faire des tests
clairs de taille de tampon, histoire d'etre sur qu'on ne debordera pas;
rajouter les bonnes barrieres entre processus/thread, histoire d'etre sur
d'avoir toutes les executions possibles; avoir le code de gestion d'erreur
le plus simple possible, histoire de limiter le nombre de chemins a tester...

Cote genie logiciel, il est bon d'avoir du code le plus standard possible.
Si on a des idiomes surs, il faut les utiliser, s'arranger pour qu'ils
aient toujours la meme apparence dans le code, histoire que toute
deviation saute aux yeux. Les grosses astuces sont l'ennemi de la securite:
elles rendent le code complique a lire, et on risque de se focaliser sur
un point de detail et de passer a cote d'un gros probleme.

Il y a une regle des 90%. Dans un logiciel, 90% du code est sans importance
pour la performance du logiciel. C'est les 10% qui restent qui sont importants.
C'est donc une bonne idee de `blinder' son code, d'ecrire les choses de la
facon la plus simple possible, et ensuite de se focaliser sur les 10% ou
les performances se trouvent (en utilisant des outils, parce que c'est pas
du tout intuitif). Pour la securite, c'est un peu pareil... il y a 10% du
logiciel qui sont vraiment critiques, ou il faut reflechir a ce qu'on fait,
et 90% du logiciel ou on peut faire du code tres standard et tres simple.
La encore, des outils peuvent aider. Les tests de couverture sont tres
importants: s'assurer qu'on sait comment passer par 100% du code.... c'est
toujours dans le 1% non teste (et donc faux) que le pirate va passer.

Je crois aussi beaucoup aux bienfaits de l'audit: montrer son code a d'autres
personnes est une excellente facon d'eviter les ennuis, et d'apprendre de
nouvelles techniques. ;-)


merci pour ton aide et ton temps consacré à mon problème :)
++

--
-uTb#`diablo PWed by GNU/Linux Debian on Diablo


Publicité
Poster une réponse
Anonyme