Quelqu'un m'a dit que l'allocation avec Malloc n'est plus sécurisé, je ne suis pas un gourou C / C ++ mais j'ai fait des choses avec Malloc et C / C ++. Est-ce que quelqu'un sait de quels risques je suis?
lui citer:
[..] Mais effectivement le point faible de C / C ++ c'est la sécurité et le talon d'Achille est en effet malloc et l'abus de pointeurs. C / C ++ C'est une langue non sécurisée bien connue. [..] Il y aurait peu d'applications dans ce que je ne recommanderais pas de continuer à programmer avec C ++. "
12 Réponses :
Si vous utilisez c, vous devez utiliser Certainement, votre ami a un point difficile qu'il est difficile d'écrire du code sécurisé en C, en particulier lorsque vous allouez de la mémoire et de faire face à des tampons. Mais nous savons tous que, non? :) MALLOC pour allouer la mémoire, sauf si vous avez une bibliothèque tierce qui allouera / gérera votre mémoire pour vous.
Peut-être que-t-il voulait dire que vous devriez utiliser calloc afin que la mémoire renvoyée soit égale à zéro.
Votre ami pourrait parler de:
La sécurité de l'utilisation des pointeurs en général. Par exemple, en C ++ si vous attribuez une gamme de caractères avec MALLOC, question pourquoi vous n'utilisez pas de string ou quelque chose à propos de MALLOC en particulier. La plupart des OSES clarifient la mémoire avant d'abord la remettre à un processus, pour des raisons de sécurité. Sinon, des données sensibles d'une application peuvent être divulguées à une autre application. Sur les OSES qui ne le font pas, vous pouvez faire valoir qu'il y a une insécurité liée à C'est aussi possible que votre ami ne sait pas de quoi il parle. Quand quelqu'un dit "X n'est pas sûr", ma réponse est "de quelle manière?". vecteur . Les pointeurs ne sont pas obstrucrés, mais le code qui est buggy en raison d'une utilisation incorrecte des pointeurs est.
malloc . C'est vraiment plus lié à gratuit .
Je suis d'accord, on dirait que son ami parle d'une perspective de sécurité C # / Java, où tous les indicateurs sont diaboliques.
Ce qu'il voulait peut-être vous avertir, c'est sur l'utilisation des pointeurs. Oui, cela causera des problèmes si vous ne comprenez pas comment cela fonctionne. Sinon, demandez-vous ce que votre amie voulait dire, ou demandez-lui une référence qui prouve son affirmation.
dire que jusqu'à ce que cela, utilisez malloc n'est pas sûr est comme dire "N'utilisez pas system x car il n'est pas sécurisé".
masloc in c et Nouveau en C ++.
Si vous utilisez malloc en C ++, les gens vont avoir l'air en colère contre vous, mais c'est bien dans des occasions très spécifiques.
Il est probablement vrai que c ++ 's 1) Avec C ++, vous devez faire attention lorsque vous en C ++, nouveau est plus sûr que malloc () , mais cela ne fait pas automatiquement malloc () plus dangereux qu'auparavant. Votre ami a-t-il dit pourquoi il l'estime insécurité?
Cependant, voici quelques éléments que vous devez faire attention à:
UTILISER MALLOC () / GRATUIT () et NOUVEAU / Supprimer côte à côte dans le même programme. C'est possible et permis, mais tout ce qui a été attribué avec MALLOC () doit être libéré avec gratuit () , et non avec Supprimer . De même, tout ce qui a été attribué avec nouveau doit être libéré avec Supprimer , et jamais avec gratuit () . (Cette logique va encore plus loin: si vous allouez un tableau avec nouveau [] , vous devez libérer avec Suppr [] , et non seulement avec Supprimer .) Utilisez toujours des homologues correspondants pour allocation et distribution, par objet. MALLOC () et nouveau (à nouveau de C ++) Ne faites pas exactement la même chose. malloc () vous donne simplement une pièce de mémoire à utiliser; Nouveau sera également Appelez un contructeur (si disponible). De même, Supprimer appellera un destructeur (si disponible), tandis que gratuit () ne sera pas. Cela pourrait entraîner des problèmes, tels que des objets incorrectement initialisés (parce que le constructeur n'était pas appelé) ou des ressources non libérées (car le destructeur n'a pas été appelé). Nouveau prend également en charge allouant la bonne quantité de mémoire pour le type spécifié, pendant que vous devez calculer cette vous-même avec MALLOC () :
conclusion:
nouveau / Supprimer devrait être préféré sur malloc () / gratuit () si possible. (En C, Nouveau / Supprimer n'est pas disponible, alors le choix serait évident là-bas.)
N'oubliez pas qu'un implémentation C ++ est libre d'implémenter nouveau en utilisant n'importe quel type de fonction d'allocation tant que son comportement est conforme à la norme. En d'autres termes, MALLOC pourrait très bien être appelé afin de mettre en œuvre la partie d'allocation du comportement de nouveau .
@dustin: Ceci est correct, mais Cela ne signifie toujours pas que vous pouvez gratuit () quelque chose attribué avec neuf . Ce que vous avez mentionné est spécifique à la mise en œuvre et ne dispose donc d'aucune garantie; Cela ne devrait pas affecter comment vous écrivez le code.
C'est le seul moyen d'allouer et d'annouez la mémoire en C Nativement. Si vous l'abusez mal, cela peut être aussi précaire que toute autre chose. Microsoft fournit des versions "sécurisées" d'autres fonctions, qui prennent une taille supplémentaire_t paramètre - peut-être que votre ami faisait référence à quelque chose de similaire? Si tel est le cas, il préfère peut-être simplement Calococ () sur Malloc ()?
Pas vraiment. Certains systèmes fournissent des API spécifiques pour une allocation de mémoire. Par exemple, Windows fournit localalloc , heaphoc , globalalloc , etc., ils sont indigènes.
En disant "natif", je voulais dire quelque chose comme "présent dans les Libs C Standard C et disponible sur n'importe quelle plate-forme". Localalloc est M $ -Specific.
Techniquement parlant, malloc n'a jamais été sécurisé pour commencer, mais de côté, la seule chose que je peux penser est le célèbre "Oom Killer" (OOM = Out-de-mémoire) que le Le noyau Linux utilise. Vous pouvez Lire la suite Il si vous voulez. Autre que cela, je ne vois pas comment malloc est intrinsèquement peu sûr.
Que voulez-vous dire par "n'a jamais été sécurisé"? Dans quel sens?
En affirmant que les implémentations actuelles de la fonction MALLOC ne sont pas sûres, il disait que toutes les implémentations précédentes qui se sont comportées de la même manière sont également insécurieuses. En d'autres termes, si malloc n'est pas sécurisé maintenant, il n'a jamais été sécurisé du tout. Quant à la raison pour laquelle il est insécurisé, je n'ai vraiment aucune idée. Je ne faisais que donner à l'OP au profit du doute. : P
Il n'y a rien de mal avec Malloc en tant que tel. Votre ami signifie apparemment que la gestion de la mémoire manuelle n'est pas sécurisée et conduit facilement à des bogues. Comparé à d'autres langues dans lesquelles la mémoire est gérée automatiquement par un collecteur à déchets (non qu'il n'est pas possible d'avoir des fuites - personne ne s'en soucie si le programme se nettoie lorsqu'il se termine, ce qui compte, c'est que quelque chose n'est pas la mémoire de hogging pendant que le programme est courir).
bien sûr en C ++, vous ne toucheriez pas vraiment MALLOC du tout (car il n'est tout simplement pas fonctionnellement équivalent à nouveau et ne fait tout simplement pas ce dont vous avez besoin, en supposant que la plupart du temps vous avez besoin Je ne veux pas juste avoir une mémoire crue). Et en outre, il est complètement possible de programmer à l'aide de techniques qui éliminent presque totalement la possibilité de fuites de mémoire et de corruption (RAII), mais qui prend une expertise.
Hmmm. Malloc ne fait pas "ce dont vous avez besoin?" Enfer, règles de mémoire brute et prouve votre mette en tant que programmeur. Essayez d'hériter d'un programme C avec des centaines de milliers de lignes de C, des milliers de mallocs et d'une base X-Windows et de migrer vers C ++. Certains d'entre nous ne nous dérangent pas malloc / gratuitement et ne sont pas confondus sur la façon dont ils travaillent et diffèrent de la nouvelle / Supprimer. Mais je suppose que c'est une question de combien d'années vous avez été dans ce biz. Je suis une vieille pêche (mais adaptable).
@xcramps: il y a un approprié moyen d'utiliser la mémoire brute en C ++ et c'est pas malloc : ICCE.RUG.NL/DOCTIONS/CPLUSPLUS/CPLUSPLUS08.HTML#L128
Malloc va bien pour la mémoire brute, mais si vous voulez un objet , il ne le fait pas. Fine, utilisez MALLOC + Placement Nouveau + Destructeur manuel + gratuit si vous le devez.
[...] C / C ++ C'est une langue précise bien connue. [...]
En fait, c'est faux. en fait, "c / c ++" n'existe même pas. il y a c , et il y a
< em> c ++ . Ils partagent certains (ou, si vous le souhaitez, beaucoup de syntaxe, mais ils sont en effet langages très différents . Une chose qu'ils diffèrent considérablement est leur moyen de gérer la mémoire dynamique. Le type C utilise effectivement
malloc () /gratuit () et si vous avez besoin de mémoire dynamique, il y a très peu d'autre que vous pouvez faire, mais les utiliser (ou quelques frères et sœurs de < Code> malloc () ).
la manière C ++ est de ne pas (manuellement) affaire avec des ressources dynamiques ( dont la mémoire n'est qu'un) du tout . La gestion des ressources est transmise à quelques classes bien implémentées et à l'œuvre, de préférence à partir de la bibliothèque standard, puis effectuée automatiquement. Par exemple, au lieu de traiter manuellement avec des tampons de caractères zéro, il y astd :: string , au lieu de traiter manuellement des tableaux alloués dynamiquement, ilstd: vecteur , au lieu de Traiter manuellement avec des fichiers ouverts, il y a lastd :: FRStream famille de flux, etc.
En effet, j'utilise uniquement des types de vecteurs, lorsque j'ai reçu des tableaux d'images au format RAW. (Opencv)
"Il y a C, et il y a C ++." - C'est ce que c'est le cas maintenant, mais ce n'était pas toujours le cas (les premières implémentations C ++ ont traduit tous les codes C ++ à c puis les compilèrent avec un compilateur C ". Son ami pourrait maintenant être familier avec la façon dont les choses avaient été.
@sheepsiminulator: Désolé, mais je ne vous suis pas du tout. Qu'est-ce qui compte ce que C ++ Code utilisé pour être traduit? FWIW, les fichiers YACC sont toujours traduits en code C, qui est ensuite compilé par un compilateur C. Souhaitez-vous affirmer qu'il existe une ressemblance entre le paradigme de programmation déclaratif des fichiers YACC et le paradigme structuré de C, juste parce que les fichiers de YACC sont traduits en C? Existe-t-il une famille de langue YACC / C? Et C ++ est principalement traduit en code machine maintenant. Est-ce que cela est pertinent? Voulez-vous prétendre qu'il y a une famille de langue C ++ / Machinecode?
Je vais bien admettre que C ++ était une fois plus proche de C que maintenant. Mais C ++ a maintenant une ressemblance syntaxique superficielle à C. une classe en C ++ (même si orthographié struct ) est quelque chose de fondamentalement différent d'un C struct . Et cela ne mentionne même pas l'héritage, les exceptions, les modèles ... C ++ prend en charge des paradigmes structurés, orientés objet, génériques, génératifs, fonctionnels et autres paradigmes. C prend directement en charge la programmation structurée uniquement. Là, dans la programmation structurée, ils se ressemblent. Mais, mettant de côté la syntaxe, C ++ en a tout autant semblable à Pascal et à d'autres langages structurés paradigmes.
@SBI - Lisez la réponse que j'ai donnée, et peut-être que mon commentaire fera un peu plus de sens ... Certains programmeurs font des hypothèses incorrectes sur les choses.
@sheepsiumulator: Je viens de le faire, et je suis toujours en désaccord avec votre commentaire.
+1 pour "C / C ++ n'existe pas". C'est une majeure partie de la mine.
en C ++, il n'y a pas de problème de ce type si vous vous tenez à de bonnes conventions. En C, bien, pratique. Malloc lui-même n'est pas une fonction intrinsèquement non sécurisée du tout - les gens peuvent simplement traiter avec ses résultats inadéquatement.
Peut-être que votre ami est plus âgé et n'est pas familier avec la façon dont les choses fonctionnent maintenant - j'avais l'habitude de penser que c et C ++ étaient effectivement les mêmes jusqu'à ce que j'ai découvert de nombreuses nouvelles choses sur la langue qui ont été publiées au cours des 10 dernières années ( La plupart de mes professeurs étaient des laboratoires de cloche anciens de la vieille école qui a écrit principalement en C et n'avait qu'une connaissance curseure des ingénieurs C ++ - et Bell Laboratories inventé C ++!). ne vous moquez pas de lui / elle - vous pourriez être là un jour aussi!
Je pense que votre ami est inconfortable avec l'idée que vous devez faire votre propre gestion de la mémoire - c'est-à-dire que c'est facile à faire des erreurs. À cet égard, il n'est pas sûr et il / elle est correct ... Cependant, cet aspect non sécurisé peut être surmonté avec de bonnes pratiques de programmation, telles que RAII et en utilisant des pointeurs intelligents.
Pour de nombreuses applications, cependant, la collecte automatisée des ordures est probablement bien, et certains programmeurs sont confus quant à la manière dont les pointeurs fonctionnent, de sorte que de nouveaux développeurs inexpérimentés pour programmer efficacement en C / C + sans une formation. Ce qui est peut-être pourquoi votre ami pense que C / C ++ devrait être évité.
Il n'est pas sécurisé d'utiliser MALLOC car il n'est pas possible d'écrire une application à grande échelle et d'assurer que chaque MALLOC est libéré dans une manière . Ainsi, vous aurez des tonnes de fuites de mémoire qui peuvent ne pas être un problème ... mais , lorsque vous double Le mode pour le code écrit dans une langue comme C ou C ++ à être sécurisé est de prouver mathématiquement le programme entier avec ses dépendances intégrées.
Les langues modernes-coffre-fort sont à l'abri de ces types de bogues tant que la mise en œuvre de la langue sous-jacente n'est pas vulnérable (ce qui est vraiment rare, car ils sont tous écrits en C / C ++, mais à mesure que nous progressons vers le matériel JVMS, cette problème disparaîtra). libres ou utilisez le mauvais Supprimer < / Code> etc. Le comportement non défini peut en résulter. En effet, en utilisant le mauvais Supprimer en C ++ permettra généralement une exécution de code arbitraire.
Peut-être que la personne faisait référence à la possibilité d'accéder aux données via malloc ()?
MALLOC n'affecte pas le contenu de la région qu'il fournit, il peut donc être possible de collecter des données d'autres processus en mallocing une grande surface, puis à la numérisation du contenu.
GRATUIT () ne fonctionne pas la mémoire non plus, les données rythmées dans des tampons alloués dynamiquement sont, en principe, accessibles.
Je connais une personne qui, il y a de nombreuses années, a exploitait MALLOC pour créer un programme de communication inter-processus lorsqu'il a constaté que Mallocs de taille égale retournerait l'adresse du plus récemment libéré.
C ++ utilise généralement
Nouveau etSupprimer au lieu demalloc etgratuitQu'entendez-vous par «sécurisé»? Et si votre "ami" vous a dit cela, pourquoi ne pas le faire expliquer ce qu'il veut dire?
A-t-il donné des raisons de l'appeler non sécurisée?
Les généralités vagues n'ont pas de sens. Si vous souhaitez réclamer quelque chose comme une insécurité, vous devez définir pourquoi il n'est pas sécurisé.
Un cadenas est-il un moyen sécurisé de verrouillage d'une porte? Si utilisé correctement sur une clôture suffisamment grande et un loquet fort; Oui. malloc () est très lâchement comme l'ensemble des boulons qui apposent le loquet à la clôture: utilisez le cadenas correctement pour implémenter un logiciel sécurisé; Tant que les boulons sont rapides, le cadenas sera utile. Par analogie, MALLOC () utilisé de manière incorrecte liée à des boulons en vrac sur le loquet cadenassé. E.G., un programme (zone clôturée) pourrait implémenter des ACLS (cadenas), mais s'il ya des bogues à l'aide de MALLOC () (boulons en vrac), le programme peut alors être cassé dans (la porte transversale).
Votre «ami» semblerait être remarquablement ignorant, ou peut-être un troll.
Je lui donnerais un avantage du doute et dis-je ignorant. Au moins, son ami dit des choses que je disais, jusqu'à ce que je commence à entrer dans le développement de C ++ et à lire plus. La gentillesse et un esprit éducatif peuvent aller très loin.