Salut mon cher journal.
Je t'écris parce que je recherche des liens vers des documents traitant de la programmation robuste, ou plus spécialement des problèmes de sécurité avec le langage C.
J'ai été faire un tour sur le site du CERT,
https://www.securecoding.cert.org/confluence/display/seccode(...)
Mais je suis vraiment déçu, il y a pas mal de conneries et d'inexactitudes.
Donc, ce serait génial si tu pouvais me donner des liens vers des documents donnant des conseils pour écrire du code robuste/sûr (fonctions, gestion mémoire, environnement, race condition, etc) en C.
Merci!
Journal Programmation robuste
7
mar.
2007
# libapr
Posté par mathieu mathieu (site web personnel) . Évalué à 1.
ca permet d'avoir un code plus lisible, plus simple et plus robuste. les pools permettent d'éviter bcp de leaks, de depassements de buffer etc.
# Je n'aurais qu'un mot ...
Posté par Guinns . Évalué à 1.
http://linuxprocess.free.fr/documents.php?section=Programmat(...)
[^] # Re: Moi aussi
Posté par Bruno Michel (site web personnel) . Évalué à 2.
http://www.dwheeler.com/secure-programs/
# Un livre ca va ?
Posté par pasBill pasGates . Évalué à 9.
Oui je sais c'est MS c'est le mal absolu, mais le bouquin contient plein d'infos utiles et explications sur quoi faire/ne pas faire.
[^] # Re: Un livre ca va ?
Posté par herodiade . Évalué à 10.
[^] # Re: Un livre ca va ?
Posté par Nicolas Schoonbroodt . Évalué à 2.
MS c'est le mal absolu, et c'est pBpG qui le dit !
[^] # Re: Un livre ca va ?
Posté par GCN (site web personnel) . Évalué à 1.
[^] # Re: Un livre ca va ?
Posté par CrEv (site web personnel) . Évalué à 3.
Oui, MS est le mal absolu mais pour moi MS Press ne l'est pas du tout.
Il existe plusieurs bouquins pas trop mal chez eux et que ce soit marqué crosoft ou non, cela ne change rien à la qualité pour une fois ;)
note : je n'ai pas celui dont tu parle (d'ailleurs pour ceux qui cherchent, l'isbn de l'édition française est : 2 10 006750 8) mais celui-ci : http://www.amazon.fr/Tout-sur-code-concevoir-logiciel/dp/210(...) et j'avoue avoir été très agréablement surpris ;-)
[^] # Re: Un livre ca va ?
Posté par beagf (site web personnel) . Évalué à 4.
Je dois avouer que j'avais éclaté de rire en voyant code sans bug et chef de projet à microsoft cote-à-cote, et sa m'avait poussé à emprunter et lire le bouquin.
Ce fut la lecture la plus interessante que j'ai jamais eu sur le sujet. Le bouquin était vraiment bon et traitait bien le sujet, avec du code très propre qui marchait bien.
Depuis je me dit que chez microsoft, soit il ne savent pas exploité les talents qu'ils on chez eux, soit ils font exprès de rajouter des bugs... (phrase gratuite je le sais...)
Bref, chez microsoft press il y a de très bon bouquins, et même si le sujet peut preter à rire par rapport au logiciel rééllement produit, lisez le bouquin avant de vous faire une opinion.
(si quelqu'un connait le titre du bouquin en question, sa m'interesserais de le relire)
[^] # Re: Un livre ca va ?
Posté par GPH (site web personnel) . Évalué à 4.
[^] # Re: Un livre ca va ?
Posté par lolop (site web personnel) . Évalué à 2.
http://www.google.fr/search?q=Steve+Maguire
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Un livre ca va ?
Posté par Olivier Guerrier . Évalué à 2.
# Vu sur securecoding.org
Posté par Uriel Corfa . Évalué à 5.
Ca inspire confiance ! :)
[^] # Re: Vu sur securecoding.org
Posté par Raphaël G. (site web personnel) . Évalué à 2.
Il récupère des données de la base de donnée, et ne vérifie pas ce qui est retourné ;)
Bref, ça pue le code porky pas E_STRICT ready...
# Tu a faim de liens coquin...? (Vu sur @NetBSD-help)
Posté par kowalsky . Évalué à 10.
Je resume en français:
Un Monsieur, George Georgalis, se pose des questions pour ces codeurs:
http://mail-index.netbsd.org/netbsd-help/2007/01/23/0000.htm(...)
Le monsieur, qui ne pose jamais de questions sans s'etre posé
de questions fournit quelque reponse avec la question:
http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm
[http://www.dwheeler.com/secure-programs/ Secure Programming for Linux and Unix HOWTO -- Creating Secure Software]
[http://www.faqs.org/docs/artu/ch01s06.html Basics of the Unix Philosophy]
[http://www.shelldorado.com/ good coding practices for Bourne Shell and Korn Shell script programmers.]
[http://www-128.ibm.com/developerworks/aix/library/au-hook_du(...) Best practices for programming in C]
[http://stommel.tamu.edu/~baum/programming.html Programming Texts and Tutorials] -- meta site
[http://mindprod.com/jgloss/unmain.html unmaintainable code]
Il s'en suit un echange tres interessant:
http://thread.gmane.org/gmane.os.netbsd.help/15970/focus=159(...)
Le monsieur, qui etait apparement tres content d'avoir reçut
quelque reponse sur differente list il me semble, nous gratifie
d'un resume :
== Near Term Programming and Unix Operating Systems ==
Overview of techniques and strategies -- when and why they are useful
* [http://cm.bell-labs.com/cm/cs/who/dmr/cacm.html The UNIX Time-Sharing System] -- D. M. Ritchie and K. Thompson
* [http://www.dwheeler.com/secure-programs/ Secure Programming for Linux and Unix HOWTO -- Creating Secure Software]
* [http://www.faqs.org/docs/artu/ch01s06.html Basics of the Unix Philosophy] from [http://www.faqs.org/docs/artu/ The Art of Unix Programming]
* [http://www.shelldorado.com/ good coding practices for Bourne Shell and Korn Shell script programmers.]
* [http://www-128.ibm.com/developerworks/aix/library/au-hook_du(...) Best practices for programming in C]
* [http://www.hacknot.info/hacknot/action/showEntry?eid=85 Debugging 101]
== What not to do ==
* [http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm A Taxonomy for "Bad Code Smells"]
* [http://mindprod.com/jgloss/unmain.html unmaintainable code]
== Alternate Technique ==
* [http://www.methodsandtools.com/archive/archive.php?id=10 Will Pair Programming Really Improve Your Project?]
* [http://c2.com/doc/oopsla89/paper.html A Laboratory For Teaching Object-Oriented Thinking]
* [http://www.extremeprogramming.org/ Extreme Programming] -- a deliberate and disciplined approach
== Reference ==
* [http://www.nrbook.com/a/bookfpdf.html Numerical Recipes in Fortran 77]
* [http://www.nrbook.com/a/bookf90pdf.html Numerical Recipes in Fortran 90]
* [http://www.nrbook.com/abramowitz_and_stegun/ Abramowitz and Stegun: Handbook of Mathematical Functions]
== Abstract ==
* [http://www.ibiblio.org/obp/thinkCS/cpp/english/index.htm How To Think Like A Computer Scientist]
* [http://www.theserverside.com/tt/articles/content/BuildManage(...) Best Practices for Risk-Free Deployment]
* [http://en.wikipedia.org/wiki/Design_Patterns Design Patterns: Elements of Reusable Object-Oriented Software] (also the [http://www.tml.tkk.fi/~pnr/GoF-models/html/ GoF Patterns])
* [http://www.cs.wustl.edu/~schmidt/tutorials-patterns.html Design Pattern Tutorials] (see [http://www.cs.wustl.edu/~schmidt/PDF/patterns-intro4.pdf Introduction to Design Patterns]
* [http://www.datingdesignpatterns.com/intro.html Dating Design Patterns] -- a tangible implementation
* [http://www.maplefish.com/todd/papers/Experiences.html Experiences] -- A Pattern Language for User Interface Design
== The Lighter Side ==
* [http://www.cryptonomicon.com/beginning.html In the Beginning was the Command Line] by Neal Stephenson
* [http://research.microsoft.com/~daniel/unix-haters.html The UNIX-HATERS Handbook]
* [http://kuoi.asui.uidaho.edu/~kamikaze/doc/kvik.html The Kvikkalkul Programming Language]
* a [http://www.cadenhead.org/book/homepage24/kvikkalkul/kvik2c.h(...) Kvikkalkul to C Translator]
* a Kvikkalkul version of [http://www.99-bottles-of-beer.net/k.html#Kvikkalkul 99 bottles of beer]
== Meta Resource ==
* [http://www.softdevarticles.com/ Software Development Articles Directory]
* [http://stommel.tamu.edu/~baum/programming.html Programming Texts and Tutorials]
== Books ==
* [http://www-cs-faculty.stanford.edu/~knuth/taocp.html The Art of Computer Programming (TAOCP)]
Certain liens archi sont connu, d'autre moins, certain sont même rigolo.
Faite chauffer les imprimante.
Bonne lecture. ( je conseille aussi de lire l'echange de mail )
[^] # Re: Tu a faim de liens coquin...? (Vu sur @NetBSD-help)
Posté par Krunch (site web personnel) . Évalué à 2.
http://www.owasp.org/index.php/Category:OWASP_Guide_Project (bon c'est pas trop C)
http://www.ruxcon.org.au/files/2006/unusual_bugs.pdf
http://nob.cs.ucdavis.edu/bishop/secprog/
(j'ai pas lu la moitié mais doit y avoir des trucs intéressants là dedans et doit y avoir moyen de retrouver chaque papier via Google)
Il existe aussi un certains nombre de blogs sur lesquels passent des exemples de code mal écrit qui sont fort instructifs ainsi que des exemples de bonnes pratiques de programmation.
http://blogs.23.nu/ilja/stories/13882/
http://taossa.com/index.php/2006/12/19/fun-with-impersonatio(...)
http://steve.yegge.googlepages.com/practicing-programming
http://blogs.msdn.com/oldnewthing/archive/2004/04/22/118161.(...)
http://www.joelonsoftware.com/items/2003/10/13.html
http://blogs.msdn.com/larryosterman/archive/tags/Software+En(...)
http://www.hacknot.info/hacknot/action/showEntry?eid=47
http://worsethanfailure.com/Series/CodeSOD.aspx
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Mon expérience
Posté par Victor STINNER (site web personnel) . Évalué à 7.
#1 : Une compilation sans avertissement
Un avertissement est souvent un bug potentiel. Un comparaison nombre entier naturel et nombre entier relatif peut être une source de bug (integer overflow). => gcc -Wall -Wextra. Je trouve ça complètement débile que "-Wall" n'affiche pas ALL (tous) les avertissements... (avec gcc < 4 : -Wall -W). Pour les fanatiques : -Werror bloque la compilation à chaque avertissement.
#2 : Valgrind
Il faut que le programme ait zéro erreur dans Valgrind.
#3 : Analyse statique du code
Utiliser SPlint, Rats, Flawfinder, etc. pour trouver les portes d'entrées possible pour des failles.
http://www.haypocalc.com/wiki/Analyse_statique_de_code
### Fin de la partie basique ###
Maintenant il faut revoir le programme pour limiter les dégats. Ca peut être :
- Vérifier strictement toutes les entrées utilisateurs : clavier, réseau, variable d'environnement, fichier de configuration, fichier en entrée, événement X11, etc.
Voir les dégats que ça peut faire :
http://sam.zoy.org/zzuf/
http://www.haypocalc.com/wiki/Injection_de_code
http://www.haypocalc.com/wiki/Injection_de_SQL
http://www.haypocalc.com/wiki/Format_string_attack
- Vérifiez aussi le code de retour des fonctions, et particulier les fonctions systèmes (fopen, chdir, fork, etc.).
- Séparation des privilèges : séparer et limiter au maximum le code exécuté avec des privilèges elevés
- etc.
[^] # Re: Mon expérience
Posté par neologix . Évalué à 1.
Moi aussi.
Mais la logique de la gcc team c'est qu'ils considèrent qu'un programme peut parfaitement être correct même s'il se mange des warnings avec les options qui ne sont pas activées par -Wall.
En gros, si tu as des warnings avec -Wall, tu sais (a priori) que tu as un problème. Avec ls autres options, il y a des chances que ça te fasse perdre ton temps. Ca dépend de ton degré d'extrêmisme...
[^] # Re: Mon expérience
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
# Change de langage
Posté par grognon . Évalué à 2.
Je ne dis pas ça parce que je n'aime pas le C. Je programme presque exclusivement en C++, mais c'est justement cette expérience-là qui me fait dire : aucun programme écrit en C n'est robuste ou sécurisé. Il y a trop de failles intrinsèques au langage lui-même.
Je suis loin d'être un expert dans le domaine, mais voilà une petite recette personnelle pour éviter une grande partie des problèmes classiques :
* n'utilise aucun pointeur C. Elimine les * partout où c'est possible.
* ne gère jamais la mémoire toi-même.
* bannis toutes les fonctions d'entrée/sortie standards du C (genre printf)
* n'utilise jamais de tableaux en C.
C'est sûr. Quand on s'interdit tout ça, on se demande à quoi bon rester en C. Disons que ça doit servir de signal d'alerte. Dès qu'il y a une * ou des [ ] dans un code, il faut se poser la question de tous les cas particuliers. Une solution intermédiaire minimale, c'est d'utiliser une bibliothèque externe pour toutes ces notions.
Mais bon, ça reste des rustines collées sur un langage non fiable. Le fameux "bufferoverflow ", qui est le vice profond du C, est à l'origine de sans doute 95% des failles des logiciels actuels. Le C a été inventé à une époque où l'idée de robustesse n'avait pas encore percé. Conséquence : la sécurité en langage C est tout simplement une chimère.
La seule raison pour laquelle on reste sous ce langage, c'est la grande base de code existant, et le grand nombre de bibliothèques disponibles. Heureusement, ça change petit à petit. De moins en moins de programmeurs savent ce qu'est un pointeur, ni même ce que le terme de "gestion de la mémoire" peut signifier. Et je m'en réjouis.
Ah oui, juste pour la petite note : les outils comme valgrind sont très bons pour détecter certains types de problèmes précis, mais ils ne remplaceront jamais l'analyse détaillée par le programmeur de tous les cas particulier de son code. ça implique notamment de vérifier toutes les possibilités de pointeur qui ne sont pas à jour, de division par zéro, d'indice incorrect dans un tableau, etc. Une bonne pratique est de mettre des vérifications dans le code lui-même (par exemple sur tous les indices de tableau). Le gros piège, c'est de se dire : ah mais y'a de problème. L'indice est toujours inférieur à telle valeur parce que gnagnagna. Il vaut mieux mettre un bon gros test if sur l'indice pour être certain qu'il se comporte comme prévu.
D'ailleurs le problème de fond de la robustesse/sécurité, à mon avis, n'est pas de savoir quoi faire, mais de savoir si on est prêt à le faire : le coût à payer en temps supplémentaire de codage et en pollution du code est très élevé pour sécuriser vraiment un programme en C.
[^] # Re: Change de langage
Posté par Zenitram (site web personnel) . Évalué à 0.
Sauf qu'en C++, si tu programme sans l'héritage du C, c'est comme Java : jamais de pointeur.
Le code est aussi sûr entre un language C++ (voire C) codé avec les meme precautions (donc test si tu es a un buffer overflow automatique) qu'avec n'importe quel language.
Un exemple? En C++ ou Java (et bcp d'autres langauges), tu as une exception si tu demandes un index en dehors du tableau. Si tu ne sais pas gérer l'exception en C++ et que ton programme fait n'importe quoi, ben ce serap areil avec Java ou autre.
Maintenant que tu as fait ton argumentation, tu préconises quel langauge où ta critique du C++ n'est pas adaptable?
[^] # Re: Change de langage
Posté par lurker . Évalué à 6.
Euuuuuuuuh...
bash-3.1$ cat test.cpp
/* test.cpp */
int main() {
int *arr = new int[10];
arr[10] = 1;
delete []arr;
return 0;
}
bash-3.1$ g++ test.cpp
bash-3.1$ ./a.out
bash-3.1$ cat Test.java
/* Test.java */
public class Test {
public static void main(String args[]) {
int arr[] = new int[10];
arr[10] = 1;
}
}
bash-3.1$ javac Test.java
bash-3.1$ java Test
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 10
at Test.main(Test.java:4)
Tu vois pas de différence ?
[^] # Re: Change de langage
Posté par Frédéric COIFFIER . Évalué à 6.
[^] # Re: Change de langage
Posté par CrEv (site web personnel) . Évalué à 5.
[^] # Re: Change de langage
Posté par Troy McClure (site web personnel) . Évalué à 3.
[^] # Re: Change de langage
Posté par imalip . Évalué à 10.
Tu as deja entendu parler de l'embarqué ?
Perso ca me désole. Et encore plus de voir des gens qui s'en réjouissent.
[^] # Re: Change de langage
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Change de langage
Posté par Mildred (site web personnel) . Évalué à 2.
C'est quand la version 0.2 du compilateur ? De préférence une version qui ne quitte pas sans explication sur le code que j'écris :)
[^] # Re: Change de langage
Posté par M . Évalué à 2.
Y a aussi ada qui est (etait) utiliser dans les applis embarquées critiques.
Mais bon meme si le language genere des exceptions en cas de problème (debordement, ...), si elle ne sont pas correctement gerer par le programme le resultat est le meme : ca plante. Cf ariane 5
[^] # Re: Change de langage
Posté par Moogle . Évalué à 5.
Ce qui me désole, c'est justement que beaucoup de nouveaux programmeurs ne sachent plus utiliser les pointeurs. Maintenant, on code dans des langages super sécurisés à la base, mais au final tellement plus lents à l'exécution... Et avec tout ce travail prémaché, on en perd justement toutes les habitudes et les concepts qui font qu'on se soucie de l'aspect sécurité.
[^] # Re: Change de langage
Posté par Mildred (site web personnel) . Évalué à 3.
Bon, je ne connais pas trop, mais il y a quand même des langages sécurisés qui sont rapides. Je pense notament à Eiffel ou Lisaac qui permettent une programmation par contrats (Lisaac, ce n'est pas encore je crois) ... et compilent le code en C
Le C c'est bien car c'st un espèce d'assembleur portable. Mais a mon avis, c'est plus intéressant de programmer dans un langage de plus haut niveau qui traduit le code en C par la suite.
[^] # Re: Change de langage
Posté par Gniarf . Évalué à 6.
[^] # Re: Change de langage
Posté par M . Évalué à 6.
Et pourtant y a des logiciels en C qui ne sont pas codé avec les pieds qui on tres peu de faille : par exemple http://vsftpd.beasts.org/
n'utilise aucun pointeur C. Elimine les * partout où c'est possible.
Tu passes comment les parametres dans tes fonctions ?
En copiant tout sur la stack ?
Et les valeurs de retour, en utilisant des variables globales ?
* ne gère jamais la mémoire toi-même.
* bannis toutes les fonctions d'entrée/sortie standards du C (genre printf)
* n'utilise jamais de tableaux en C.
T'as des exemples de code C avec tes regles ?
Je serais curieux de voir ce que ca donne :)
(Il est bien entendu qu'il est hors de question d'utiliser des libs qui ne respectent pas ses regles, et que tu as donc recoder ta libc...)
[^] # Re: Change de langage
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il faut tout lire ...
"La première sécurité est la liberté"
[^] # Re: Change de langage
Posté par voodoo . Évalué à 1.
A cela on ajoute qmail, lighttpd, dovecot ... Et des applis qui n'ont pas le droit a l'erreur (validees par Astree http://www.astree.ens.fr/ par exemple!!)
# Doc: eviter les failles de securité
Posté par nanard . Évalué à 2.
Il y a de la doc en quatre partie, ce sont des articles parut dans linuxmag, sur la programmation en C. Assez instructif.
Allez tous vous faire spéculer.
# Coding Standard
Posté par Vivi (site web personnel) . Évalué à 2.
Qu'est-ce qu'il y a comme conneries/inexactitudes ?
[^] # Re: Coding Standard
Posté par voodoo . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.