Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Analyste
    Inscrit en
    juillet 2013
    Messages
    2 289
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Analyste
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 2 289
    Points : 74 656
    Points
    74 656
    Billets dans le blog
    2
    Par défaut Linux Foundation initie un nouveau programme pour améliorer la sécurité des logiciels open-source
    Linux Foundation initie un nouveau programme
    Pour améliorer la sécurité des logiciels open-source

    Mieux vaut prévenir que guérir. Les leaders de l’open source multiplient les efforts pour renforcer la sécurité des logiciels open source, avant qu’ils ne deviennent une cible fréquente pour les pirates.

    Le mois dernier, dans le cadre de son projet baptisé Core Infrastructure Initiative (CII), la fondation Linux a fait un examen des logiciels open source Linux Debian afin d’en déterminer ceux qui nécessitent plus d’attention de la part des développeurs du point de vue de la sécurité. L’objectif était de pouvoir ensuite mobiliser les ressources humaines et financières pour renforcer la sécurité de ces projets.

    Le CII est en fait un projet qui réunit entreprises de technologie, développeurs et certains acteurs de l’industrie. Tous doivent collaborer pour identifier et financer les projets de logiciels libres et open source essentiels pour le fonctionnement de l’Internet et d’autres grands systèmes d’information qui ont besoin d’une assistance.

    Le fait est que de plus en plus de services en ligne utilisés aujourd’hui reposent sur les logiciels open source. Ce qui pourrait donc progressivement attirer l'attention des pirates à la recherche de failles dans la sécurité des logiciels à exploiter. Pour protéger les services en ligne qui reposent sur l’open source, Linux Foundation veut compter sur une équipe dédiée de professionnels de sécurité pour anticiper les éventuels problèmes de sécurité et les corriger.

    Dans la poursuite de son objectif de sécurité, le projet Core Infrastructure Initiative a initié un nouveau programme baptisé Badge Program. A travers ce programme axé sur la sécurité, le CII invite la communauté open source à faire des propositions sur les critères à utiliser pour déterminer la sécurité, la qualité et la stabilité des logiciels open source.

    Le Badge Program est destiné à encourager les projets de logiciels open source à prendre en considération à la fois la sécurité et la qualité et aider les utilisateurs à savoir quels projets prennent en considération ces différents aspects. Il vise à garantir un « modèle de développement open source sécurisé ». Il permettra de s’assurer que « les nouveaux projets ne dépendent que des projets open source les plus sains, améliorant ainsi notre infrastructure mondiale de l’Internet », explique Emily Ratliff, directeur senior de la sécurité d’infrastructure chez Linux Foundation.

    Une première ébauche du projet de critères est disponible sur GitHub et est dirigée par David Wheeler, un expert de l'open source et de la sécurité qui travaille pour l'Institut for Defense Analyses (IDA) et Dan Kohn, un conseiller senior du projet CII.

    Le CII a également renforcé son conseil consultatif par deux personnalités imminentes de la cyber-sécurité. Il s’agit d’Adam Shostack, membre du conseil d’examen du BlackHat, et Tom Ritter, directeur de Cryptography Services de CCN Group.

    Source : Market Wired, GitHub

    Et vous ?

    Que pensez-vous des efforts de Linux Foundation pour renforcer la sécurité des projets open source ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Rédacteur

    Avatar de Davidbrcz
    Homme Profil pro
    Ing Supaéro - Doctorant ONERA
    Inscrit en
    juin 2006
    Messages
    2 307
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ing Supaéro - Doctorant ONERA

    Informations forums :
    Inscription : juin 2006
    Messages : 2 307
    Points : 4 235
    Points
    4 235
    Par défaut
    Arrêtons d'écrire des logiciels en C, et le sécurité sera mécaniquement augmentée.
    "Never use brute force in fighting an exponential." (Andrei Alexandrescu)

    Mes articles dont Conseils divers sur le C++
    Une très bonne doc sur le C++ (en) Why linux is better (fr)

  3. #3
    Membre du Club
    Femme Profil pro
    Ingénieur systèmes et réseaux
    Inscrit en
    août 2015
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 49
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur systèmes et réseaux

    Informations forums :
    Inscription : août 2015
    Messages : 13
    Points : 50
    Points
    50
    Par défaut
    Citation Envoyé par Davidbrcz

    Arrêtons d'écrire des logiciels en C, et le sécurité sera mécaniquement augmentée.
    Exact, mieux vaudrait un noyau Linux écrit en Visual Basic.

  4. #4
    Rédacteur

    Avatar de Davidbrcz
    Homme Profil pro
    Ing Supaéro - Doctorant ONERA
    Inscrit en
    juin 2006
    Messages
    2 307
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ing Supaéro - Doctorant ONERA

    Informations forums :
    Inscription : juin 2006
    Messages : 2 307
    Points : 4 235
    Points
    4 235
    Par défaut
    Citation Envoyé par Goedulf Voir le message
    Exact, mieux vaudrait un noyau Linux écrit en Visual Basic.
    Essayons d'être constructif :

    Le C est un langage de niche qui ne doit être réservé qu'à quelques cas particuliers (composant systèmes bas niveau, systèmes embarqués, code glu entre 2 langages,...).

    Un bon paquet de logiciels qu'on utilise tout les jours gagnerait en sécurité et en simplicité à ne pas être écrits en C. Après y'a l'inertie technique, mais quand même...
    Plus vite on circonscrira le C aux endroits où il est indispensable, mieux on se portera.
    "Never use brute force in fighting an exponential." (Andrei Alexandrescu)

    Mes articles dont Conseils divers sur le C++
    Une très bonne doc sur le C++ (en) Why linux is better (fr)

  5. #5
    MikeRowSoft
    Invité(e)
    Par défaut
    Citation Envoyé par Davidbrcz Voir le message
    Essayons d'être constructif :

    Le C est un langage de niche qui ne doit être réservé qu'à quelques cas particuliers (composant systèmes bas niveau, systèmes embarqués, code glu entre 2 langages,...).

    Un bon paquet de logiciels qu'on utilise tout les jours gagnerait en sécurité et en simplicité à ne pas être écrits en C. Après y'a l'inertie technique, mais quand même...
    Plus vite on circonscrira le C aux endroits où il est indispensable, mieux on se portera.
    Comme d'habitude le radicale sur les conditions d'usages a détrôner l'appauvrissement de langages pour des circonstances données.
    Cependant rien au sujet de la N.S.A. et de leurs équivalents des autres pays (si il y en a).
    Encore moins au sujet de beaucoup plus sensible en étique...
    Dernière modification par MikeRowSoft ; 20/08/2015 à 05h00.

  6. #6
    Membre expert Avatar de jopopmk
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mars 2011
    Messages
    1 846
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2011
    Messages : 1 846
    Points : 3 509
    Points
    3 509
    Par défaut
    Citation Envoyé par Davidbrcz Voir le message
    Arrêtons d'écrire des logiciels en C, et le sécurité sera mécaniquement augmentée.
    Au profit du C++ ... ?
    Plus je connais de langages, plus j'aime le C.

  7. #7
    Rédacteur
    Avatar de imikado
    Homme Profil pro
    Ingénieur développement
    Inscrit en
    décembre 2006
    Messages
    5 197
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement
    Secteur : Finance

    Informations forums :
    Inscription : décembre 2006
    Messages : 5 197
    Points : 19 334
    Points
    19 334
    Billets dans le blog
    17
    Par défaut
    Vous pensez que IE est écrit en C ?

    Idem pour les sites internet, dont nombre d'entre eux souffrent de failles (xss, xsrf, sql injection, null byte...)

    Le langage ne fait pas tout
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

  8. #8
    Membre éclairé Avatar de Beanux
    Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    octobre 2009
    Messages
    249
    Détails du profil
    Informations personnelles :
    Âge : 31
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : octobre 2009
    Messages : 249
    Points : 736
    Points
    736
    Par défaut
    Citation Envoyé par Davidbrcz Voir le message
    Arrêtons d'écrire des logiciels en C, et le sécurité sera mécaniquement augmentée.
    Citation Envoyé par Davidbrcz Voir le message
    Essayons d'être constructif :

    Le C est un langage de niche qui ne doit être réservé qu'à quelques cas particuliers (composant systèmes bas niveau, systèmes embarqués, code glu entre 2 langages,...).

    Un bon paquet de logiciels qu'on utilise tout les jours gagnerait en sécurité et en simplicité à ne pas être écrits en C. Après y'a l'inertie technique, mais quand même...
    Plus vite on circonscrira le C aux endroits où il est indispensable, mieux on se portera.
    Comme tu dis, soyons constructif,
    Tu as des exemple de langages "sûr" ?
    Tu as des arguments à apporter pour justifier que C est moins sûr ?
    Mis à par que ce soit un langage plutôt bas niveau et qu'il y est plus simple de faire des erreurs (donc erreurs provenant du développeur).


    Le langage est loin de d’être les premières raisons de l'insécurité du code.

  9. #9
    Membre du Club
    Femme Profil pro
    Ingénieur systèmes et réseaux
    Inscrit en
    août 2015
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 49
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur systèmes et réseaux

    Informations forums :
    Inscription : août 2015
    Messages : 13
    Points : 50
    Points
    50
    Par défaut
    Citation Envoyé par Davidbrcz
    Essayons d'être constructif :

    Le C est un langage de niche qui ne doit être réservé qu'à quelques cas particuliers (composant systèmes bas niveau, systèmes embarqués, code glu entre 2 langages,...).

    Un bon paquet de logiciels qu'on utilise tout les jours gagnerait en sécurité et en simplicité à ne pas être écrits en C. Après y'a l'inertie technique, mais quand même...
    Plus vite on circonscrira le C aux endroits où il est indispensable, mieux on se portera
    Ah pardon je pensais que c'était pour plaisanter alors j'ai feed...
    Je ne suis pas sûr qu'on puisse dire aussi facilement que ça que tel language est plus sécurisé que le C, ni même cantonné celui-ci à de l'utilisation purement bas niveau
    Comme dit précédemment, on ne peut pas réduire la sécurité au simple choix d'un language, ça se saurait

  10. #10
    Membre émérite
    Inscrit en
    juin 2009
    Messages
    910
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 910
    Points : 2 721
    Points
    2 721
    Par défaut
    Citation Envoyé par Beanux Voir le message
    Comme tu dis, soyons constructif,
    Tu as des exemple de langages "sûr" ?
    d'un point de vu manipulation de la mémoire, je pense que l'ADA peut limiter pas mal de truc.
    J'ai ouïe dire aussi que par conception les langages fonctionnels garantissent l'absence d'effet de bord, donc par conception aussi, limiter certains problèmes (en général difficiles à débusquer en plus).

    Après pour moi le problème est global, il n'y a pas de raison d'attaquer le C.

  11. #11
    Inactif  

    Homme Profil pro
    NR
    Inscrit en
    juin 2013
    Messages
    3 715
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2013
    Messages : 3 715
    Points : 1 033
    Points
    1 033
    Billets dans le blog
    9
    Par défaut
    En quoi changer de langage apporterais une meilleur sécurité ?
    C'est comme avec les bugs, c'est pas en changeant de langage qu'ils vont se corriger tous seul.

    Les failles proviennes des logiciels que les développeurs convoient, rarement du langage ou du compilateur.

    Bien évidement je parle uniquement des langages matures et qui sont activement suivie, (comme le C et le compilateur gcc...)

  12. #12
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 260
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 260
    Points : 3 455
    Points
    3 455
    Billets dans le blog
    12
    Par défaut
    Le compilateur GCC n'est pas exempt de bug, beaucoup le critique pour diverses raisons.
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  13. #13
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    avril 2002
    Messages
    3 892
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : avril 2002
    Messages : 3 892
    Points : 11 330
    Points
    11 330
    Par défaut
    Citation Envoyé par imikado Voir le message
    Vous pensez que IE est écrit en C ?
    IE est en C++ il me semble, ce qui n'est pas forcément mieux niveau sécurité non plus, surtout que vu son age, il y a fort a parier qu'il repose fortement sur du code pré C++11.

    Citation Envoyé par imikado Voir le message
    Idem pour les sites internet, dont nombre d'entre eux souffrent de failles (xss, xsrf, sql injection, null byte...)
    Les failles Web et applicatives sont deux domaines relativement distincts.

    Un langage plus adapté ne résoudra évidement pas les failles venant de mauvais algorithmes, mais ça devrait pouvoir réduire voire faire complètement disparaitre certaines erreurs classiques, particulièrement pour ce qui est des failles dues à la sécurité mémoire qui comptent parmi les plus courantes et les plus dangereuses en C et C++.

    Citation Envoyé par Beanux Voir le message
    Comme tu dis, soyons constructif,
    Tu as des exemple de langages "sûr" ?
    La grande majorité des langages est plus sure que le C et le C++. C'est notamment le cas des langages de plus haut niveau (C#, Java, Go, ...)
    Parmi les langages conçus pour être particulièrement sûr au niveau de la gestion de la mémoire, tout en restant de plus bas niveau, on peut citer le vénérable l'Ada, ou le plus récent Rust.

    Citation Envoyé par Beanux Voir le message
    Tu as des arguments à apporter pour justifier que C est moins sûr ?
    Mis à par que ce soit un langage plutôt bas niveau et qu'il y est plus simple de faire des erreurs (donc erreurs provenant du développeur).
    Tu as répondu toi même à la question : c'est un langage bas niveau qui n'a aucun garde fou et qui permet facilement de corrompre la mémoire sans s'en rendre compte.

    Comme toute les failles, c'est, en effet, des erreurs de programmation, mais il faut prendre en compte que les hommes, même les meilleurs, ne sont pas infaillibles. Tout expert en sécurité sait que concentrer sa sécurité sur la compétence des développeurs, c'est insuffisant. Il y a aussi des outils pour aider a gérer ça mais la complexité du langage fait que ils ne pourront jamais tout garantir non plus.

    Même dans les projets le plus surveillés comme le navigateurs, près de la moitié des failles sont liées à la gestion mémoire. Ce n'est pas pour rien que Mozilla a créé Rust, un nouveau langage plus sûr pour travailler sur l’éventuel remplaçant de Gecko.

    Citation Envoyé par Beanux Voir le message
    Le langage est loin de d’être les premières raisons de l'insécurité du code.
    L'erreur est forcément humaine à la base. Si on savait toujours éviter les erreurs, on n'aurait pas de faille, même avec le pire des langages.
    Ceci dit comme nul n'est parfait, si le langage peut aider l'humain à éviter de faire certaines erreurs, c'est bon à prendre.

  14. #14
    En attente de confirmation mail
    Profil pro
    Inscrit en
    décembre 2010
    Messages
    555
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2010
    Messages : 555
    Points : 1 583
    Points
    1 583
    Par défaut
    Au risque d'enfoncer des portes ouvertes, un code lisible et maintenable est la base pour obtenir un logiciel sécurisé.

    Pas besoin d'utiliser des mécanismes ultra-spécifiques d'un langage particulier sauf si ça permet de gagner en clarté (comme les user defined literals en C++11).
    L'utilisation d'un framework peut aider à avoir une écriture uniforme parmi les contributeurs et permettre d'intégrer du code "unsafe".

    Le langage importe peu, il vaut mieux qu'un expert écrive du beau code dans son langage de prédilection plutôt qu'un paquet de merde dans un autre langage qu'il ne connait que superficiellement (Bon, on oublie de Brainfuck, quoi).

  15. #15
    Rédacteur

    Avatar de Davidbrcz
    Homme Profil pro
    Ing Supaéro - Doctorant ONERA
    Inscrit en
    juin 2006
    Messages
    2 307
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ing Supaéro - Doctorant ONERA

    Informations forums :
    Inscription : juin 2006
    Messages : 2 307
    Points : 4 235
    Points
    4 235
    Par défaut
    Au profit du C++ ... ?
    Non, le langage est devenu bien trop expert only.

    Tu as des exemple de langages "sûr" ?
    Tu as des arguments à apporter pour justifier que C est moins sûr ?
    N'importe quel langage qui interdit une arithmétique des pointeurs et un accès libre à la mémoire.


    Le langage est loin de d’être les premières raisons de l'insécurité du code.
    utiliser le C pour développer une application hors de son champs d'application, c'est comme la libre circulation des armes à feu. Dans un monde parfait, avec des gens compétents, sérieux et responsables, ca pose pas de soucis. On connait tous la réalité

    En quoi changer de langage apporterais une meilleur sécurité ?
    • Heartbleed : accès mémoire foireux
    • Apple : SSL double goto car y'a pas de mécanisme de gestion des erreurs.
    • Et je passe sous silence les buffers overflow que permet le C...


    Le C est une source sans fin de bugs exploitables.

    C'est comme avec les bugs, c'est pas en changeant de langage qu'ils vont se corriger tous seul.
    Les failles proviennes des logiciels que les développeurs convoient, rarement du langage ou du compilateur.
    Changer de langage permet de grandement diminuer le risque de bug. Ca corrigera pas une logique applicative foireuse par contre.
    "Never use brute force in fighting an exponential." (Andrei Alexandrescu)

    Mes articles dont Conseils divers sur le C++
    Une très bonne doc sur le C++ (en) Why linux is better (fr)

  16. #16
    Expert éminent Avatar de BufferBob
    Profil pro
    responsable R&D vidage de truites
    Inscrit en
    novembre 2010
    Messages
    2 855
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : responsable R&D vidage de truites

    Informations forums :
    Inscription : novembre 2010
    Messages : 2 855
    Points : 7 855
    Points
    7 855
    Par défaut
    Citation Envoyé par Davidbrcz Voir le message
    N'importe quel langage qui interdit une arithmétique des pointeurs et un accès libre à la mémoire.
    du coup tu fais quoi avec ? y'a bien le LOGO (et encore ) sinon je vois pas trop quel langage empêche d'écrire dans la mémoire...

    • Heartbleed : accès mémoire foireux
    • Apple : SSL double goto car y'a pas de mécanisme de gestion des erreurs.
    • Et je passe sous silence les buffers overflow que permet le C...


    Le C est une source sans fin de bugs exploitables.
    autant je suis d'accord que le C est un langage compliqué et qu'il faut pas juste un développeur il faut un développeur très compétent pour coder proprement en C, autant ton argument ici est tout à fait foireux, le fait que le C puisse engendrer des failles c'est le concours du développeur peut-être pas totalement rompu aux risques et à la programmation sécurisée, mais aussi à la libc (cf des fonctions alternatives comme strcpy_s par exemple qui permettent moins de débordements, et donc pas directement le langage en lui même)

    qui plus est les systèmes ont depuis plusieurs années vu développer des contre-mesures pour éviter les exploitations, c'est assez standard de nos jours (ASLR, NX, PIE, grsec, propolice et autres canarys etc.), et il semble que ça ait été jugé plus rentable que de troquer C pour un autre langage avec tous les problèmes de rétro-compatibilité que ça aurait engendré

    enfin le "trop de liberté" que t'évoques et qui permet d'induire des trous, c'est finalement que le revers de la médaille si on considère tout ce qu'il permet de faire, et si on y regarde bien l'industrie n'est pas faite que de totos non plus; il y a énormément et de plus en plus d'applications "non-critiques" développées dans autre chose que C, il se trouve que pour l'instant on a toujours des apache, nginx, sendmail et autres codés en C, ils ont subit les overflows pendant des années, mais avec le recul aujourd'hui on considère aussi qu'ils ont fait leurs preuves, et des alternatives en Python, LUA, etc. commencent à pop doucement

    pour rappel on a arrêté depuis un moment de faire des CGI en C par exemple, et plus ça va moins on en fait en PHP, preuve que les choses avancent mine de rien...
    Avant donc que d'écrire, apprenez à penser.
    Selon que notre idée est plus ou moins obscure, l'expression la suit, ou moins nette, ou plus pure.
    Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément.
                                                        - Nicolas Boileau, L'Art poétique

  17. #17
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    avril 2002
    Messages
    3 892
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : avril 2002
    Messages : 3 892
    Points : 11 330
    Points
    11 330
    Par défaut
    Citation Envoyé par BufferBob Voir le message
    du coup tu fais quoi avec ? y'a bien le LOGO (et encore ) sinon je vois pas trop quel langage empêche d'écrire dans la mémoire...
    C'est fou les développeur C++ qui sont persuadés de tout connaître des autre langages.
    Evidement que tous les langages, même le logo manipulent la mémoire. Cela dit, il y a énormément de langages, qui permettent d'utiliser la mémoire via des pointeur ou d'autres mécanisme, tout en imposant un minimum de restriction, ou des contrôles qui permettent une bien meilleure sécurité.

    Je te conseille de te renseigner sur le Rust par exemple, qui permet d’empêcher les erreur mémoire tout en permettant un contrôle bas niveau comme le C/C++.

    Citation Envoyé par BufferBob Voir le message
    qui plus est les systèmes ont depuis plusieurs années vu développer des contre-mesures pour éviter les exploitations, c'est assez standard de nos jours (ASLR, NX, PIE, grsec, propolice et autres canarys etc.), et il semble que ça ait été jugé plus rentable que de troquer C pour un autre langage avec tous les problèmes de rétro-compatibilité que ça aurait engendré
    Et malgré ça les exploit lié a une corruption de la mémoire sont de loin les problèmes de sécurités les plus courants sur les grosse applications C/C++.

  18. #18
    Membre habitué
    Homme Profil pro
    Étudiant
    Inscrit en
    juillet 2014
    Messages
    28
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nièvre (Bourgogne)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juillet 2014
    Messages : 28
    Points : 137
    Points
    137
    Par défaut
    Sans trop rentrer dans le débat, mais ayant vu l'erreur à plusieurs reprises:

    C'est fou les développeur qui sont persuadés de connaître le C++ (humour pour ceux qui en douterait), alors même qu'ils semblent ignorer l'existence de ça bibliothèque standard.
    Utiliser std:: et la bonne partie des risques de buffers overflows sont éliminés (il peut y avoir avec une mauvaise utilisation de std::copy). Après je sais bien qu'avec une utilisation un peu à l'arrache des pointeurs on peut facilement faire des erreurs et que ça reste un langage exigeant par rapport à d'autre. Je pointe juste du doigt le fait que beaucoup des erreurs communément imputées aux C++ sont dues à l'utilisation des solutions du C à la place de celles du C++ (qui sont pourtant souvent plus simples). Et puis même en C, éviter les BO est plus une question de rigueur que de génie.

    Arrêtons de mélanger C et C++ comme un seul et même langage.

    Et quitte à me faire moinser, j'ajouterai que les VMs ne sont pas exemptes de tous défauts non plus (par rapport aux remarques sur JAVA et C#). Et l'utilisation d'un "mauvais" langage pour un projet n'est pas limité aux C, et le choix du langage n'est pas aussi trivial que ça (sinon ce débat n'existerait même pas).

  19. #19
    Membre confirmé
    Profil pro
    Inscrit en
    septembre 2009
    Messages
    181
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2009
    Messages : 181
    Points : 463
    Points
    463
    Par défaut
    Citation Envoyé par Betameche Voir le message
    C'est fou les développeur qui sont persuadés de connaître le C++ (humour pour ceux qui en douterait), alors même qu'ils semblent ignorer l'existence de ça bibliothèque standard.
    Utiliser std:: et la bonne partie des risques de buffers overflows sont éliminés (il peut y avoir avec une mauvaise utilisation de std::copy). Après je sais bien qu'avec une utilisation un peu à l'arrache des pointeurs on peut facilement faire des erreurs et que ça reste un langage exigeant par rapport à d'autre. Je pointe juste du doigt le fait que beaucoup des erreurs communément imputées aux C++ sont dues à l'utilisation des solutions du C à la place de celles du C++ (qui sont pourtant souvent plus simples). Et puis même en C, éviter les BO est plus une question de rigueur que de génie.
    Arrêtons de mélanger C et C++ comme un seul et même langage.
    Sauf que le langage (C ou C++) n'aide pas dans ce sens. Pour preuve, je suis pas sur que les failles cités précédemment aient étés commisses par des débutants. Et surtout quand tu fais des erreurs (mais que ton programme compile quand même) tu n'es pas certains de ce qui va se passer (undefined behavior). Chose qui est impossible dans d'autres langages. Enfin l'argument C != C++ me fait toujours rire. C++ est un sur ensemble de C (à un ou deux détails près) donc un développeur C++ se doit de maitriser le C. De même que de dire que le C++ simplifie la programmation aujourd'hui est assez discutable. Parce que le C++ n'existe pas en tant que tel, il existe le C++ 98, 11 et bientôt 17. Ça fait beaucoup de révision à connaitre pour un développeur et autant de chances de mélanger les pinceaux à un moment donné.

  20. #20
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    avril 2002
    Messages
    3 892
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : avril 2002
    Messages : 3 892
    Points : 11 330
    Points
    11 330
    Par défaut
    Citation Envoyé par Betameche Voir le message
    Utiliser std:: et la bonne partie des risques de buffers overflows sont éliminés. Arrêtons de mélanger
    La stdlib de C+11 c'est mieux que rien, mais c'est très loin d'être suffisant pour faire de C++ un langage sur.
    De plus l'héritage C est inamovible et c'est bien le premier problème. Son utilisation généralement plus naturelle que celle de la stdlib et la frontière entre ce qu'il est sur et ce qui ne l'est pas est loin d'être évidente.

    Citation Envoyé par Betameche Voir le message
    Et quitte à me faire moinser, j'ajouterai que les VMs ne sont pas exemptes de tous défauts non plus (par rapport aux remarques sur JAVA et C#).
    Ma remarque visait les langages et non les VM, même si les langages conçus pour VM prennent a ma connaissance tous en compte au moins la sécurité mémoire. Beaucoup de langages sans VM (Go, Haskell, Ada, Rust, ...) empêchent tout de même la plupart, voire la totalité des erreurs qui pourraient conduire à une corruption mémoire.

    Après en effet, même les langages les plus sûrs comme Ada ou Rust, peuvent abusés s'ils sont particulièrement mal utilisés, mais leur conception est faite pour minimiser au maximum le risque, là ou le C++ doit composer avec son héritage qui ignore totalement la problématique.

Discussions similaires

  1. Google initie un nouveau programme d’achats de brevets
    Par Siguillaume dans le forum Actualités
    Réponses: 10
    Dernier message: 30/04/2015, 15h28
  2. Réponses: 49
    Dernier message: 29/08/2010, 03h55
  3. programmation pour éviter le message: "des liaisons existent.."
    Par babou466 dans le forum Macros et VBA Excel
    Réponses: 2
    Dernier message: 04/03/2009, 15h29
  4. Nouveau programme pour débutant
    Par gregouz59 dans le forum Débuter
    Réponses: 4
    Dernier message: 02/06/2008, 18h45
  5. Réponses: 1
    Dernier message: 07/09/2006, 11h03

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo