Pour lancer une application, il faut cliquer au moins trois fois...
Ah bon ?
Methodes que je connai :
1) click sur le bural, qui affiche le menu, ensuite on se balade dans le menu (clavier ou souris, les deux fonctionnent) et on choisi donc l appli au click ou au clavier en appuyant sur entree (donc ca fait 2 clicks)
2) L application est dans une ibar = 1 click
3) Alt+Escape -> ca lance omni, tu peux soit choisir ton appli au click, ou tout au clavier, ou un mix des deux (donc ca fait entre 0 et ... plein de clicks)
C est vrai que la quasi totalite des distros n a pas les patchs kernels necessaires mais un desktop bateau a moins de besoins de secu qu un serveur, il y a une relativite a savoir conserver, y en a meme qui veulent juste un systeme rapide, et donc, les patchs grsec tu as plutot interet a ne pas les avoir. Mais il y a bien pire que cela : Si tu utilises checksec tu verras que pas mal de demons sont compiles sans aucune protection. Apres c est encore et toujours une question de contexte : pour un desktop linux qui ne fait qu utiliser firefox, il n y a pas grand chose a encadrer. Mais il est evident qu on va eviter une ubuntu de base pour un serveur. La chance que l on a, c est qu on peux tout changer selon notre bon vouloir. Apres il est aussi evident qu il faut chercher la securite dans son code, a moins de s en foutre.
tu n a pas relu ce qui etait dit, l exemple etait un strncpy et prendre en compte le '\0' dans le calcul. Rien a voir avec deux threads qui vont corrompre un size_t qui va ensuite partir sur une mauvaise utilisation du char *.
Bah oui moi ca me surprend qu un test de charge en interne ne voit pas ca.
Oh, bah non moi je m arrete pas la dessus, j ai vu un homme de 55ans partir a la retraire, il a code quasimment toute sa vie, et pourtant il a fini sur windev, ne gerait jamais les erreurs, alors la securite j en parle meme pas. Par contre moi je me demande jusqu a quel point va ton orgueil. Car des "Je bosse avec les meilleurs du monde", "l os le plus utilise" bla bla et bla, desole de ne pas etre autant impressionne de toi que l est toi meme sur ton parcours professionnel. tu n a fait que sortir des propos qui etaient hors contexte. On parlai de savoir utiliser strncpy sans faire de gaffe, tu es tout de suite parti totalement autre chose, qui sont des problemes en AMONT. Ne pas savoir coder un thread (ou une faute d etourderie, fatigue) et donc provoquer une corrumption memoire, ca n a rien a voir avec le fait de savoir dimensionner un char * et savoir passer les bons params a strncpy ou controler si une chaine passee a snprintf ne contiendrai pas des caracteres qui vont provoquer un seg.
La realite qui ne correspond pas a la problematique initiale que j ai du aller rechercher : utiliser strncpy et snprintf. Tu es sorti du contexte des le debut
On parlai de dev des applis il me semble, mais pareil, si on est pas dans le meme contexte...
"une appli qui lit un buffer sur plusieurs sockets a la fois" Le probleme est la. tu as plusieurs sockets, mais un seul buffer pour stocker tout le monde a la fois ? on peux partir loin dans les implementations. On peux meme parler des forks et leurs limites.
La stack non executable c est l un des mecanismes a mettre en oeuvre. Les ret2libc je connais bien ca aussi, c est la parade bien connue, mais plus difficile a maitriser car ils faut savoir pointer sur system(). On peux aussi complexifier le ret2libc via l ASLR, et surtout l ASLR sur un systeme 64bits, ou via noexec. On peux aussi utiliser certaines options de gcc comme -fstack-protection, le RELRO, et toutes ces joyeusetees. Il existe plusieurs projets tres sympa comme hardened gentoo/debian. Mais si on ne donne plus de contextes aux dialogues, on est pas pres de s arreter.
Moi je te conseilles plutot de revenir sur terre.
La question etait : "c est trop dur en C/C++ de borner un char *"
Pour prouver que c est vrai, tu as derive sur "j ecrit mal mes threads en posant mal des mutex, pour corrompre mes variables" ce qui est un probleme d ecriture de threads.
Maintenant, tu en es a venir au sein meme du kernel pour prouver le contraire. En quoi l ecriture d une application JAVA va changer le fonctionnement du KERNEL ?
Moi je repondai aux BOFs quand il s agit de lire via son appli ce qui vient d une source externe, tu me parle de race condition au en interne d une appli, puis du kernel.
Le bypass de grsec est tres sympa, je ne me rappelle pas l avoir vu, il faudrait que je check mes activitees pour cela. Mais je le repete, on est encore sorti du cas qui etait discute au debut, on est pas en train de faire un BOF sur un demon qui ecoute sur la socket, on a un programme qui s execute deja sur le systeme, donc on a deja bypass la stack qui n est pas executable, ce qui est bloque par GRSEC.
perso j utilise grsec depuis ... tres longtemps, peut etre 10ans, et je n ai pas memoire d avoir vu un exploit qui arrivait a bypass les patchs de grsec.
Par contre, j ai vu plein de softs cesser de fonctionner avec grsec car ils faisaient des trucs malsaints =)
Il me parait relativement invraissemblable qu un code soit release avec une bourde de conception pareille.
Et java n est pas non plus a l abris de tout. Il y a meme eu une epoque ou la version courante de java ne pouvait s executer sur un kernel compile avec GRSEC.
Alors, reprenons :
- Dans son cas, il a deux threads, et deux variables, ou il pose ses mutex sur une variable apres l autre, ce qui provoque cette corruption entre le size_t et la vraie taille memoire du char *. Le soucis est de ne pas avoir ecrit ses threads correctement (deux erreurs de conception) ca n a rien a voir avec une gestion de char *.
En java, tu traiteras n importe quoi de toute facon. Si tu fais un FS (mettons via FUSE), tu vas corrompre ton FS.
Un hacker aura bien du mal faire expres de foirer les threads comme decrit alors que tout fonctionne autrement, pour une raison tres simple : le probleme ne vient pas d une attaque!
Ce n est donc pas plus un probleme de securite lie a un BOF potentiel.
De plus, je rappelle que pour des serveurs ou il faut de la securite, y a un mec qui s appelle Spender et qui produit des patchs kernels plus qu interessants.
Oui, c est tjs l erreur d un gars, on est d accords.
Et ton exemple est bidon, car si tu geres mal tes threads, c est pas java qui va te sauver. Hors tout mon dialogue est la, car au dessus si tu relis, on parle bien de "ouais mais le C/C++ c est trop complique, car t as des BOFs partout quand tu manipules des char *", et toi tu viens avec un probleme de gestion des threads, pas un probleme de gestion de char *. la source du probleme n est pas du tout la meme.
Tu ne parles pas de probleme de gestion de debordement memoire comme ca a ete le cas au debut, tu parles de probleme de gestion des threads sur un acces concurrent, qui donnent une corruption de la data qu aucun langage ne va corriger pour toi.
Huuuum, stoi qu est pas serieux!
Desole, j ai pas mieux la ...
Au jeu du "ouais mais si j ecris nawak en ram tu sais pas garantir la donnee" a mon avis, tout le monde se vautre. Si j ai un thread qui ecrit 3, un autre qui ecrit 4, et que je lis que 4, j ai rate 3, et ce soucis c est pas un probleme du langage C, ca concerne tous les langages.
Donc, je reste sur ce que j ai dit :
- Eviter les BOFs c est simple, il est facile d encadrer ce qu un soft recoit d un input clavier, d une lecture de fichier, d une socket.
- Il y a des cas bien plus difficiles a gerer, comme des threads (deadlocks, acces concurrents) qui eux vont corrompre ta stack. Si ta stack est corrompue, tout peux arriver, ca peux etre un BOF, mais aussi un fonctionnement ou tu ne detecte pas d erreur (ce qui est pire!) mais ou tu traites de la donnee CORROMPUE. et ca, si pour une raison X ou Y, ta stack est corrompue, peux importe le langage, que ca seg ou pas, c est pas le probleme, le soft ne fonctionne pas, et la raison n a rien a voir avec un BOF.
En fait on va simplifier le debat, car je pense qu on est d accord sur la technique mais qu on en tire peux etre pas les memes conclusions :
1) La data est corrompue par le BOF ou les threads qui accedent en meme temps a la meme data ?
2) Le patch se fait en priorite sur l evitement d un BOF ou sur l evitement de corruption de data ?
si tu repond :
1) les threads
2) la corruption generee par les threads
Alors on est d accord, le soucis c est pas de gerer des BOFs.
Un autre exemple aussi valable que le tiens aurait ete : Si ta RAM est defectueuse, et que tu y lis des valeurs qui ne sont pas celles que tu as ecrites, et que ca genere un BOF, le soucis c est le BOF ou la RAM ?
Je ne vais donc pas dire "ouais mais il suffit de XXX pour que ca n'arrive pas, le developpeur est un nul !" puisque tu t y attend, je vais donc partir sur autre chose :
Le probleme n est donc pas un BOF, mais un acces concurrent a une data, qui a pour consequence un BOF dans ce cas la (et qui fait que du coup on remarque le probleme). On en reviens donc tjs a la meme chose : Les buffers on sait les manipuler. Ce cas de probleme d acces concurrent qui vient corrompre de la data, tu peux l avoir sur n importe quel langage. Et meme si avec java tu n aurai pas eu l effet d un BOF, qui entraine eventuellement (en l esperant, je prefere seg que manipuler de la donnee corrompue) un segfault, tu as de toute facon corruption de la data.
Si ta taille est corrompue, ton probleme n est pas un buffer overflow, ton soucis est ce qui a genere cette taille corrompue. Soit c est un autre buffer overflow, et donc c est tjs le meme soucis type d erreur de conception ou on borne mal, ou alors il y a autre chose, qui n a rien a voir avec un BOF (RAM defectueuse par exemple). Et dans ce cas, le probleme c est pas un BOF.
Il faudrait pour cela que ton race condition soit sur un acces a cette taille, hors je doute fortement que tu aies des acces concurrents complexes sur des gestions de buffers/size. Autant ce genre de chose est possible sur un FS avec un acces en cluster concurrent pour lequel il est parfois tres difficile de garantir la data, mais en ram tout est OK, et a la relecture de la data, sur le FS, tu fais des reads, donc pas de corruption au niveau de cette taille.
Et pourtant, borner des espaces memoire, c est pas si complique. On pourrait meme s amuser a creer une structure representant des chaines, leur taille, et leur type. Et en interne, forcer un controle du contenu de la chaine par rapport a son type, et en permanence borner sa taille. La seule chose compliquee, c est de jouer avec des fonctions de formatage comme sscanf ou snprintf quand on ne controle pas tous les arguments, et donc leur taille, ce qui veux donc dire que c est une mauvaise idee de les utiliser directement.
Il y a des cas beaucoup plus complexes a gerer que ca.
Tes fonctions plus sures, c est tjs du C non ? tout est dit.
Je ne developpe pas que des hello world.
C'est vrai, et quelque soit le langage d'ailleur. Mais qui t'assure que tes tests sont correctement écrits ? Rien. Qui t'assures que tes tests sont complets ?
Je m amuse avec plusieurs outils, des valeurs extremes, des caracteres aleatoires ... mon but est que dans le pire des cas, ca remonte seulement une erreur. Il est facile de tester tous les caracteres possibles ainsi que des tailles depassant les buffers internes qui sont bornes. les soucis d archi, ca se passe a un autre niveau que ton code C (hormis la taille de certaines variables, mais c est connu et documente)
Et comme j ai dit, la problematique des BOFs t en as vite fait le tour. Il existe pire que cela.
Je ne parle pas de clareté mais de sécurité. La méthode peut être clair, la doc aussi, mais tout repose sur le programmeur qui ne doit pas se "planter" lorsqu'il code, sinon boum. D'où l'idée d'avoir un outil (langage + compilo + runtime) qui permet d'assurer l'absence des problèmes les plus courants, by design.
pareil, il faut eviter d adopter une lib simplement parce qu elle fonctionne quand tout est 'dans la norme'. Franchement, mon but n est pas de dire que java ne sert a rien, mais dire que le C c est dangereux, c est quand meme abuse. tout est logique, documente, tout s explique ... ca peux paraitre effrayant quand on vient de java, mais c est juste des methodes a connaitre et respecter.
Oui, des erreurs du programmeur qui conduisent à bugs non détectés par un compilo ou un runtime, et qui se transforme en faille de sécurité potentielle.
C est pour ca que je code des tests unitaires qui inclus les tests qui valident que tout fonctionne quand tout est normal, mais aussi les cas extremes (fuzzing). Se contenter d ecrire un code sans le valider, c est faire la moitiee du taff d un dev.
Le problème c'est pas qu'il n'y a pas d'API intuitive en C, le problème c'est que le langage est tellement dangereux qu'il est extrêment complexe de faire une API 100% secure
En fait non, il existe des methodes assez claires, le probleme c est qu il y a un fosse entre ce qu on apprend a l ecole, le code crado qu on trouve sur google, et de vraies fonctions/libs.
Ben vous le faites, mais avec pleins de problème de sécurité qui conduisent à des failles, pourtant "classiques", mais qui auraient été évités avec un langage de plus haut niveau.
Comme j ai dit au dessus, tests unitaires et fuzzing (au sein d un buildbot), c est primordial. ca detecte tous ces problemes sans avoir a les chercher, et si t as bien fait tes tests tu sauras automatiquement ou ca merde. Ca fait longtemps que les BOFs sont des soucis d un autre age pour moi, les plus gros problemes dans l ecriture d un soft en C, sont la coherence necessaire entre la gestion des ressources, threads et forks (resistance au DDOS, ou grosse charge)
et puis niveau dialogue avec l exterieur, dans mon cas c est a 95% du temps des sockets, et une fois que tu sais le faire une fois, tu sais le faire 100 fois. j avai ecrit une lib pour ca dans le passe, avant de switcher sur ecore (et donc, eina), qui sont deux libs tres agreables.
# Tu cherches donc a avoir un acces internet.
Posté par kur1g3n . En réponse au message FAI: Renater, comment éviter la restriction des protocoles ?. Évalué à 3.
Desole de te l apprendre, mais tu n a donc pas internet.
Une video rigolotte en passant : https://www.youtube.com/watch?v=ky03Pzjfynw
Sinon la solution de christophe est bonne (LES solutions en fait, puisqu il a edite pendant que j ecrivai).
[^] # Re: Je me lance, pas taper !
Posté par kur1g3n . En réponse à la dépêche EFL 1.1 alpha. Évalué à -3.
Methodes que je connai :
1) click sur le bural, qui affiche le menu, ensuite on se balade dans le menu (clavier ou souris, les deux fonctionnent) et on choisi donc l appli au click ou au clavier en appuyant sur entree (donc ca fait 2 clicks)
2) L application est dans une ibar = 1 click
3) Alt+Escape -> ca lance omni, tu peux soit choisir ton appli au click, ou tout au clavier, ou un mix des deux (donc ca fait entre 0 et ... plein de clicks)
Et il y a encore bien d autres maniere de faire
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -3.
Question de contexte et de ce que fait le code.
C est vrai que la quasi totalite des distros n a pas les patchs kernels necessaires mais un desktop bateau a moins de besoins de secu qu un serveur, il y a une relativite a savoir conserver, y en a meme qui veulent juste un systeme rapide, et donc, les patchs grsec tu as plutot interet a ne pas les avoir. Mais il y a bien pire que cela : Si tu utilises checksec tu verras que pas mal de demons sont compiles sans aucune protection. Apres c est encore et toujours une question de contexte : pour un desktop linux qui ne fait qu utiliser firefox, il n y a pas grand chose a encadrer. Mais il est evident qu on va eviter une ubuntu de base pour un serveur. La chance que l on a, c est qu on peux tout changer selon notre bon vouloir. Apres il est aussi evident qu il faut chercher la securite dans son code, a moins de s en foutre.
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -4.
tu n a pas relu ce qui etait dit, l exemple etait un strncpy et prendre en compte le '\0' dans le calcul. Rien a voir avec deux threads qui vont corrompre un size_t qui va ensuite partir sur une mauvaise utilisation du char *.
Bah oui moi ca me surprend qu un test de charge en interne ne voit pas ca.
Oh, bah non moi je m arrete pas la dessus, j ai vu un homme de 55ans partir a la retraire, il a code quasimment toute sa vie, et pourtant il a fini sur windev, ne gerait jamais les erreurs, alors la securite j en parle meme pas. Par contre moi je me demande jusqu a quel point va ton orgueil. Car des "Je bosse avec les meilleurs du monde", "l os le plus utilise" bla bla et bla, desole de ne pas etre autant impressionne de toi que l est toi meme sur ton parcours professionnel. tu n a fait que sortir des propos qui etaient hors contexte. On parlai de savoir utiliser strncpy sans faire de gaffe, tu es tout de suite parti totalement autre chose, qui sont des problemes en AMONT. Ne pas savoir coder un thread (ou une faute d etourderie, fatigue) et donc provoquer une corrumption memoire, ca n a rien a voir avec le fait de savoir dimensionner un char * et savoir passer les bons params a strncpy ou controler si une chaine passee a snprintf ne contiendrai pas des caracteres qui vont provoquer un seg.
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -1.
La realite qui ne correspond pas a la problematique initiale que j ai du aller rechercher : utiliser strncpy et snprintf. Tu es sorti du contexte des le debut
On parlai de dev des applis il me semble, mais pareil, si on est pas dans le meme contexte...
"une appli qui lit un buffer sur plusieurs sockets a la fois" Le probleme est la. tu as plusieurs sockets, mais un seul buffer pour stocker tout le monde a la fois ? on peux partir loin dans les implementations. On peux meme parler des forks et leurs limites.
La stack non executable c est l un des mecanismes a mettre en oeuvre. Les ret2libc je connais bien ca aussi, c est la parade bien connue, mais plus difficile a maitriser car ils faut savoir pointer sur system(). On peux aussi complexifier le ret2libc via l ASLR, et surtout l ASLR sur un systeme 64bits, ou via noexec. On peux aussi utiliser certaines options de gcc comme -fstack-protection, le RELRO, et toutes ces joyeusetees. Il existe plusieurs projets tres sympa comme hardened gentoo/debian. Mais si on ne donne plus de contextes aux dialogues, on est pas pres de s arreter.
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -2.
Moi je te conseilles plutot de revenir sur terre.
La question etait : "c est trop dur en C/C++ de borner un char *"
Pour prouver que c est vrai, tu as derive sur "j ecrit mal mes threads en posant mal des mutex, pour corrompre mes variables" ce qui est un probleme d ecriture de threads.
Maintenant, tu en es a venir au sein meme du kernel pour prouver le contraire. En quoi l ecriture d une application JAVA va changer le fonctionnement du KERNEL ?
Moi je repondai aux BOFs quand il s agit de lire via son appli ce qui vient d une source externe, tu me parle de race condition au en interne d une appli, puis du kernel.
Le bypass de grsec est tres sympa, je ne me rappelle pas l avoir vu, il faudrait que je check mes activitees pour cela. Mais je le repete, on est encore sorti du cas qui etait discute au debut, on est pas en train de faire un BOF sur un demon qui ecoute sur la socket, on a un programme qui s execute deja sur le systeme, donc on a deja bypass la stack qui n est pas executable, ce qui est bloque par GRSEC.
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -2.
Et ?
Ca va deborder de l espace alloue mais avec GRSEC tu ne pourra pas executer le code que tu injectes. ca ne change rien.
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -2.
perso j utilise grsec depuis ... tres longtemps, peut etre 10ans, et je n ai pas memoire d avoir vu un exploit qui arrivait a bypass les patchs de grsec.
Par contre, j ai vu plein de softs cesser de fonctionner avec grsec car ils faisaient des trucs malsaints =)
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -2.
C est exactement ce que font les mecanismes de securite actuels via grsec, pas besoin de rajouter une JVM pour cela.
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -2.
Il me parait relativement invraissemblable qu un code soit release avec une bourde de conception pareille.
Et java n est pas non plus a l abris de tout. Il y a meme eu une epoque ou la version courante de java ne pouvait s executer sur un kernel compile avec GRSEC.
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -2.
Oui, codons en java, et fermons les yeux sur les erreurs de conception, tant que ca plante pas, y a pas de probleme =)
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -1.
Alors, reprenons :
- Dans son cas, il a deux threads, et deux variables, ou il pose ses mutex sur une variable apres l autre, ce qui provoque cette corruption entre le size_t et la vraie taille memoire du char *. Le soucis est de ne pas avoir ecrit ses threads correctement (deux erreurs de conception) ca n a rien a voir avec une gestion de char *.
En java, tu traiteras n importe quoi de toute facon. Si tu fais un FS (mettons via FUSE), tu vas corrompre ton FS.
Un hacker aura bien du mal faire expres de foirer les threads comme decrit alors que tout fonctionne autrement, pour une raison tres simple : le probleme ne vient pas d une attaque!
Ce n est donc pas plus un probleme de securite lie a un BOF potentiel.
De plus, je rappelle que pour des serveurs ou il faut de la securite, y a un mec qui s appelle Spender et qui produit des patchs kernels plus qu interessants.
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -1.
t en es presque a me dire "si tu passes pas les bons parametres a une fonction, elle ne donne pas le bon resultat, c est vraiment un langage pourri!"
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -1.
Oui, c est tjs l erreur d un gars, on est d accords.
Et ton exemple est bidon, car si tu geres mal tes threads, c est pas java qui va te sauver. Hors tout mon dialogue est la, car au dessus si tu relis, on parle bien de "ouais mais le C/C++ c est trop complique, car t as des BOFs partout quand tu manipules des char *", et toi tu viens avec un probleme de gestion des threads, pas un probleme de gestion de char *. la source du probleme n est pas du tout la meme.
Tu ne parles pas de probleme de gestion de debordement memoire comme ca a ete le cas au debut, tu parles de probleme de gestion des threads sur un acces concurrent, qui donnent une corruption de la data qu aucun langage ne va corriger pour toi.
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -1.
Huuuum, stoi qu est pas serieux!
Desole, j ai pas mieux la ...
Au jeu du "ouais mais si j ecris nawak en ram tu sais pas garantir la donnee" a mon avis, tout le monde se vautre. Si j ai un thread qui ecrit 3, un autre qui ecrit 4, et que je lis que 4, j ai rate 3, et ce soucis c est pas un probleme du langage C, ca concerne tous les langages.
On en revient toujours aux memes conclusions.
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -2.
Donc, je reste sur ce que j ai dit :
- Eviter les BOFs c est simple, il est facile d encadrer ce qu un soft recoit d un input clavier, d une lecture de fichier, d une socket.
- Il y a des cas bien plus difficiles a gerer, comme des threads (deadlocks, acces concurrents) qui eux vont corrompre ta stack. Si ta stack est corrompue, tout peux arriver, ca peux etre un BOF, mais aussi un fonctionnement ou tu ne detecte pas d erreur (ce qui est pire!) mais ou tu traites de la donnee CORROMPUE. et ca, si pour une raison X ou Y, ta stack est corrompue, peux importe le langage, que ca seg ou pas, c est pas le probleme, le soft ne fonctionne pas, et la raison n a rien a voir avec un BOF.
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -2.
En fait on va simplifier le debat, car je pense qu on est d accord sur la technique mais qu on en tire peux etre pas les memes conclusions :
1) La data est corrompue par le BOF ou les threads qui accedent en meme temps a la meme data ?
2) Le patch se fait en priorite sur l evitement d un BOF ou sur l evitement de corruption de data ?
si tu repond :
1) les threads
2) la corruption generee par les threads
Alors on est d accord, le soucis c est pas de gerer des BOFs.
Un autre exemple aussi valable que le tiens aurait ete : Si ta RAM est defectueuse, et que tu y lis des valeurs qui ne sont pas celles que tu as ecrites, et que ca genere un BOF, le soucis c est le BOF ou la RAM ?
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -2.
Je ne vais donc pas dire "ouais mais il suffit de XXX pour que ca n'arrive pas, le developpeur est un nul !" puisque tu t y attend, je vais donc partir sur autre chose :
Le probleme n est donc pas un BOF, mais un acces concurrent a une data, qui a pour consequence un BOF dans ce cas la (et qui fait que du coup on remarque le probleme). On en reviens donc tjs a la meme chose : Les buffers on sait les manipuler. Ce cas de probleme d acces concurrent qui vient corrompre de la data, tu peux l avoir sur n importe quel langage. Et meme si avec java tu n aurai pas eu l effet d un BOF, qui entraine eventuellement (en l esperant, je prefere seg que manipuler de la donnee corrompue) un segfault, tu as de toute facon corruption de la data.
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -1.
Si ta taille est corrompue, ton probleme n est pas un buffer overflow, ton soucis est ce qui a genere cette taille corrompue. Soit c est un autre buffer overflow, et donc c est tjs le meme soucis type d erreur de conception ou on borne mal, ou alors il y a autre chose, qui n a rien a voir avec un BOF (RAM defectueuse par exemple). Et dans ce cas, le probleme c est pas un BOF.
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -2.
Il faudrait pour cela que ton race condition soit sur un acces a cette taille, hors je doute fortement que tu aies des acces concurrents complexes sur des gestions de buffers/size. Autant ce genre de chose est possible sur un FS avec un acces en cluster concurrent pour lequel il est parfois tres difficile de garantir la data, mais en ram tout est OK, et a la relecture de la data, sur le FS, tu fais des reads, donc pas de corruption au niveau de cette taille.
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -2.
Je veux bien qu un race condition te provoque des dead locks ou de la data corrompue, mais un BOF ... faut pas pousser
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -2.
Tes fonctions plus sures, c est tjs du C non ? tout est dit.
Je ne developpe pas que des hello world.
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -2.
Je m amuse avec plusieurs outils, des valeurs extremes, des caracteres aleatoires ... mon but est que dans le pire des cas, ca remonte seulement une erreur. Il est facile de tester tous les caracteres possibles ainsi que des tailles depassant les buffers internes qui sont bornes. les soucis d archi, ca se passe a un autre niveau que ton code C (hormis la taille de certaines variables, mais c est connu et documente)
Et comme j ai dit, la problematique des BOFs t en as vite fait le tour. Il existe pire que cela.
pareil, il faut eviter d adopter une lib simplement parce qu elle fonctionne quand tout est 'dans la norme'. Franchement, mon but n est pas de dire que java ne sert a rien, mais dire que le C c est dangereux, c est quand meme abuse. tout est logique, documente, tout s explique ... ca peux paraitre effrayant quand on vient de java, mais c est juste des methodes a connaitre et respecter.
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 1.
Mes excuses, j ai totalement merde sur les quotes, j ai zappe la previsualisation comme un couillon =)
[^] # Re: Dépassement de tampon
Posté par kur1g3n . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 0.
et puis niveau dialogue avec l exterieur, dans mon cas c est a 95% du temps des sockets, et une fois que tu sais le faire une fois, tu sais le faire 100 fois. j avai ecrit une lib pour ca dans le passe, avant de switcher sur ecore (et donc, eina), qui sont deux libs tres agreables.