Journal Linux c'est plein de trous

Posté par  .
Étiquettes : aucune
0
11
nov.
2004
"Linux ne vaut pas plus cher que Windows".
avec l'article :
http://www.reseaux-telecoms.com/cso_btree/04_11_10_162639_515/CSO/N(...)

et un nouveau petit trou:
http://lists.netsys.com/pipermail/full-disclosure/2004-November/028(...)

"Synopsis: Linux kernel binfmt_elf loader vulnerabilities
Product: Linux kernel
Version: 2.4 up to to and including 2.4.27, 2.6 up to to and
including 2.6.8"

pour finir en beauté le troll je rappelle que freebsd 5.3, openbsd 3.6
sont sortis, avec bientôt netbsd 2.0 ;)

  • # et le 2.6.9

    Posté par  . Évalué à 1.

    Le 2.6.9 est-il touché ?
    Apparemment non, mais j'ai pas pu tester...

  • # ???

    Posté par  (site web personnel) . Évalué à 4.

    Ca fait plusieurs fois que je vois ces chiffres, mais je me pose une question : si on prend au peid de la lettre ce qui est dit, les pourcentages ne tiennent pas du tout compte de la proportion des OS étudiés. Si MacOSX ou autre BSD représentaient moins de 5% des OS étudiés, les chiffres sont tout à fait logiques, la position de Linux pouvant alors être expliqué par une plus forte présente que ses concurrents côtés serveurs...
    Si quelqu'un peut m'éclairer sur le sujet, histoire que je puisse faire mes propres conclusions :)

    • [^] # Re: ???

      Posté par  . Évalué à 2.

      oui mais ta logique marche pas, windows est beaucoup plus répandu.

      • [^] # Re: ???

        Posté par  (site web personnel) . Évalué à 6.

        Dans la logique de l'article, les PC de particuliers ne sont pas particulièrement concernés et les pirates préfèrent les serveurs (ce que je comprend), et la posiiton des serveurs Linux dans ce domaine est quand même pas du tout la même que chez les particuliers...

  • # "Linux ne vaut pas plus cher que Windows".

    Posté par  . Évalué à 9.

    Et cet article ne vaut pas plus que son poids de PQ :)

    Les « install days » laissent parfois les boulangers-charcutiers et les poinçonneurs-maçons –en d’autres termes, les « non geeks »- un peu au dépourvu lorsqu’il s’agit de configurer ipchain ou récupérer un rpm salvateur sur un site situé au Zimbabwe oriental.

    Il me viendrait pas à l'esprit d'écrire des conneries pareilles sur ms win, alors qu'est ce qui passe bien par la tete des gens qui veulent autant troller ?

    Pourtant avec ses chiffres, le gars aurait pu faire une analyse sérieuse...
    C'est triste d'être aussi con.

    • [^] # Re: "Linux ne vaut pas plus cher que Windows".

      Posté par  . Évalué à 2.

      Peut-être que Linux ne vaut pas plus cher que Windows sur le plan de la sécurité quoi que la comparaison citée dans l’article semble légère mais financièrement parlant il est plus judicieux de dire que Windows + les applications associées coûte beaucoup plus cher que Linux.

    • [^] # Re: "Linux ne vaut pas plus cher que Windows".

      Posté par  . Évalué à 9.

      C'est sur qu'aller chercher un rpm sur un site situé au Zimbabwe oriental, c'est super dur : il faut se frayer un chemin a la machette, combattre les serpents a main nue et survivre aux moustiques pour enfin pouvoir obtenir ce qu'on cherche.

    • [^] # Re: "Linux ne vaut pas plus cher que Windows".

      Posté par  . Évalué à 9.

      configurer ipchain

      Sans doute un expert qui suit le développement de Linux!

    • [^] # Re: "Linux ne vaut pas plus cher que Windows".

      Posté par  . Évalué à 1.

      Bah c'est sur que le fils de la boulangere du coin quand il passe l'apres midi à t'installer Windows , au moins quand il part le PC est une vraie forteresse contre les virus et autres crackers...
      Et surtout il a tout bien expliqué le fonctionnement interne de l'os.

      Tandis que le fils du boucher , quand il tente d'amorcer une conversation sur Linux , on voit bien qu'il est palot , qu'il passe trop de temps sur son PC , qu'il porte des lunettes pas belles , qu'il est mal rasé , et qu'en plus son truc à la mode la , c'est pour les jeunes qui font rien de leurs journées donc qui ont le temps pour leurs ordis...

  • # Compétences des Kernels Hackers.

    Posté par  (site web personnel) . Évalué à 5.

    Je ne discute pas les compétences de tous les kernels hackers, mais de certains ayant que quelques notions de devel d'OS. Ce dont je veux dire, c'est qu'il y a de plus en plus de failles de sécurités, alors qu'avant, au sein même du kernel, il n'y en avait pas autant sur toute une année.

    Je trouve que le kernel perd de sa stabilité, de son efficacité avec le temps.

    Est-ce que les gens se disent, "je code dans le kernel et c super, je me la pète" et ne vérifient pas leur code ?, où ont-ils un manque de connaissances sur le Software Engineering et la possibilité de coder du code correct ?

    C'était mon ptit coup de gueule

    • [^] # Re: Compétences des Kernels Hackers.

      Posté par  . Évalué à 4.

      Je ne crois pas que c'est la cas des personnes qui s'occupent de l'elf loader!

      D'accord avec toi si ça serais une multiplication de vulnerabilités dans des modules d'un accesoire exotique pour geek.

      Le kernel s'enrichit de plus en plus de fonctionalités, et forcement plus il grossit plus il va en y avoir de plus en plus. Faut pas oublier non plus que le projet est énorme. Il n'a rien a voir en taille et en nombre de fonctionnalités avec un open bsd trés sécurisé par exemple.

      Dans l'avenir il faudra faire un choix, celui d'avancer vite en sortant pleins de nouveautés où d'aller plus doucement en faisant du code plus soigné.

      • [^] # Re: Compétences des Kernels Hackers.

        Posté par  (site web personnel) . Évalué à 3.

        Je trouve simplement regrettable que les notions de programmation fondamentale au niveau du debugging, ou de la conception ne soit pas ou plus prise en compte.

        Nombre de fois, ou je lis du code de devel qui ne check pas les accès ressources, c'est un peu reloud, et pourtant, ça se dit grand devel.

        Tout le monde est d'accord de dire, il faut un noyau ayant un nombre de fonctionnalités croissant. Mais il faut aussi que la base du chateau de carte soit stable. Et je vois qu'au fur et à mesure du temps, des bugs énormes commencent à être trouvé dans le code.

        J'ai peur qu'avec le temps et les bugs que l'on découvre, que l'on vienne dire que les logiciels libres ne sont pas si sécurisé et si stable qu'il l'était avant. Simplement par la faute de personnes faisant du code sans vérifier la conception de celui-ci, ce qui au fil du temps risque de casser toute la structure actuelle.

        Ne serait-il pas temps de commencer à regarder tout le code fourni et de checker la gestion mémoire, les algos, les accès fichiers/réseaux, etc... ? Auditer le code ne permettra peut-être pas d'ajouter des fonctionnalités, mais sans cela, je pense qu'au fur et à mesure le code ne sera plus utilisé par excès de bugs.

        Le logiciel libre est la possibilité de montrer que l'on peut créer un outil stable, robuste grace à la connaissance de toutes les personnes. Le problème est que si un bon développeur commence à faire des erreurs, les débutants qui reliront son code, ne verront pas l'erreur et la dupliqueront dans leur propre code à eux. Et après pour corriger tout cela, bonjour les dégats.

        Voilà ce que je pense.

        L'art de coder, c'est l'art d'écrire un poème pour un ordinateur. Si il est beau, bien conçu, il ne sera jamais oublié.

        Lire le code d'un autre, c'est vraiment super, quand celui-ci est bien écrit.

        • [^] # Re: Compétences des Kernels Hackers.

          Posté par  . Évalué à 2.

          J'espère sincérement que des gros projets libres subiront des audits COMPLETS du code : le kernel, mozilla... Ça leur fera du bien, tant pour les perfs que pour la sécu que pour les bugs...
          D'ailleurs, c'est un truc bien dans KDE 4 : le passage à QT4 va demander pas mal de relecture de code !

          • [^] # Re: Compétences des Kernels Hackers.

            Posté par  . Évalué à 2.

            Vaudrait mieux partir sur de bonnes bases que relire les millions de lignes de codes.
            Dés lé début il devrait y avoir une doc et des critères de codage.

            • [^] # Re: Compétences des Kernels Hackers.

              Posté par  (site web personnel) . Évalué à 1.

              Comment veux-tu établir des critères sur un projet dont tu ne connais pas l'envergure 10 ans à l'avance ?

              Le problème est qu'actuellement, on colmate des fuites aussi bien sur le noyau que sur d'autres projets, mais ce n'est pas en colmatant qu'un navire tient le cap. Il faut parfois le mettre à quai et refaire la coque complètement.

              Ok, Linux est devenu un beau projet, mais à force d'accumuler les erreurs, la sécurité et stabilité ne seront plus des arguments valorisant Linux et les logiciels libres. Seul le prix sera un argument, et cela deviendra un simple "freeware".

              La personne qui s'investit dans un patch (ajout de fonctionnalté, correction de bugs) doit tout de même se dire que si il fait une bourde, ça diminue la crédibilité de ce logiciel envers ses utilisateurs.

          • [^] # Re: Compétences des Kernels Hackers.

            Posté par  (site web personnel) . Évalué à 1.

            Parfois dans une course, il est bon de se ressourcer un petit peu, de se calmer et de penser correctement à la prochaine étape. En allant trop vite, on se casse la gueule. N'y a-t-il pas moyen de créer un tools permettant de tracer tous les pointeurs, vérifier leur initialisation, vérifier qu'ils sont bien désallouer, vérifier les types des variables, etc... créer un tools qui affiherait un graphe contenant les appels de toutes les fonctions ?

            Diminuer le code redondant, créer un ensemble de spécifications (style une interface de base pour la création de modules pour du hard ou software ? ).

            Avec toute l'imagination que l'on possède, les outils que nous possédons actuellement, n'est-il pas moyen de créer un outil permettant d'auditer du code ?.

            Quelqu'un a une idée ?

            • [^] # Re: Compétences des Kernels Hackers.

              Posté par  . Évalué à 2.

              Ben je dirais qu'il y a certainement deja quelques outils (generiques) qui existent deja, genre valgrind et kcachegrind.

              Il me semble d'ailleurs que Linus en (les problemes sus-evoques) est conscient, et qu'il est justement en train de bosser sur un outil de verification de code (il me semble cependant que c'est assez Linux-oriente).

              • [^] # Re: Compétences des Kernels Hackers.

                Posté par  (site web personnel) . Évalué à 2.

                Cool, enfin une réponse qui m'intéresse.

                1) Checker les variables, type, initialisation
                2) pointeur : allocation mem, desallocation
                3) ressource : hd, network, etc...
                4) avoir du code lisible et pas un farfouilli de spaghetti sauce bolognèse (ça me donne faim :-)).

                5) être beaucoup plus sérieux dans les codes que l'on envoit.

            • [^] # Re: Compétences des Kernels Hackers.

              Posté par  . Évalué à 2.

              Concernant KDE, ils ont un outil qui contrôle leur code à la recherche d'erreurs particulières : http://www.icefox.net/kde/tests/(...)
              Particulièrement efficace à mon goût, vu les gains qu'il engendrera quand tout sera corrigé...

              • [^] # Re: Compétences des Kernels Hackers.

                Posté par  . Évalué à 2.

                L'url ca doit plutot etre ca :)
                http://www.icefox.net/kde/tests/report.html(...)

                Mais c'est vrai que ca a l'air interessant.
                Dans le soft sur lequel je bosse, il est recommande dans les regles de programmation de toujours soumettre dans le package dont on est l'auteur un petit test des classes et algorithmes developpes. Ainsi, a chaque build de la release (et aussi pour chaque nightly) on a les resultats des differents tests.
                Ca utilise du CppUnit et aussi 2-3 scripts python pour les tests RunTime...

            • [^] # Re: Compétences des Kernels Hackers.

              Posté par  . Évalué à 3.

              > n'est-il pas moyen de créer un outil permettant d'auditer du code ?.

              SWAT... (d'ailleur si tu lisais lkml ou hackers au lieu de troller ici et sur irc tu aurais deja remarque qu'ils postent assez regulierement les problèmes qu'ils trouvent).

              Enfin croire qu'un tel outil va corriger tout les trous c'est croire au pere noel. Tu penses pas que si c'etait possible ca se saurait depuis tres longtemps et on serait tous au chomage.

              Tu sais même sur les projets type spacial, avec de la preuve formelle sur de petit bout du code et du soft redondant (tu pars des memes specifications et tu as deux implementations) etc. on arrive encore a faire exploser des fusees. Alors penses tu pour un ouvrage de la taille d'une distrib.

              De même a cours terme aucun outil ne te diras que tu as mal verifier la valeur de retour d'une fonction en C. Les excetions sont beaucoup moins casse geule de ce côte la...

              On peut auditer automatiquement sur des choses plus ou moins triviales, en userland on peut facilement detecter les erreurs memoires, en kernel land on peut assez facilement detecter les erreurs de mutex. Pour le reste...


              Pour tes grands conseils sur les devels en carton regarde du cote de FreeBSD. Le dernier adviso, syscons, si tu cherches qui a commis la bourde tu tombes sur ce commit : http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/syscons/syscons.c(...) regarde son auteur tu verras que c'est loin d'etre un con. L'erreur est humaine. De plus quelqu'un avait lu son patch puisque le commit d'apres est juste un s/0/NULL donc il n'avait pas vu le probleme non plus. Phk etait aussi passe sur le fichier 20 jours apres.... D'ailleur donne moi ton code je suis sur qu'en cherchant je trouve des choses sympas !

        • [^] # Re: Compétences des Kernels Hackers.

          Posté par  . Évalué à 3.

          > Nombre de fois, ou je lis du code de devel qui ne check pas les accès ressources, c'est un peu reloud, et pourtant, ça se dit grand devel.

          Des pointeurs sur le code incriminé ? Autrement c'est une affirmation gratuite

          > des bugs énormes commencent à être trouvé dans le code.

          Les bugs ne sont pas si enormes que ca puisque c'est toujours le meme mec d'isec qui les trouve... Donc soit y'a que lui qui lit le code soit....

          > que les logiciels libres ne sont pas si sécurisé et si stable qu'il l'était avant

          Naaaaaan les defenseurs du LL decouvrent que le code n'est pas vierge de tout bug, n'est pas secure de la mort (regardez le nombre d'adviso apache :-) et qu'il ne faut pas vendre ce qui n'existe pas. Les systemes libres tout comme l'informatique se complexifient a une vitesse folle. La ou on pouvait coder tout seul dans son garage et tout maitriser il y a quelques annees on en arrive a de gros projet impliquant des milliers/millions de lignes de code avec des dependances dans tout les sens.

          Et le LL ne favorise pas du tout une bonne conception des applis, vu que les mediums pour en discuter ne sont pas reellement adaptes (rien de pire qu'irc !).

          > Si il est beau, bien conçu, il ne sera jamais oublié.

          Un logiciel qui fait son boulot n'est pas oublie, autrement il disparait rien de plus rien de moins.

  • # Attention à ne pas confondre.

    Posté par  . Évalué à 6.

    De la même facon que certain confondent linux et les applications associé (KDE n'est pas linux pax exemple), certain confondre le noyau Linux et les modules du noyau.

    On peut se se faire trés peur comme ca.

    Effectivement, si je regarde les sources du noyau linux + les sources de tout ses modules, ca fait des millions (milliers? centaine de millier ?) de lignes de code.

    Ca à de quoi effrayer et on peu se dire que ce n'est plus maintenable.

    Heureusement, c'est largement moins pire qu'il n'y parrait.

    Les souces du kernel seul de linux sont netement plus réduite que les sources des modules.

    Ces sources la sont elle même composé en parties et sous partieindépendant et relié entre elles par les interfaces, et donc, on peu corriger partie par partie.

    pour s'en rendre compte il faut regarder la carte du kernel:

    http://lug.oregonstate.edu/projects/kernelmap/map.php(...)

    C'est justement la toute la beauté de la chose.

    La plus par du temps les bugs apparaissent sur des modules (au dessus du noyaux). Il est donc trés facile de changer ou de corriger.

    Exemple (foireux mais explicite):

    le gestionnaire de filesystem ext12 est buggué, et bien je prend le gestionnaire de fichier fs42. le mainteneur à corrigé ext12, je reviens sous ext12 (ca demande des copie et recopie mais c'est pas la mort).

    Sous un autre os (windows pour ne citer que lui), si ntfs à un bug, et bien, vous pouvez tjs repasser en fat32 :). etc ...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.