Ce problème engendre la possibilité de lancer des commandes sur le serveur IMAP en utilisant le nom de l'utilisateur connecté sur sa messagerie. Heureusement qu'il faille être déjà logué sur le serveur IMAP pour pouvoir exploiter ce trou de sécu... ça limite la portée de ce dernier. En espérant que vous ne vous fassiez pas écouter votre réseau si vous avez des clients fonctionnant avec imap sans sous-couche SSL...
wu-imapd
29
mai
2002
RedHat, Mandrake, Eridani et sûrement d'autres (Debian ?) viennent de sortir des patches pour leur packages... En effet, un buffer overflow vient d'être découvert dans les serveurs IMAP utilisés dans ces distributions.
Ce problème engendre la possibilité de lancer des commandes sur le serveur IMAP en utilisant le nom de l'utilisateur connecté sur sa messagerie. Heureusement qu'il faille être déjà logué sur le serveur IMAP pour pouvoir exploiter ce trou de sécu... ça limite la portée de ce dernier. En espérant que vous ne vous fassiez pas écouter votre réseau si vous avez des clients fonctionnant avec imap sans sous-couche SSL...
Ce problème engendre la possibilité de lancer des commandes sur le serveur IMAP en utilisant le nom de l'utilisateur connecté sur sa messagerie. Heureusement qu'il faille être déjà logué sur le serveur IMAP pour pouvoir exploiter ce trou de sécu... ça limite la portée de ce dernier. En espérant que vous ne vous fassiez pas écouter votre réseau si vous avez des clients fonctionnant avec imap sans sous-couche SSL...
# Mort de rire
Posté par Dugland Bob . Évalué à -10.
http://www.haskell.org(...)
http://www.perl.org(...)
etc.
[^] # Re: Mort de rire
Posté par lorill (site web personnel) . Évalué à -7.
-1 parce je le vaux bien (meuh).
[^] # Re: Mort de rire
Posté par dguihal . Évalué à 3.
[^] # Re: Mort de rire
Posté par Baptiste SIMON (site web personnel) . Évalué à 9.
o caml -> "The compiler performs many sanity checks on programs before compilation" & "Automatic memory management and incremental garbage collection"
o haskell -> "Store is allocated and initialised implicitly, and recovered automatically by the garbage collector"
o Perl -> "Perl handles memory management internally"
Voilà koi !
Je garderais pour un autre jour les batailles de clocher en ce qui concerne ces langages (et le java ?? c'est Sun... ok !).
[^] # Dommage, je n'ai plus de [-]
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#IDX62(...)
http://www.gnu.org/prep/standards_22.html#SEC22(...)
[^] # Re: Dommage, je n'ai plus de [-]
Posté par Dugland Bob . Évalué à 0.
[^] # Re: Dommage, je n'ai plus de [-]
Posté par Jar Jar Binks (site web personnel) . Évalué à 0.
[^] # Re: Dommage, je n'ai plus de [-]
Posté par pasBill pasGates . Évalué à 1.
Si tu ne fais jamais d'erreur, tu ne te trompes jamais dans l'index de ta boucle, sur la taille de tes elements,... et bien tu n'as aucun buffer overflow dans ton code non plus.
Tout le probleme est que les gens font toujours des erreurs, et aucun papier quel qu'il soit ne changera ca, alors les GNU coding standards c'est bien joli, mais ca resoud rien du tout. ca elimine quelque cas mais c'est tout.
En passant, je suis tres loin de penser qu'il faudrait eliminer C/C++(bien au contraire), le jour ou d'autres langages auront le meme rapport temps de dev/performance/flexibilite n'est pas encore arrive.
[^] # Re: Dommage, je n'ai plus de [-]
Posté par Dugland Bob . Évalué à -2.
laisse moi rire
va faire un tour sur le language shootout, compte les lignes de codes.
Avec un langage faiblement type tu passe ta vie a checher le bug vicieux.
Sans les contrats en objet, tu cherche qui a foutu la merde dans ton appli.
Sans les closures (ou un substitut) tu n'a pas vraiment de flexibilite.
Et j'en ai de centaines des trucs comme ca (references faibles, faineantise, types generiques etc.)
Pour la flexibilite t'a jamais du utiliser un autre langage alors.
Quand aux perfs ... laisse moi rire ! Faut arreter les benchmark sur les boucles courtes.
[^] # tampons dynamiques => pas de débordement de buffer : Mort de rire !!!
Posté par pappy (site web personnel) . Évalué à 3.
Tu es sérieux quand tu écrit ça ? Tu y crois vraiment ?
main(int argc, char **argv) {
char *buf = malloc(16);
strcpy(buf, argv[1]);
}
Il y a bien un débordement pourtant ... Ben zut ;-) La différence principale entre buffers automatiques et dynamiques vient de leur position en mémoire :
Bref, il vaut mieux éviter de parler de "buffer overflow" et utiliser "stack overflow" ou "heap overflow".
Pour ton information, je fais ma propre pub et celles des RMLLs :
[^] # Re: tampons dynamiques => pas de débordement de buffer : Mort de rire !!!
Posté par Dugland Bob . Évalué à -1.
malloc(sizeof(char)*(strlen(argv[1])+1));
mais ce que j'en pense c'est qu'à un moment où à un autre y'a un +1 qui passe à la trappe
[^] # Re: tampons dynamiques => pas de débordement de buffer : Mort de rire !!!
Posté par Jar Jar Binks (site web personnel) . Évalué à 0.
Sauf que ces bugs sont beaucoup plus faciles à détecter, avec un malloc debugger par exemple, car ils sont systématiques.
[^] # Re: Mort de rire
Posté par furai (site web personnel) . Évalué à -1.
pour ceux qui sechent:
Quel est le langage repute pour sa spongiosite (?) au buffer overflow ?
PS: j'espere au moins que c'est de ce cote la qu'il faut chercher
[^] # Re: Mort de rire
Posté par dguihal . Évalué à -2.
Dommage, il etait bien deguise ce troll
[^] # Re: Mort de rire
Posté par DiZ . Évalué à 1.
ben j'espere pas, sinon on va commencer a parler performance
[^] # Re: Mort de rire
Posté par bmc . Évalué à 3.
Bien sûr, un code C optimisé aux petits soins sera toujours plus rapide, mais la perte de performance est minime.
J'étais tombé sur des mesures de performances (bien sûr, elles valent ce qu'elles valent...) comparant la plupart des langages répandus en fonction des différentes tâches et algorithmes; résultat global, le C finissait premier, devant (dans l'ordre) Ocaml et C++...
Bref, je ne pense pas qu'on puisse dire que les performances de Ocaml (pour Haskell je ne sais pas, pour le Perl j'admets qu'il soit plus lent) soient un frein à son adoption pour l'écriture de logiciels dont les performances ne peuvent être sacrifiées, d'autant plus que le fait que Ocaml dispose d'un interpréteur et d'un compilateur facilite AMHA grandement le développement...
[^] # Re: Mort de rire
Posté par Jar Jar Binks (site web personnel) . Évalué à -1.
Ouiiiiiin, je veux un compilateur Python !
[^] # Re: Mort de rire
Posté par Vivi (site web personnel) . Évalué à 1.
la syntaxe est effectivement différente de celle du C (heureusement) mais il n'y a rien de spécialement mathématique.
[^] # Re: Mort de rire
Posté par Dugland Bob . Évalué à 6.
Les plus éloignés de toi intellectuellement savent même optimiser du C dans un autre langage (par ex. Continuation passing style).
Mais se croire le roi du pétrole à bidouiller la pile d'appel en C ou des pointeurs 'achtement compliqués c'est un peu ce qui mène à ces buffers overflow (et les autres conneries sur la pile).
Et ne me dites pas qu'en faisant gaffe machin, il est certain qu'à un moment ou à un autre toute la monde envoie un pointeur dans l'espace en C.
[^] # Re: Mort de rire
Posté par Jar Jar Binks (site web personnel) . Évalué à 0.
Le mec qui fait de l'arithmétique de pointeurs ou des bidouilles sur la pile dans un programme setuid ou un serveur, il ferait mieux de se mettre à un autre boulot. Et ne me raconte pas qu'en utilisant un autre langage ça ira mieux.
[^] # Re: Mort de rire
Posté par Dugland Bob . Évalué à -6.
Sauf qu'on rediscutera quand tu connaitras les closures, les applications partielles, le typage fort, l'intégrité reférentielle et j'en passe.
Si un jour tu connais tout ça (que je suis hélas loin de maîtriser parfaitement) tu va vite abandonner le C.
En attendant, tu fait du C et ses potes, la seule chose que tu a apris de plus doit être l'algèbre des expressions rationelles (perl, php, python) et tu dois intuiter la notion de classe (qd à un contrat ... :-) ).
Cette attaque personnelle répond à une attaque personnelle.
[^] # Re: Mort de rire
Posté par Jar Jar Binks (site web personnel) . Évalué à 3.
Le problème n'est pas là. Le problème, ce sont les gens comme toi qui racontent à tort et à travers qu'il ne faut pas faire de C parce que c'est une usine à trous de sécurité. Il n'y a rien de plus faux, et il n'y a pas de raison de penser que quelqu'un qui fait des grouikeries en C ne les fera pas dans un autre langage. Un autre langage peut être une solution aux problèmes du langage, pas aux problèmes humains ; et les débordements de tampon en C ne sont pas un problème du langage mais du programmeur.
[^] # Re: Mort de rire
Posté par Dugland Bob . Évalué à 3.
Il faut utiliser son intelligence sur d'autres trucs que sur des indices de tableaux et autres conneries d'allocation (sur avec les pb d'allocation explicite d'on j'ai déjà discuté ailleur) et même d'implémentation.
Etre trop proche du métal fait réfléchir localement au lieu de prendre de la hauteur (genre optimiser les structures de données au lien de schéma général).
Quand je parle d'Ocaml, c'est un nouveau défit, mélanger classes et modules, rien qu'en restant imprératif c'est déjà autre chose que de préfixer ces noms de fonctions par le nom de la biblothèque et se taper des macro #define super dangereuses quand ça se complique.
L'important c'est la facilité avec laquelle on évite le bug, se cracher violement sur une exception est déjà plus saint que de corrompre le tas ou la pile. Surtout si ça crache systématiquement.
Il est d'autre part important de limiter les effets de bords, ils obligent à une réflexion permanente à l'état dans lequel on va retrouver un bout de mémoire à l'entrée dans une fonction.
D'autre part, il y a une culture "élitiste" qui veut que programmer en C soit le top et qu'en plus ce soit difficile. Alors qu'apprendre au plus tôt des langages modernes et variés ferait avancer beaucoup plus vite l'informatique. Le C est un langage quasiment inutile à l'informatique, les codeurs de noyeaux et autres drivers sont marginaux et devraient utiliser ADA.
L'histoire de coder un SGBD en C est à mon sens une vaste connerie (ça vaut des millions les données qu'il y a dedans, autant éviter q'une erreur conne foute tout en l'air).
Bon j'arrête là parce que siono y'en a pour 10 pages et j'ai parlé que de caml comme alternative.
[^] # Re: Mort de rire
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
Mais c'est qu'il en rajoute...
Je renonce. Objective Caml est certainement un très bon langage pour faire ce que tu fais, mais il y a d'autres choses dans la vie. Si je me restreignais au C pour programmer, ce serait une catastrophe, mais se restreindre à autre chose n'est pas pour autant une meilleure idée.
Tu parles du C comme un langage de dinos pas plus évolué que le Fortran, mais crois-tu une seconde qu'il serait encore utilisé dans le monde du libre (un monde où on a le choix, pas comme dans l'industrie ou les SSII) si c'était le cas ?
Sans oublier le problème des bibliothèques...
[^] # Re: Mort de rire
Posté par Vivi (site web personnel) . Évalué à 3.
Des milliards de mouches ne peuvent pas se tromper, ... mangeons de la merde.
Plus sérieusement, je ne suis pas d'accord. Y'a des tas de raisons pour lesquels les gens continuent à programmer en C :
- c'est le seul langage qu'ils connaissent pour lequel il existe un compilo/plate-forme de dev potable en logiciel libre
- l'OS et plein de bibliothèques sont écrits en C.
Mais prendre ça comme une preuve de la qualité du langage, non c'est pas sérieux ...
[^] # Re: Mort de rire
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
Non, ça n'explique pas tout.
[^] # Re: Mort de rire
Posté par Vivi (site web personnel) . Évalué à 1.
[^] # Re: bench
Posté par Prosper . Évalué à 2.
[^] # Re: bench
Posté par bmc . Évalué à 1.
Les comparaisons sont ici:
http://www.bagley.org/~doug/shootout/craps.shtml(...)
Bien sûr, comme le dit l'auteur, c'est "just for fun"...
[^] # Re: Mort de rire
Posté par Jylam / jylam.lnxsce (site web personnel) . Évalué à -3.
2/ Tu generalises on dirait. Je te voie mal ecrire un SGBD en autre chose que du C si tu peux pas mettre un athlon a genoux
3/ Ecris n'importe quoi en n'importe quoi, je te met au defis de me montrer une version 100% bug free.
(m'ennervent ces lycéens / etudiants / autoproclames-admin qui ont l'impression d'avoir des solution a tout mais qui ne connaissant pas la moitiée du probleme)
[^] # Re: Mort de rire
Posté par Éric (site web personnel) . Évalué à -1.
merdeuuhhh c'etait bien parti pourtant j'avais déjà fait la phase de login
[-1, completement stupide]
[^] # Re: Mort de rire
Posté par Vivi (site web personnel) . Évalué à 6.
Non, au contraire c'est toi qui généralise. La news parle d'un serveur IMAP, un programme qui manipule des chaines de caractères et des fichiers. Ce genre de programme s'écrit trés bien (même mieux) dans un langage de haut-niveau. Il n'a jamais parlé de SGBD.
# Patchs
Posté par Tibo . Évalué à 3.
-1 ----> car on le savait déjà !
# Encore un WU-gruyere !
Posté par Ludovic Boisseau . Évalué à 10.
Il y a deux ans, après les nombreuses alertes concernant les versions successives de WU-FTPd, j'avais bani ce serveur et depuis, je ne jure plus que par ProFTPd (<pub>ProFTPd est génial !!!</pub>).
Va-t-il falloir en faire autant avec leur serveur IMAP ? Et pour Pine ? Eh oui, Pine est aussi un produit "WU"... mais bon, c'est seulement un client, pas un serveur (ouf !).
Pfff... Je sais bien que développer un serveur, c'est pas simple. Mais il existe des méthodes pour produire du code sûr : vérifier tous les codes de retour, les allocations mémoire, traiter les erreurs correctement... Oui, je sais, ça alourdit _énormément_ le code et en plus, ça suppose que le programme ait été conçu dès le début en respectant ces rêgles. Mais c'est faisable. De plus, puisque les machines sont de plus en plus rapides, on peut se permettre d'alourdir le code avec une floppée de tests dans tous les sens. En plus, dans le cas d'un serveur, c'est bien souvent le réseau qui ralentit tout.
Alors, à quand des serveurs sécurisés ?
Pour mémoire, le HOWTO relatif à la programmation sécurisée : http://www.dwheeler.com/secure-programs/(...)
[^] # Re: Encore un WU-gruyere !
Posté par gle . Évalué à 4.
[^] # Re: Encore un WU-gruyere !
Posté par Aurélien Jarno (site web personnel) . Évalué à 6.
Redistribution of this release is permitted as follows, or by mutual agreement:
(a) In free-of-charge or at-cost distributions by non-profit concerns;
(b) In free-of-charge distributions by for-profit concerns;
(c) Inclusion in a CD-ROM collection of free-of-charge, shareware, or non-proprietary software for which a fee may be charged for the packaged distribution.
Enfin, on a vu pire niveau restrictions dans la license...
[^] # Re: Encore un WU-gruyere !
Posté par gabuzo . Évalué à 6.
wu-Imapd est efectivement réputé pour ses bugs de sécurité (tellement d'ailleurs que sous FreeBSD la compilation du port se traduit par un texte d'avertissement recommendant de ne surtout pas l'installer). Concernant les alternatives j'en connaît deux :
[^] # Re: Encore un WU-gruyere !
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
Pour ce qui est de courier, il est vraiment très bien, mais je crois qu'il ne marche pas avec les boîtes aux lettres par défaut, il lui faut du maildir.
[^] # Re: Encore un WU-gruyere !
Posté par bmc . Évalué à 3.
[^] # Re: Encore un WU-gruyere !
Posté par William Steve Applegate (site web personnel) . Évalué à 2.
C'est curieux, parce que la licence dispo à http://asg.web.cmu.edu/cyrus/imapd/license.html(...) ressemble comme deux gouttes d'eau à une licence BSD première version (avec la clause de « publicité »). Et, ô surprise, un apt-cache showpkg cyrus-imapd le montre dans main, donc sa licence est conforme aux DFSG.
Moi je dirais qu'il est suffisamment libre pour moi. En revanche, le fait qu'il n'utilise pas les spools de mail normaux ne me plait pas trop. Mais je vais voir quand même, les machins WU-* j'en ai par-dessus la tête moi aussi...
Envoyé depuis mon PDP 11/70
[^] # Re: Encore un WU-gruyere !
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
On dirait bien qu'ils ont changé leur licence, et il n'y a pas très longtemps.
C'est une très bonne nouvelle, ça !
[^] # Re: Encore un WU-gruyere !
Posté par sheepkiller . Évalué à 1.
De plus, puisque on est d'humeur a parler secu, un petit coup d'oeil sur les sources et on y trouve pletore de "strcpy" et "strcat", souvent nids de stack overflow...
Il doit y avoir quelques possibilités pour que lui aussi puisse etre un gruyere ;)
PS : -1 ou je fais un malheur ;)
[^] # Re: Encore un WU-gruyere !
Posté par Jar Jar Binks (site web personnel) . Évalué à 2.
Pourquoi ? S'ils sont effectués sur des tampons alloués dynamiquement, c'est au contraire un bon moyen d'éviter les débordements.
[^] # Re: Encore un WU-gruyere !
Posté par Dugland Bob . Évalué à -3.
-1 encore un sarcasme (je deviens antissocial ou quoi ?)
[^] # Re: Encore un WU-gruyere !
Posté par Jar Jar Binks (site web personnel) . Évalué à -3.
(-1, je marche encore dans le troll)
[^] # Re: Encore un WU-gruyere !
Posté par pasBill pasGates . Évalué à 6.
Ton tampon peut etre alloue dynamiquement ca change rien. Si tu te trompes sur la taille de l'allocation ou si le string que tu passes n'as pas de '0' a la fin(bon ok c'est plus un string a ce moment...) tu risques un heap overflow et c'est aussi dangereux qu'un stack overflow(bien qu'un peu moins facile a exploiter, mais tres loin d'etre infaisable).
La regle c'est de limiter la copie a la taille du buffer, et ca tu peux pas le faire avec un strcpy ou un strcat. strncpy et strncat resolvent en partie ce probleme bien qu'ils ne soient pas parfait a 100%, mais c'est deja une tres grosse avancee.
Si tu as:
char *monbuffer=(char*)malloc(SIZE+1);
//test alloc success
strcpy(monbuffer,thestring);
- T'as un BO si thestring n'est pas null terminated
- T'as un BO si tu t'es gourre de taille pour SIZE
si tu utilises
#define MyStrnCpy(X,Y,Size) X[Size]=0; \
strncpy(X,Y,Size);
MyStrnCpy(monbuffer, thestring, SIZE);
Tu elimines ces 2 risques.
Faut bien comprendre qu'aucune fonction sans bug n'est dangereuse d'elle meme, une fonction est dangereuse a partir du moment ou le dev l'utilise mal en lui passant des parametres a la con.
strncpy et strncat sont plus surs car en utilisant la simple technique de:
- allouer un buffer de <size>+1
- mettre buffer[size] a 0 avant l'appel a strncpy
- specifier le nombre max de char a copier
On est sur de ne pas eclater le buffer.
Ces etapes sont elles aussi sujettes a erreur, mais elles sont beaucoup plus simples a effecteur et bien moin sujettes a erreur que faire un strcpy en priant pour qu'on ne se soit pas trompes en calculant la taille du buffer.
[^] # merci :)))
Posté par pappy (site web personnel) . Évalué à 1.
Juste un petit truc avec lequel je ne suis pas d'accord :
- allouer un buffer de <size>+1
- mettre buffer[size] a 0 avant l'appel a strncpy
- specifier le nombre max de char a copier
Si tu fais cela, tu risques d'écraser l'octet NULL de fin de chaîne que tu viens de mettre (genre tu t'es trompé dans ton 3ème argument) et donc tu as une forte chance d'arriver à une erreur (overflow ou autre) la prochaine fois que tu te serviras de cette chaîne.
Les fonctions strncpy() et strncat() ne sont pas non plus des solutions idéales, comme vous le découvrirez en lisant MISC 3 :-)
[^] # Re: merci :)))
Posté par pasBill pasGates . Évalué à 0.
char buffer[400+1];
buffer[400]=0; // 401eme element
strncpy(buffer,thestring,400); // --> de 0 a 399
Le risque d'erreur est la effectivement, mais c'est pour ca que tu fais :
- allouer un buffer de taille size+1, pas de reflexion a faire tu fais aveuglement un +1 a chaque fois.
Ensuite tu sais qu'il ne faut pas mettre le +1 dans ton 3eme parametre.
un petit define:
#define STACK_BUF(TYPE, NAME, SIZE) TYPE NAME[SIZE+1];
et ca donne:
STACK_BUF(char, buffer, 400);
MyStrnCpy(buffer,thestring, 400);
La tu ne t'occupes plus de rien d'autres que d'un seul chiffre, plus besoin de chercher des histoires de +1, -1, etc...
[^] # Re: merci :)))
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
J'ai déjà passé des journées entières à traquer ce genre de saloperies dans le code.
Cela dit, personnellement, j'utilise très peu strcpy et strcat (voire jamais), je préfère strdup qui fait déjà tout le boulot.
[^] # Re: merci :)))
Posté par pasBill pasGates . Évalué à 1.
J'ai du mal a te suivre la(un petit exemple aiderait je pense).
Sinon, strdup est bien joli, mais il alloue a chaque fois de la RAM, pas tres utilisable.
[^] # Re: merci :)))
Posté par Jar Jar Binks (site web personnel) . Évalué à 3.
Un tampon dont tu calcules la taille avant de l'allouer.
C'est l'une des règles de base des GNU coding standards : aucune limitation arbitraire. Et un tampon de taille fixée, c'est une limitation arbitraire. Je trouve l'exemple du PATH_MAX assez révélateur.
Sinon, strdup est bien joli, mais il alloue a chaque fois de la RAM, pas tres utilisable.
Quand on fait un serveur, il faut savoir sacrifier certaines choses sur l'autel de la sécurité. Je pense qu'une légère perte de performances est largement compensée par le gain. Qui plus est, les sections qui consomment beaucoup de temps de calcul sont en général assez courtes, et il vaut mieux concentrer les efforts d'optimisation dessus.
[^] # Re: merci :)))
Posté par Dugland Bob . Évalué à -1.
alors pourquoi utiliser du C ?
perl et très bien, python est très bien
et moi je suis au moins à 2grammes/Litre
[^] # Re: merci :)))
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
Ceci dit, quand la tenue à la charge n'est pas une priorité, ça peut très bien se faire, et même que ça existe. Regarde du côté de pyftpd, par exemple.
[^] # Re: merci :)))
Posté par pasBill pasGates . Évalué à 0.
Ca ne resoud RIEN DU TOUT.
Un tampon dynamique c'est super si tu ne te trompes jamais dans le calcul de la taille de l'allocation, si tu peux te permettre de faire des allocations toutes les secondes(et un malloc est une des operations les plus lentes), ...
Le probleme que t'as du mal a voir il me semble est le suivant:
1) Cas avec tampon dynamique et strcpy
Tu alloues un buffer dynamiquement, tu calcules sa taille comme tu veux, et apres tu fais ta copie SANS AUCUNE VERIFICATION A CE STAGE
Resultat: Si tu t'es gourre dans la taille du buffer, tu t'ecrases
2) Cas avec tampon dynamique et strncpy
Tu alloues un buffer dynamique, tu calcules sa taille comme tu veux, et apres tu fais ta copies en specifiant la taille du buffer.
Resultat: TU ES SUR DE NE PAS DEPASSER LE BUFFER, meme si tu t'es gourre dans le calcul de la taille du buffer, meme si un autre thread change la taille du string,..., car quoi qu'il arrive, tu n'ecriras pas plus loin que la fin du buffer.
Non serieux, tu peux demander a n'importe quel gourou securite, si tu lui dis les mots strcpy et strcat, il va prendre un air affole et appeler le ciel a l'aide. Chez nous utiliser strcpy ou strcat c'est considere "bad practice", et dans tout element un tant soit-peu sensible de l'OS(service, truc qui a des droits eleves,...) c'est un BUG, et on est loin d'etre les seuls a faire de la sorte.
[^] # Re: merci :)))
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
toto=malloc(strlen(titi)+1); strcpy(toto,titi);
(modulo le test de retour du malloc)
à la place de :
toto=strdup(titi);
je ne trouve pas que ce soit une grosse erreur. On croise souvent des choses beaucoup plus « graves » dans des composants pourtant critiques.
[^] # Re: merci :)))
Posté par pasBill pasGates . Évalué à 1.
Si tu te trompes pas en ecrivant ton allocation, ca sert a rien bien evidemment, mais le probleme est que tout le monde se trompe avec ca, et c'est une des causes les plus frequentes de buffer overflow.
Si t'as oublie un mutex sur ton tampon, c'est une erreur ! Mais le fait de specifier la taille du buffer a l'ecriture(strncpy) fait que tu n'auras pas un buffer overflow, peut-etre un autre probleme mais potentiellement moins grave.
Quand a strdup, c'est bien joli mais c'est le genre de truc a finir avec des memory leaks ca et ca fragmente monstrueusement ta memoire, faut a chaque fois allouer/desallouer, chaque allocation que tu fais est un risque de plus d'oublier de desallouer, c'est un test de plus a faire pour voir si malloc a fonctionne,...
C'est pas faisable pour des serveurs, c'est beaucoup trop lourd.
# php/imap
Posté par Francois SIMOND . Évalué à 1.
.. ça risque de ne pas être évident de compiler et faire fonctionner le tout !
A votre avis quelle est la meilleure alternative a WU pour utiliser avec un webmail en php ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.