Voilà ce que j'ai avec ce bout de code basique:
 

Pourquoi ?  
 
J'apprend le C avec un bouquin et c'est la solution qu'ils donnent à un petit exercice...
 
Merci

because elle verifie pas si la chaine lu peut entré dans le buffer de destination, donc pb en pagailles

le programme fuis, jette le bouquin

si tu tappe + de 80 caractètes ça déborde.
gets peut toujours faire un débordement quelque soit le tampon alloué avant, elle est donc toujours dangereuse.
celà dit moi je m'en sers souvent car elle est pratique, mais en étant conscient que ça crée un trou de sécurité dans mon prog.

Ok    
 

Déjà que la traduction est superbement mal faite et que y'a des erreurs de tous les côtés    
24€ à la poubelle quasiment  

t'avais qu'à demander avant d'acheter de la merde s

Il avait l'air bien, il est si joli dans sa robe jaune    
J'avais regardé pour le K&R mais ils avaient pas (à la FNAC évidemment  )
 
Pour ceux que ca intérressent le livre en question est: "Le programmeur: le langage C" de CampusPress...

 
du coup ta pris la merde qui  restait

Ben ouais  

warning: the use of `tmpnam' is dangerous, better use `mkstemp'
 

la fnac c'est les pires de tous. va dans n'importe quelle librairie, il te le commande pour pas un rond, ça te coute pareil que chez amazon (ou moins) et tu vais vivres de véritables professionels du livres

 
c'est a dire ?  

abruti

ben un débordement fait que tu écrit dans une zone mémoire qui ne t'es pas allouée, un endroit aléatoire, et tu peux corrompre des données

utile quand on débugge un code de ne même pas pouvoir se fier à sa saisie

c'est gênant, mais le fait d'avoir un bug indébuggable n'est pas un trou de sécurité en lui même

Ouai, parce que j'avais entendu dire que c'etait une ancienne ruse pour faire du hacking cette fonction la...je croyais qu'en parlant de sécurité il voulait faire allusion a ceci.
 
=> taz : casse-toi !

Pas de sang sur mon topic

vous êtes vraiment incroyable, vous êtes des bleu-bites comme on en fait pas avec vos pointeurs, les mecs de gcc ont pris la peine, une fois n'est pas coutume, d'afficher un warning, et vous foncez ...

 
Ben oui, exploiter un buffer overflow (écrasement mémoire) c'est même la méthode la plus classique de prise de contrôle d'un ordinateur à distance.
 
www.bletchleypark.net/algorithms/Buffer_Overflow.pdf

   
je disais simplement que les problèmes rencontrés au débug n'étaient pas les concéquences les plus graves (en terme de dangerosité potentielle) d'un dépassement de capacité moi

comment tu veux débugger quoi que ce soit en utilisant des fonctions notoirement bugguées et dangereuses ? c'est comme mets des abort() dans tous les sens, tu gagneras du temps et de l'argent

Mais bordel de foutracul j'ai pas dit le contraire espèce de vieux grincheux !
 
J'ai simplement sous entendu que le fait qu'il ne faut pas utiliser une commande parce qu'elle empêche de débugger on s'en tamponne quand on sait qu'il ne faut pas l'utiliser car elle constitue une faille de sécurité  
dans les deux cas le résultat est le même (tu utilises pas la commande)

je m'en fous, je veux pas entendre parler de gets

t'es quand même un vieux grincheux  
[meta ultra combo dans ta tête]
on dirait mon père  
[/meta ultra combo dans ta tête]

j'ai un bug vous pouvez m'aider ?
 
 

 
je vois pas de pbs, mé ca mrche pas

c'est pas bien de se moquer des gens

merde, fais pas de faute d'orthographe

oui comme dit plus haut si les octets qui débordent sont du binaire qui se place au bon endroit (à l'adresse d'une prochaine instruction pour peux qu'elle soit accessible) tu peux exécuter du code malicieux. C'est un grand classique des failles.

 
 
Et maintenant voilà que les pages du livre commencent à se détacher ! A se demander si j'ai pas acheté un manuscrit...  

 
ben le classique buffer overflow
 
où l'on peut ecrire du code executable dans un endroit de la ram où on ne devrait pas pouvoir... c'est la magie du C

 
faudrait ptet tester ce que vaut ptr apres le malloc, non ? imagine que le malloc échoue  

imagine que malloc soit inutile

Pourquoi chercher midi a 14heure.
gets ne doit plus être utiliser pour les raisons évoquées plus hauts.
 
A la place il vaut mieux utiliser fgets

installez SP2

 
et un athlon 64 pour avoir un bô message d'erreur et le kill du process en cado  

Salut,
 
a propos de buffer overlow, j'ai matté quelqes topics et étudiés quelques bouts de code.
Il y a toujours un trucs que j'ai pas compris : une fois le bout de code envoyé celui-ci viens donc "remplir" plus de memoire que le programmeur n'avait prévu et ainsi provoqué un debordement de tampon. Par contre, comment ce bout de code peut-il s'executer tout seul sur la machine vérolée ?  A part planter (core dump) le programme fautif je vois pas comment ca peut fonctionner ...
 
Bon en y regardant de plus prêt on peu voir que les exploits utilisent aussi une adresse de retour apres avoir envoyé le shellcode. J'imagine que c'est une espece de call adresse qui est éxecuté mais je vois toujours pas comment . l'@ en question doit sans doute être le pint d'entree en memoire de la variable devant accueillir la chaine (dans le cas d'un gets par ex)  
 
SI je comprend bien le seul interet de la chose est de profiter des privilèges attribués au programmes exploitable et ainsi executer son pti programme confortablement ?

L'athlon 64, il fait quoi de plus ?  en gros on aurais rajouté une fonctionnalité dans le prossesseur pour prévenir les bugs des programmeurs ? (lol) pour moi c'est prendre le pb à l'envers.. j'me demande bien a la demande de qui les constructeurs ont-ils rajouté ce systeme
si vous avez un lien interessant sur le sujet je suis preneurs

Tous les sites de hardware en parlent, ils bloquent les buffer overflow, c'est tout...