On peut aussi lire la doc, mal la comprendre, mal l'interpréter, avoir un moment d'égarrement, etc.
Et c'est justement là qu'est le débat : le langage est tellement "dangereux" qu'il en devient inutilisable : pour écrire une ligne de code, il faut lire 1 doc, un man, un tutorial et prier pour que personne te traite de débile ou de sous-merde infâme.
Tu es tres a cote de la verite. ce que vous traitez de dangereux depuis le debut, ce sont des erreurs de debutants, laxisme, ou etourderie.
Peu importe la fonction et le langage, si tu connais pas, il faut lire sa doc. Je te rassures, je n ai pas a relire les docs de toutes les fonctions que j utilise quotidiennement ... Un grand nombre semble aussi croire que le C, ca se resume a partir de la glibc et rien d autre, autre tres grande erreur. Il y a plein de librairies de plus haut niveau pour facilement le boulot ...
Je ne dev pas en Java, j evite donc de balancer dessus.
Par contre je dev en C chaque jour, et je suis en profond desaccord avec vous. Si c etait aussi difficile que vous le dites, comment on a fait pour dev tous ces programmes en C, ainsi que ces OS ? ou alors les devs C seraient des etres d une intelligence superieure ? j en doute quand meme.
Tu as dit que vtorri n avait pas beaucoup d experience, il te donne son experience, tu repond que c est une ineptie (synonyme : absurdite), j aimerai bien comprendre pourquoi.
Linus lui meme l admet : il ne cherche pas a dev un truc blinde.
Donc forcement, on trouve des failles dans le kernel (biensur, on en trouve bien plus dans les milliards de logiciels existants), qui ne sont patchees qu une fois devoilees.
L erreur humaine du dev n est pas un probleme du langage.
Les soucis lies aux BOFs sont surtout une question de securiser les "liens avec l exterieur" que ce soit des inputs clavier, la lecture d un fichier externe, une bdd, ou encore des sockets. Beaucoup de devs ne le font pas, car l aspect "fonctionnel" prime sur l aspet "securite", et comme je l ai deja dit, tu connais beaucoup de projets qui sont passes au fuzzing par leurs devs ? Il est la le vrai probleme.
Si parrer aux BOFs c etait si difficile, en patcher un prendrai des mois, et pas quelques minutes lorsque l exploit est publie.
Il leur suffit de lancer gdb, lancer l exploit, et backtrace tout ca pour voir ou est ce que c est mal controle, fiou, que c est difficile!
Les cas les plus complexes ne sont pas les exploitations mais plutot les implementations.
blinder un programme d une exploitation c est juste un boulot chiant et du coup les devs ne le font pas vraiment : Il est pourtant tres facile de fuzzer.
La tres grande majorite des devs ne fait ni de tests unitaires, ni de fuzzing.
Certains devs reprennent du vieux code de personnes n ayant aucune notion de securite, et donc, rien n est controle.
Il n est pas si difficile de se proteger contre les attaques type BOF, mais ca demande de la rigueur.
En fait dans la majorite des cas, le dev ecrit, et attend que quelqu un lui montre la faille avant de comment a se poser des questions.
Oui c est vrai, mais ca me parait evident que si tu passes n importe quoi comme parametres a une fonction, tu obtiens n importe quoi, non ?
Si tu donnes a une fonction de formatage de la data non controlee, elle va formater n importe comment..
Si tu ne sait pas calculer la taille max d une chaine, forcement strncpy() ne t es pas d un grand secours, car il a besoin de toi pour compte le MAX ...
Si on en est a ce niveau la ... je pense qu il vaut mieux ne pas coder du tout.
On peux tout a fait coder des gros projets en C.
Le faire en assembleur est bien plus delicat, notamment car les optims de gcc sont plus interessantes que notre capacite a optimiser le code.
Java ne fait pas cela. Java permet seulement de donner moins de boulot au dev, au detriment d une JVM et de perfs amoindries. Hors, chez moi (dev de softs pour des serveurs), ce compte c est que ce soit leger et rapide sans avoir besoin d un serveur a 10k€
Il suffit de savoir structurer son programme ...
C est sur que si on ne respecte aucune rigueur, on obtient de la bouillie. Mais c est comme ca partout, pas juste en informatique ...
Donc, si j ai bien tout lu et compris, l avantage de java c est que les securitees sont dans la JVM et donc qu un mauvais dev peut coder, alors qu en C il faut quelqu un qui utilise son cerveau pour sortir un programme fonctionnel. C est pour ca que les etudes sont de plus en plus simples alors ? ca sert a rien d etre doue, java corrige les conneries ?
Je suis aussi amuse de lire "en C/C++ t as des soucis de BOFs". Ah bon ? pourtant je code en C tous les jours (bon, ok, parfois c est seulement du lundi au vendredi, et parfois je suis en conges). C est soit une etourderie, soit le fait d une meconnaissance du langage, et non un probleme du langage!
C est limite si certains tenteraient pas de nous dire qu on peut pas coder en C car c est trop difficile! Mince, comment on a fait jusque la alors ?
Meme en C, si on le souhaite, on peut coder des libs pour gerer l espace memoire, limiter les BOFs ... le premier venu qui connait snprintf, strncpy, sizeof et strlen sait bloquer les BOFs!
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 3.
Tu es tres a cote de la verite. ce que vous traitez de dangereux depuis le debut, ce sont des erreurs de debutants, laxisme, ou etourderie.
Peu importe la fonction et le langage, si tu connais pas, il faut lire sa doc. Je te rassures, je n ai pas a relire les docs de toutes les fonctions que j utilise quotidiennement ... Un grand nombre semble aussi croire que le C, ca se resume a partir de la glibc et rien d autre, autre tres grande erreur. Il y a plein de librairies de plus haut niveau pour facilement le boulot ...
Je ne dev pas en Java, j evite donc de balancer dessus.
Par contre je dev en C chaque jour, et je suis en profond desaccord avec vous. Si c etait aussi difficile que vous le dites, comment on a fait pour dev tous ces programmes en C, ainsi que ces OS ? ou alors les devs C seraient des etres d une intelligence superieure ? j en doute quand meme.
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -2.
J ai ouie dire que dans le cas de Windev ou Webdev, on pouvait se cacher derriere le langage.
pour la libc, c est plus difficile.
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -1.
Tu as dit que vtorri n avait pas beaucoup d experience, il te donne son experience, tu repond que c est une ineptie (synonyme : absurdite), j aimerai bien comprendre pourquoi.
Linus lui meme l admet : il ne cherche pas a dev un truc blinde.
Donc forcement, on trouve des failles dans le kernel (biensur, on en trouve bien plus dans les milliards de logiciels existants), qui ne sont patchees qu une fois devoilees.
L erreur humaine du dev n est pas un probleme du langage.
Les soucis lies aux BOFs sont surtout une question de securiser les "liens avec l exterieur" que ce soit des inputs clavier, la lecture d un fichier externe, une bdd, ou encore des sockets. Beaucoup de devs ne le font pas, car l aspect "fonctionnel" prime sur l aspet "securite", et comme je l ai deja dit, tu connais beaucoup de projets qui sont passes au fuzzing par leurs devs ? Il est la le vrai probleme.
Si parrer aux BOFs c etait si difficile, en patcher un prendrai des mois, et pas quelques minutes lorsque l exploit est publie.
Il leur suffit de lancer gdb, lancer l exploit, et backtrace tout ca pour voir ou est ce que c est mal controle, fiou, que c est difficile!
Les cas les plus complexes ne sont pas les exploitations mais plutot les implementations.
blinder un programme d une exploitation c est juste un boulot chiant et du coup les devs ne le font pas vraiment : Il est pourtant tres facile de fuzzer.
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -1.
La tres grande majorite des devs ne fait ni de tests unitaires, ni de fuzzing.
Certains devs reprennent du vieux code de personnes n ayant aucune notion de securite, et donc, rien n est controle.
Il n est pas si difficile de se proteger contre les attaques type BOF, mais ca demande de la rigueur.
En fait dans la majorite des cas, le dev ecrit, et attend que quelqu un lui montre la faille avant de comment a se poser des questions.
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
Oui c est vrai, mais ca me parait evident que si tu passes n importe quoi comme parametres a une fonction, tu obtiens n importe quoi, non ?
Si tu donnes a une fonction de formatage de la data non controlee, elle va formater n importe comment..
Si tu ne sait pas calculer la taille max d une chaine, forcement strncpy() ne t es pas d un grand secours, car il a besoin de toi pour compte le MAX ...
Si on en est a ce niveau la ... je pense qu il vaut mieux ne pas coder du tout.
[^] # Re: Chacun son style
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 1.
Et tu n a pas code de fonction d init ?
AFFECT_DATA *paf = affectdate_new();
avec dans cette fonction un :
AFFECT_DATA *tmp = calloc(1, sizeof(AFFECT_DATA));
c est la base.
[^] # Re: Chacun son style
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -2.
On peux tout a fait coder des gros projets en C.
Le faire en assembleur est bien plus delicat, notamment car les optims de gcc sont plus interessantes que notre capacite a optimiser le code.
Java ne fait pas cela. Java permet seulement de donner moins de boulot au dev, au detriment d une JVM et de perfs amoindries. Hors, chez moi (dev de softs pour des serveurs), ce compte c est que ce soit leger et rapide sans avoir besoin d un serveur a 10k€
[^] # Re: Chacun son style
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -2.
Il suffit de savoir structurer son programme ...
C est sur que si on ne respecte aucune rigueur, on obtient de la bouillie. Mais c est comme ca partout, pas juste en informatique ...
[^] # Re: Chacun son style
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -4.
Donc, si j ai bien tout lu et compris, l avantage de java c est que les securitees sont dans la JVM et donc qu un mauvais dev peut coder, alors qu en C il faut quelqu un qui utilise son cerveau pour sortir un programme fonctionnel. C est pour ca que les etudes sont de plus en plus simples alors ? ca sert a rien d etre doue, java corrige les conneries ?
Je suis aussi amuse de lire "en C/C++ t as des soucis de BOFs". Ah bon ? pourtant je code en C tous les jours (bon, ok, parfois c est seulement du lundi au vendredi, et parfois je suis en conges). C est soit une etourderie, soit le fait d une meconnaissance du langage, et non un probleme du langage!
C est limite si certains tenteraient pas de nous dire qu on peut pas coder en C car c est trop difficile! Mince, comment on a fait jusque la alors ?
J imagine aussi qu a cette adresse on nous ment : http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Java
Meme en C, si on le souhaite, on peut coder des libs pour gerer l espace memoire, limiter les BOFs ... le premier venu qui connait snprintf, strncpy, sizeof et strlen sait bloquer les BOFs!
Mais bonne blague tout cela.