Un nouveau root exploit est apparu mardi et concerne les noyaux Linux de 2.6.38 à 3.8.8 ayant CONFIG_PERF_EVENTS activé.
Tapez la commande suivante pour savoir si vous êtes impacté :zgrep CONFIG_PERF_EVENTS /proc/config.gz
Si zgrep répond cette ligne, vous êtes impacté.CONFIG_PERF_EVENTS=y
Le patch existe depuis plusieurs semaines mais n'a pas été forcement intégré dans toutes les distributions - cherchez le code CVE-2013-2094 dans les derniers security advisory.
La Debian Wheezy a été patchée ce matin (je mets le lien vers le mail de la liste de diffusion « security » car je ne trouve pas l'annonce de sécurité debian sur le site).
Pour ceux qui ne peuvent pas patcher immédiatement leur noyau, il faut suivre le lien vers l'outil de suivi de bug de redhat qui propose plusieurs solutions temporaires plus ou moins efficaces.
Aller plus loin
- Critical Linux vulnerability imperils users, even after “silent” fix (1051 clics)
- [DSA 2669-1] linux security update (531 clics)
- Solutions de mitigation du probleme (746 clics)
# /boot/config-* ?
Posté par rpnpif . Évalué à 7.
Ne serait-ce pas plutôt
Au moins pour Debian.
[^] # Re: /boot/config-* ?
Posté par rpnpif . Évalué à -2.
L'annonce de Debian avec le correctif est datée du 15 avec 17 autres alertes sur le noyau. Relativement banal pour un système très vigilant sur la sécurité ?
Je ne sais pas pourquoi la old-stable n'est pas corrigée en même temps. Ce n'est pas habituel.
[^] # Re: /boot/config-* ?
Posté par kessavdir (site web personnel) . Évalué à 6.
Parce que c'est un noyau 2.6.32 (donc pas impacté) par défaut sur debian squeeze…
[^] # Re: /boot/config-* ?
Posté par rpnpif . Évalué à 0.
Si par les backports qui sont aujourd'hui en 3.2+46 comme Wheezy, mais je n'avais pas vu qu'ils avaient été corrigés, désolé.
[^] # Re: /boot/config-* ?
Posté par pipo_molo . Évalué à -1.
http://lxr.linux.no/linux+v3.9.2/kernel/configs.c
[^] # Re: /boot/config-* ?
Posté par Batchyx . Évalué à 6.
L'option
CONFIG_IKCONFIG_PROCn'est pas activée sous Debian. donc pas de/proc/config.gz.# HAHA
Posté par ariasuni . Évalué à -10.
Mon serveur sous Arch Linux est sous Linux 3.9 depuis au moins une semaine.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: HAHA
Posté par patrick_g (site web personnel) . Évalué à 10.
Stop aux "Ha Ha" : Le mec qui a écrit l'exploit connaissait le bug depuis au moins deux ans.
[^] # Re: HAHA
Posté par hitmanu . Évalué à 5.
C'est ce que je trouve de navrant, il aurait pus le signaler pour faire corriger le bug.
Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.
[^] # Re: HAHA
Posté par patrick_g (site web personnel) . Évalué à 10.
Visiblement le mec est un black hat qui vend ses trouvailles à qui veut bien les acheter.
Il ne dévoile la faille en ouvrant un CVE et en publiant un exploit que lorsque le trou est corrigé sur un dépôt Git.
Voir le mail ce petit salopard ici : http://article.gmane.org/gmane.comp.security.oss.general/10189
[^] # Re: HAHA
Posté par Aris Adamantiadis (site web personnel) . Évalué à 6.
Je pense qu'on est en train de détourner la responsabilité de ce mini scandale. Le "salopard" en question ne fait que suivre ce qui est standard dans l'industrie de la sécurité, c'est à dire découvrir des bugs, coder l'exploit pour soi et attendre que ça tombe ailleurs. (Je connais personnellement des dizaines de personnes qui le font, moi y compris)
Par contre personne ici pour critiquer les deux raisons principales de la publicité de cet exploit:
1- il y a eu un bug qui permet d'obtenir un local root dans un premier temps
2- Lorsqu'un développeur a trouvé le bug (une écriture en dehors du buffer !!) ils ont corrigé le bug sans même créer un CVE, sans mettre le fix en quarantaine ni suivre la moindre procédure de backporting du patch. Ces personnes sont les véritables irresponsables, car un bug de sécurité a été publié dans la nature sans que le patch ne soit prêt à être déployé.
Rapporter la responsabilité de l'absence de CVE et publication de l'exploit à sd est de la mauvaise foi. La véritable responsabilité, c'est l'attitude totalement autruchienne de l'équipe de dev de linux par rapport aux bugs de sécurité. Et je suis convaincu que ce n'est pas le premier bug de sécurité publié ouvertement dans le git sans qu'il y ait le moindre CVE et backporté dans aucune distribution majeure.
[^] # Re: HAHA
Posté par Zenitram (site web personnel) . Évalué à 8.
Ce genre de personne que tu décris est bien un salopard, pas besoin de mettre des guillemets.
Et non, ce n'est pas standard dans l'industrie de la sécurité, il y en a pas mal qui découvrent des bugs, codent l'exploit pour démontrer aux autres qu'il y a un réel problème, démonstration soit privée (responsible disclosure, la personne attend le patch puis se fais la pub, si ça tarde trop hop en public pour forcer le patch), soit en public lors des meeting de sécurité, et parfois empochent quelques milliers de $ en remerciement, soit un bon gros plaisir sadique de faire du 0-day (irresponsible disclosure).
Le développeur ne savait peut-être pas que ça posait un problème utilisable de sécurité. Si il faut faire un CVE pour chaque patch…
C'est à ma connaissance la politique de Linus depuis le début, ton irresponsable a quand même un CV en béton.
Libre à toi de critiquer cette façon de faire, libre à eux de considérer que l'industrie s’accommode très bien de cette façon de faire et de t'envoyer chier. Il te reste à démontrer que ta façon de faire est viable et meilleure. Eux démontrent, pas toi.
Tant que ce n'est pas exploité, ça ne pose aucun problème. Sans compter que la plupart du temps, c'est non exploitable.
[^] # Re: HAHA
Posté par Aris Adamantiadis (site web personnel) . Évalué à 8.
Désolé de te contredire, le standard dans l'industrie c'est de garder les résultats de recherches privés. sd n'a rien fait de mal en gardant pour lui ses résultats. Il n'a rien publié avant que ce soit connu, il ne s'est même pas plaint que ce soit devenu public. Il n'a rien fait d'irresponsable.
Au contraire, les devs qui ont publié les patches sans faire de review de sécurité sur le bug qu'ils avaient trouvé ont publié un bug de sécurité selon ta vision de l'irresponsible disclosure.
C'est un problème de processus. Sur les gros projets (et les petits aussi), chaque bug qui est trouvé et dont on soupçonne des répercussions au niveau de la sécurité doit être analysé par une équipe compétente. Mon petit projet y arrive, pourquoi linux n'y arrive pas ? Parce qu'il n'y a pas d'équipe de sécurité.
Donc d'après toi, puisque monsieur Linus a un meilleur pédigrée que moi, il a toujours raison. Ton argument d'autorité, tu peux le garder. Et bien non, en terme de sécurité, la vision de Linus (Un bug de sécurité = un bug) est totalement irresponsable. Il se moque totalement de l'impact des bugs de linux au niveau de la sécurité et compte sur les autres pour tenter de regarder le backlog et trouver ce qui est urgent à backporter et ce qui ne l'est pas. Linus le dit lui même, la sécurité de Linux c'est pas son problème. Je refuse de prendre des conseils en sécurité de cette personne.
Et ce n'est pas juste moi qui le dit, mais Spender (le mec de grsecurity qui s'y connait "un peu" en sécurité linux) [1] premier hit sur "spender linus security"
Ce type d'excuse est irresponsable. Tu crois que parce qu'un problème est caché sous le paillasson, il n'existe pas ? Il y a des gens qui passent leur temps à inspecter les commits linux à la recherche de bugs exploitables et crois-moi, ils ne réagissent pas comme sd lorsqu'ils trouvent quelque chose. Tant que ce travail ne sera pas fait de manière systématique par l'équipe sécurité de Linux, on aura ce genre de problèmes de manière récurrente.
[1] http://www.reddit.com/r/netsec/comments/18qab0/spender_grsecurity_author_linux_approach_to/ https://lwn.net/Articles/538600/
[^] # Re: HAHA
Posté par Renault (site web personnel) . Évalué à 10.
Garder secret ce type de chose pour un bénéfice personnel et malsain c'est selon moi irresponsable. Même si c'est un standard ou pas sa procédure, cela n’enlève pas qu'il aurait pu le publier pour que tout le monde s'en sorte grandi…
[^] # Re: HAHA
Posté par Zenitram (site web personnel) . Évalué à 3.
Tu arrives à rester sérieux en écrivant ça?
Bon, il sait que ça va exploser un jour, il a de quoi empécher l'explosion, mais il laisse exploser, c'est responsable de ton point de vue, le mec est un salopard du mien.
Relit, je ne parles pas d'autorité, rien à faire de l'autorité.
Je dis simplement que les autres ont l'air de très bien vivre avec ça, et que personne n'arrive à proposer "mieux".
Je ne parle pas d'autorité, je dis juste que ça marche. Ensuite, libre (c'est beau le libre) à d'autres de te proposer une review de sécurité si ça vaut le coup.
Tu es au courant qu'il y a un très faible nombre de gens qui utilisent grsecurity? Il faut croire que la vision de Spender n'attire pas plus foule que ça.
L'avantage du libre, c'est que tu peux, toi, proposer ta vision sans problèmes. Faut juste que les autres suivent. grsecurity est un très bon exemple, ses patchs sont jugés foireux, rejetés de la branche principale, et il est bloqué à Linux 3.4.4, ça manque un peu de réactivité…
Libre à toi d'avoir une autre politique de sécurité, chacun sa liberté et sa politique de sécurité (vive le libre), mais désolé, je n'accepte pas qu'on balance que ce comportement de salopard (pour reprend ton mot qui a bien sans les guillemets) est ce qu'on peut appeler, même de loin, responsable. c'est au mieux du je m'en foutiste, mais ici ce n'est pas le cas puisque la personne a codé une démo pour se faire mousser, donc la c'est l’irresponsabilité complète et/ou le plaisir de nuire.
[^] # Re: HAHA
Posté par Aris Adamantiadis (site web personnel) . Évalué à 2.
Se boucher les oreilles et crier lalalala n'est pas un argument valide. La politique de sécurité de linux est puante et ce n'est pas parce que l'équipe de dev de linux se complait dans leur médiocrité que c'est comme ça que ça doit fonctionner.
[^] # Re: HAHA
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 19 mai 2013 à 11:30.
Tu parles de toi?
Ce n'est pas parce qu'elle ne te plait pas qu'elle est puante. C'est un choix. Qui a l'air de plaire.
Je t'en prie, propose mieux. En vrai, hein, pas en lalalala, pour démontrer qu'il est possible de mieux faire (en plus, tu dis toi-même que les "méchants" scannent les logs GIT, donc ça doit être aussi possible pour les "gentils").
Perso, je constate juste que Linux est sur tous les serveurs ou presque non pas parce que les commerciaux sont doués, mais parce qu'il répond au besoin technique (sécurité comprise, faut voir comparé à d'autres OS).
Je reprend ce bout de phrase, mais l'utilise pour ton "(Je connais personnellement des dizaines de personnes qui le font, moi y compris)".
[^] # Re: HAHA
Posté par Aris Adamantiadis (site web personnel) . Évalué à 3.
Le choix ne plait pas, cfr propos de spender (à sortir du contexte grsecurity, son framework ne plait pas forcément pour des raisons techniques.)
J'ai expliqué mon point de vue sur les choses à améliorer, suffit de lire. Avoir une vraie team sécurité, des vrais reviews de patches, ne pas considérer la sécurité comme un truc chiant qui ne concerne que les autres.
Linux est sur beaucoup de serveurs, y compris les miens, parce qu'il y a beaucoup de fonctionnalités dedans et que ça marche pas mal. Mais j'aimerais bien avoir un OS dont j'ai la garantie que tous les bugs de sécurité qui ont été trouvés dans le passés soient patchés sur mon système. Je n'ai pas encore cette garantie aujourd'hui.
Je vais ignorer cette basse attaque ad hominem.
[^] # Re: HAHA
Posté par Misc (site web personnel) . Évalué à 10.
C'est une question de ressources. Soit tu prends un noyau ou les gens auditent tout pour la sécurité, mais ça avance pas aussi vite que tu voudrais, voir ça vire des options que tu voudrais ( exemple, la virtualisation que l'équipe openbsd considère comme mauvaise pour la sécurité, donc ne veut pas intégré ça ). Soit tu prends un truc qui avance et ou le prix du progrès, c'est d'avoir parfois des failles.
Sinon, si tu veux une vraie équipe sécurité, y a des boites qui font leur propre OS qui paye des gens pour ça. Exemple, Apple, Microsoft, SunW Oracle mais bien sur, tu doit payer. Y a des boites qui payent aussi des équipes sécu pour le logiciel libre, genre Red Hat, Suse, Canonical, mais pareil, les revues de sécurité, ça tombe pas du ciel.
Dernière possibilité, commence à faire des revues de code en même temps que tout le reste de la lkml, lead by example, etc, etc.
Poster sur Linuxfr sans rien faire, ça va juste rien faire.
[^] # Re: HAHA
Posté par claudex . Évalué à 7.
Si jamais tu en trouve un, ce serait une sacré découverte (et on parle bien de tous les bugs de sécurité, pas uniquement des bugs taggé comme tel).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: HAHA
Posté par Athel . Évalué à 1.
Source ?
Source ?
Faux, Brad Spengler n'a aucune volonté de pousser grsecurity dans la branche principale.
Encore faux, les patch sont disponibles jusqu'à la version 3.9.2
Des fois il faut se renseigner un peu avant de parler…
[^] # Re: HAHA
Posté par Zenitram (site web personnel) . Évalué à 1.
Flemme de chercher pour le reste, concentrons-nous la dessus :
Effectivement, je me suis trompé, j'ai été trop gentil, c'est que 3.2 (j'avoue avoir mal lu wikipedia trop vite, mauvaise ligne qui est vieille)
Tu fais de la sécurité avec des versions de tests non jugées stables par les développeurs?
[^] # Re: HAHA
Posté par Athel . Évalué à 3.
Brad choisit uniquement certaines version LTS de Linux en tant que branche stable. Cela explique que sa branche stable soit "Bloquée" en 3.2.
Tu fais de la sécurité avec des noyaux qui n'ont pas du support à long terme ?
Je ne comprends pas ton propos, tu parles de manque de réactivité, on te montre que si c'est réactif, et du coup tu critiques le fait que cela ne soit pas stable ?
[^] # Re: HAHA
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 20 mai 2013 à 15:28.
Je ne comprends pas ton propos, tu mélanges réactivité et stabilité.
Du réactif non stable n'est pas du réactif.
Tu confirmes bien donc ce que je disais: tu utilises (ou parle d'utiliser) du test pour de la production.
Non, me démontrer ça serait que grsecurity soit en stable avec la 3.9, ce qu'il n'est pas.
Pire, à revoir kernel.org, la dernière longterm (ne rigolons pas, ne parlons pas de dernière stable) est la 3.4, pas en stable pour grsecurity, oups… Tu parles d'une réactivité! tu le dis toi-même "certaines LTS de Linux", du coup quand elle n'est pas choisie, ben réactivité à la ramasse.
[^] # Re: HAHA
Posté par Athel . Évalué à 1.
Pour être précis dans le choix des stables, ce sont les LTS choisies par les distributions :
- 2.6.32 : Debian Squeeze et RHEL 6
- 3.2 : Debian Wheezy
Non, je parles d'utiliser pour de la production des versions qui ont du LTS, c'est toi qui n'a pas répondu à ma question, tu utilises des versions non LTS pour de la production ?
[^] # Re: HAHA
Posté par patrick_g (site web personnel) . Évalué à 3.
http://article.gmane.org/gmane.linux.kernel/774824
[^] # Re: HAHA
Posté par Athel . Évalué à 2.
Au temps pour moi, j'avais compris foireux au sens, les fonctionnalités apportées sont foireuses. Si l'on parle de patch foireux au sens non intégrable parce que tros gros, en effet.
L'auteur de Grsecurity n'a aucune intention de pousser ses développement mainstream. Il ne fait donc aucun effort pour présenter son code pour qu'il soit intégré. Attention, je ne veux pas dire par la qu'il fait du mauvais code, mais il n'y a aucune découpe des différents patch par fonctionnalité, ce qui permettrai une meilleure intégration.
[^] # Re: HAHA
Posté par Batchyx . Évalué à 4.
Linus n'a jamais dit que ces patches étaient foireux, juste qu'ils sont bien trop spécifiques et trop chiants pour être upstream.
Franchement, on peut faire les mêmes critiques à tout les patches que les gens écrivent pour un besoin particulier sans considération pour être intégrés upstream. C'est le cas à chaque fois que des développeurs utilisent le noyau Linux pour faire autre chose qu'un noyau généraliste.
[^] # Re: HAHA
Posté par Kerro . Évalué à 9.
Il va falloir que tu m'expliques en parlant lentement : pour quelle raison sans visées illégales cette personne garde secrète ce genre d'info ?
Si c'est un professionnel « propre » de la sécurité, il n'a aucun bénéfice à attendre pour publier. Sinon il risque de se faire doubler, et son CV sera moins bon.
Il faut donc enlever « propre » pour que son attitude soit logique.
Vendre des failles de sécurité, c'est la même chose que vendre le code administrateur d'une centrale d'alarme, ou d'une ouverture de porte automobile. Le but est uniquement illégal.
[^] # Re: HAHA
Posté par Aris Adamantiadis (site web personnel) . Évalué à 7.
Ton commentaire touche à un des points assez sensibles en infosec, qui est le grand débat full disclosure/no disclosure. Beaucoup de chercheurs compétents croient au non disclosure et gardent leurs trouvailles pour eux, au risque de se faire doubler comme tu dis. En résumé, leur raisonnement est le suivant:
- Ils ne sont pas payés pour faire la recherche donc n'ont pas d'obligation de publication
- Les bugs de sécurité sont vu comme des trésors heisenbergiens qui disparaissent lors de la publication. Un exploit 0day, même non partagé, est une sorte de trophée qu'ils conservent précieusement.
- Ils n'ont pas besoin de publier pour étoffer leur CV, partant du principe que le CV ne leur intéresse pas ou qu'ils n'ont pas besoin de publier pour être reconnus
- Le point le plus important: la publication de découvertes de sécurité est une pratique dangereuse. Cela ne s'applique sans doute pas à linux, mais publier en son nom propre (même en suivant les pratiques de "responsible disclosure") expose le chercheur à des ripostes légales. Parfois prendre ce risque gratuitement ne vaut pas le coup.
J'ai une opinion différente. Certains hackers considèrent que vendre de l'exploit est non éthique (je pense que sd en fait partie), et préfèrent laisser leur exploit moisir sur le disque dur que le divulguer de cette manière. Quoi qu'il en soit, vendre une faille de sécurité n'est pas similaire à vendre un code d'alarme. C'est vendre la primeur sur un problème de sécurité peut-être connu ailleurs pour laisser une chance aux clients de se protéger à l'avance. Je pense que le raisonnement "vendre des vulnérabilités est forcément illégal" tient du même raisonnement fallacieux que "Si tu utilises de la cryptographie, c'est que tu as des choses illégales à cacher".
Et vu le nombre de vulnérabilités critiques rapportées par ZDI et autres, qui seraient peut-être restées très longtemps non publiées si il n'y avait pas de contrepartie financière, je pense que la monétisation de rapports de vulnérabilité est positif à long terme. Rechercher des vulnérabilités, ça prend du temps et c'est loin d'être gratuit.
[^] # Re: HAHA
Posté par Aris Adamantiadis (site web personnel) . Évalué à 2.
Lien pertinent à mon message plus haut: http://blog.trailofbits.com/2009/03/22/no-more-free-bugs/
[^] # Re: HAHA
Posté par Zenitram (site web personnel) . Évalué à 7.
On parle de responsabilité.
Personne ne parle d'obligation.
Tu trouves responsable l'idée (si on augmente ton principe) de laisser crever des gens alors que tu aurais pu empêcher ça en informant juste la bonne personne, et tu peux dormir tranquille, pas moi. Ils ne sont pas payés pour faire la recherche? Qu'ils ne la fassent pas. Mais si ils trouvent, c'est de leur responsabilité (non légale) d'informer la bonne personne (et si l'upstream s'en fout, tant pis, ils auront fait ta part). Ils n'en n'ont pas l'obligation légale certes, mais cette non obligation n'enlève pas l'idée que ces personnes sont des salopards (sans les guillemets).
Tu as un conscience très sélective.
Tu le dis toi-même : ça ne s'applique pas à Linux. Et ici, on parle de?
informer seulement l'upstream uniquement n'a jamais fait prendre des risques légaux dans ce milieu. Il y a même des confs dédiées à ça! Au pire on t'ignore (genre Microsoft), au mieux on te récompense nominativement et financièrement (hop, pratique tu perds ton argument "risque gratuit") (genre Mozilla et Google).
Les risques sont si tu t'attaques au système d'un autre (accès frauduleux genre si tu t'attaques au GIE carte bancaire, il y en a un qui en a fait les frais), ici tu peux t'attaquer à ton propre système, donc le seul risque et de te prendre un procès de toi-même, risque gérable.
Ne te cache pas devant des excuses fallacieuses pour te donner bonne conscience.
[^] # Re: HAHA
Posté par Aris Adamantiadis (site web personnel) . Évalué à 5.
Pour reprendre tes propres mots:
Nous parlons aussi du comportement de l'équipe de dev de linux, qui pour toi n'ont rien fait d'irresponsable alors qu'ils ont aussi l'obligation "morale" de prévenir lorsqu'un bug qu'ils ont réparé était exploitable, selon tes critères.
Malheureusement il y a un paquet de contre exemples, allant de mecs qui montrent que le DRM d'une solution x est inutile (Dmitry contre Adobe), à des mecs qui montrent qu'il est facile de contourner un antivirus (qui tourne sur ta propre machine). Petite liste disponible ici: http://attrition.org/errata/legal_threats/
[^] # Re: HAHA
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 19 mai 2013 à 12:28.
Tu sais, toi, qu'ils savaient que c'était exploitable? Ils avaient codé une démo? Source?
C'est la "petite" différence qui change tout… Je l'ai écrit déjà ("faire la recherche").
Tu as lu ce que j'ai écrit? La, on parle de DRM, même pas libre, qui est juridiquement protégé (contourner un DRM est illégal, DMCA aux USA, DADVSI en France).
Au passage, tout le monde n'habite pas dans des pays bizarre, et perso je publie depuis des années un crack qui casse des DRM sans être inquiété.
Passer root sur ta machine à toi n'est pas illégal à ma connaissance, où sort moi le texte.
Il y a parfois des risques, oui, je n'ai jamais nié ça (tu donnes un exemple DRM qui ne t'appartient pas, j'en donne un CB) mais certainement pas pour ce dont on discute, ne te cache pas derrière des exemples différents.
[^] # Re: HAHA
Posté par croux . Évalué à 3.
Je sors cette phrase de son contexte car on ne passe pas root sur une machine mais sur un système d'exploitation. Être propriétaire de la machine ne signifie pas avoir les droits sur le ou les systèmes d'exploitations qu'elle fait tourner ; les hébergeurs en savent quelque chose… Il y a bien un risque légal d'intrusion.
My 2 cents.
[^] # Re: HAHA
Posté par khivapia . Évalué à 2.
Il y a parfois des risques, oui, je n'ai jamais nié ça (…) mais certainement pas pour ce dont on discute
En France en tout cas, il est interdit de développer et encore plus de publier des outils permettant de trouver et exploiter des failles de sécurité (art 323-3-1 du code pénal).
Donc le monsieur qui a publié l'exploit est susceptible de poursuites selon la loi française.
Dans d'autres pays (pas forcément des états de droit), ce serait une mise à l'ombre directe par les services spécialisés.
[^] # Re: HAHA
Posté par Zenitram (site web personnel) . Évalué à 2.
http://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI000006418323&cidTexte=LEGITEXT000006070719
"Le fait, sans motif légitime, d'importer, (…)"
On parle de motif illégitime (se faire mousser, revendre, utiliser…), alors eux, franchement, je m'en balance complet de leur condamnation, voire ça me va.
Perso, je parlais d'un non risque lors d'un responsible disclosure, et donc ton article ne s'applique pas.
Condamner les irresponsible disclosure me convient complètement.
[^] # Re: HAHA
Posté par Anonyme . Évalué à 6.
Ils n'ont pas réparé un bug qu'ils savaient exploitable. Ils ont réparé un bug, qui comme des milliers d'autres est peu etre exploitable, ou peu etre pas. Pour le savoir, il faut passer du temps à essaier de l'exploiter.
[^] # Responsabilité
Posté par croux . Évalué à 2.
Si on accorde une responsabilité à celui qui cherche des failles et qui en trouve, ne faut-il pas en accorder autant à ceux qui développent en reléguant la sécurité au second plan ?
On sait que Linus ne fait pas de distinction entre les bugs (puisqu'un bug qui n'est pas identifié comme étant de sécurité peut s'avérer en être un). Partant de là, ceux qui choisissent d'utiliser linux n'acceptent-ils pas tacitement la situation actuelle du noyau en matière de sécurité ? Quel est le niveau de responsabilité de ces utilisateurs ?
[^] # Re: Responsabilité
Posté par Zenitram (site web personnel) . Évalué à 5. Dernière modification le 19 mai 2013 à 12:52.
Un bug est un bug, c'et un choix, on ne sait pas forcément que c'est de sécurité c'est tout, c'est quoi le problème la dessus?
Et je ne vois pas le rapport entre la politique de sécurité de Linux (il y en a une : un bug est un bug) et le fait que quelqu'un ne prévient personne (Si Linus ne veut pas, ok, mais au moins prévenir les distros qui s'interessent à la sécu non?) quand il a une démo, et surtout qu'il balance la démo comme ça quand ça lui chante.
Si il ne cherche pas, je ne l'accuse pas de ne pas chercher.
Si il trouve mais ne dit jamais rien, passe encore.
Si il trouve et balance l'exploit quand la faille est patchée par quelqu'un d'autre qui ne sait pas forcément que c'est un problème de sécurité, désolé de ne pas dégager la personne de son irresponsabilité et/ou intention de nuire.
Pour faire une analogie (en admettant que Linux ai une "politique pourrie"), ce n'est pas parce qu'une porte est ouverte (politique de sécurité pourrie) que ça te légitime d'entrer et tout prendre (utiliser ton hack), ou dire aux autres comment faire ("allez y les gars, cassez tout").
[^] # Re: HAHA
Posté par Kerro . Évalué à 4.
Par définition, un secret jamais partagé ni exploité ne rapporte jamais rien.
Vu que c'est issu de son travail, qu'il passe probablement des centaines d'heures à trouver ce genre de truc, alors il exploite ce secret (ou alors il a les fils qui se touchent). Il exploite par lui-même ou en vendant la solution. L'objectif final est forcément de pénétrer des systèmes. Donc des choses illégales, mais surtout vaguement détestables.
Je suis peut-être à côté de la plaque, mais je n'ai vu nulle part dans les arguments ici quelque chose qui tienne la route. À part concernant des activités illégales. Et dans ce cas je comprends bien que le mec ne s'en vente pas.
[^] # Re: HAHA
Posté par croux . Évalué à 2.
Un informaticien qui divulgue de telles découvertes longtemps après, ne tombe pas nécessairement dans l'illégalité. Son travail peut servir à des activités parfaitement licites. Par exemple dans le cadre des tests d'intrusion, pratiqués par certaines sociétés spécialisées en sécurité informatique, la possession possession d'un tel "outil" peut devenir un avantage commercial.
Le fait qu'il ait publié son exploit m'incite à penser qu'il est surtout en quête de reconnaissance plus qu'autre chose.
[^] # Re: HAHA
Posté par Misc (site web personnel) . Évalué à 3.
Je ne suis plus un professionnel du domaine, mais j'ai pris une douche, donc je m'estime un minimum propre. Parfois, si tu as une faille, tu agrdes parce que tu as pas le temps de t'en occuper. Moi, j'ai trouvé des trucs mineurs en faisant de la lecture de code, j'ai fait un rapport de bug par mail, j'attends le correctif. Depuis janvier.
Ensuite, c'est dans l'absolu, si j'avais un truc de ce genre, oui, je tenterais de faire corriger ça assez vite. Et pour ça, c'est simple, au moins pour le logiciel libre. Y a assez de gens sur la liste oss-security pour t'aider à coordonner une release du patch avec un embargo pour que ça soit fait le plus proprement sans faire trop de dégâts.
Dans le cas de spencer, chaque fois que je lit ce qu'il écrit, il est souvent agressif et/ou hautain et rarement coopératif. Et c'est en voyant ce genre de mec ( car c'est pas le seul dans le milieu ) que j'ai compris que le monde de la sécurité est mauvais pour l'équilibre psychologique des gens ( et donc que j'ai pas cherché à re bosser dans le domaine à nouveau, si c'est pour trainer avec des mecs dans son genre ( et c'est pas le seul, je précise ), je préfère devenir admin windows au tadjikistan )
Et c'est aussi en le lisant que j'ai pigé que le patch grsecurity serait sans doute jamais mergé upstream, donc jamais à l'abri d'un coup de tête du dev principal, donc à éviter pour ma part.
[^] # Re: HAHA
Posté par Antoine . Évalué à 8.
Mouais. Ou bien plutôt : parce que ton petit projet est petit. C'est largement plus facile de maîtriser la sécurité d'un petit projet, avec une communauté de développeurs et d'utilisateurs restreinte (et donc une grande facilité à imposer des pratiques homogènes), que sur un des plus gros projets au monde.
S'y connaître techniquement en sécurité, cela ne fait pas de lui une autorité en matière de méthode de développement. Chacun croit son activité plus importante que les autres : les fous de performances vont mépriser n'importe quel programme leur apparaissant comme "bloated", par exemple. Les férus de sécurité essaient en permanence d'imposer un agenda où la résolution des problèmes de sécu prime sur tout le reste (y compris, par exemple, la compatibilité avec l'existant). Discuter avec ce genre de types peut être extrêmement pénible, et peu productif.
[^] # Re: HAHA
Posté par patrick_g (site web personnel) . Évalué à 10.
Ce serait pas mal quand même de prendre le temps de lire et de comprendre ses arguments au lieu de pontifier doctement comme tu le fais.
Je t'invite à (re)lire les questions relatives à la sécurité dans son interview qui avait été postée sur LinuxFR : https://linuxfr.org/news/linus-torvalds-l%E2%80%99interview-anniversaire-des-20%C2%A0ans-du-noyau
Tu fais un Ctrl+F "GRSecurity" et tu lis les trois questions qui suivent.
Tu notera d'ailleurs que ça se termine par une phrase que je t'invite à méditer: "Do security people always agree with me? Hell no. But they don't agree amongst themselves either, so what does that prove?"
[^] # Re: HAHA
Posté par Aris Adamantiadis (site web personnel) . Évalué à 1.
Ce que j'en pense:
http://securityreactions.tumblr.com/post/52299339625/linux-kernel-devs-reaction-to-complaints-about-silent
[^] # Re: HAHA
Posté par Tharkun2 (site web personnel) . Évalué à 3.
Ce genre de personne que tu décris est bien un salopard, pas besoin de mettre des guillemets.
Et non, ce n'est pas standard dans l'industrie de la sécurité
Laisse moi deviner : tu ne bosses pas dans l'industrie de la sécurité, et tu ne connais pas grand monde qui y bossent. Je me trompe ?
Parce que le gars que tu qualifies de salopard, c'est peut-être juste un gars qui fait son boulot. Et le comportement décris EST standard, même si ça peut en gêner certains.
Toutes les boites de sécu que je connais qui pratique des tests d'intrusions connaissent des failles 0-days, et ne les divulguent pas. Tout simplement parce que lors d'un audit, disposer d'un moyen "innovant" pour pénétrer un système, c'est un avantage concurrentiel, et un gros gain de temps.
[^] # Re: HAHA
Posté par Misc (site web personnel) . Évalué à 10.
ça résume bien ce qui va pas dans le monde de la sécurité. Y a plein de pognon à se faire car le processus de décision contourne la rationalité. Le secret autour des affaires fait que les légendes urbaines et les exagérations sont légions ( suffit de voir les histoires de cyberwars ). Le cinéma fait tout pour faire rêver et faire croire que la sécurité et les ordinateurs, c'est magique et/ou compliqué et/ou tout troué. On vends aux gens de la peur basé sur justement de l'imaginaire, donc ça parle directement à un niveau moins rationnel de l'esprit.
Comme le dit Linus dans une interview cité plus haut, et comme j'ai pu le constater souvent en bossant dans le domaine et en lisant les MLs de projets, certains gens dans la sécurité sont très manichéen avec une vision tunnelisé.
Et comme il y a d'énormes ressources en jeu ( lire pognon ), il y a plein de monde et du coup, le monde de la sécurité est plus dans l'opposition et la compétition que dans la coopération, coopération qui est au coeur du logiciel libre et qui explique le clash des cultures. Et pas opposition juste quand il y a de l'argent, ce qui à la rigueur serait normal. Non opposition du style "je passe des jours à montrer qu'un bug est une faille et en plus,je passe le double du temps à contourner les systèmes de sécurité des autres pour faire une petite pique pour montrer qu'ils servent à rien".
Opposition car les "leaders" du monde de la sécurité sont souvent dans un des 2 extrêmes entre "paranoiaque et très discret", ie, on ne lit pas d'interview d'eux, voir connait pas leur vrai nom ( SolarDesigner, par exemple, même si maintenant, on connait son vrai nom ), et "grande gueule et porté sur l'obsession de la sécurité, voir l'exagération". Donc à partir de la, les grandes gueules gagnent la bataille médiatique, donc on a tendance à suivre leurs exemples. Suivre pour la vision tunnelisé, suivre dans l’exagération, voir promouvoir des gens comme expert alors qu'ils ont plus d'une fois parlé de casser AES.
Ensuite, je connais plein de gens qui ont une approche plus balancé de la sécurité, je ne nie pas leur existence. Mais eux, on ne les entends pas, ils ont pas une horde de gens prêt à reprendre leurs idées non extrémistes sur le web, donc on prends pas en compte leur point de vue.
Et enfin, la question qui se pose, c'est de savoir si c'est le milieu qui transforme les gens, ou si c'est les gens qui transforme le milieu. Et si au final, c'est une bonne chose de voir qu'en France, on a 4 conférences de sécurité international durant ce trimestre. Ou plus audacieux, est ce que la monté du front national en France et la monté de la sécurité informatique ne sont pas liés ( liés dans le sens ou "se méfier des autres" devient une idée de société prédominante )
[^] # Re: HAHA
Posté par Zenitram (site web personnel) . Évalué à 1.
Mélange un peu rapide… On peut aussi voir que la sécurité va de pair avec la démocratisation de l'informatique, avec des choses intéressantes à récupérer à nos jours (compte bancaire, secret industriel… Et ce en masse).
Et les gens veulent se protéger du vol depuis bien avant l’existence du FN et de l'informatique.
Et ce que la démocratisation de l'informatique et la montée de la sécurité informatique ne sont pas liées?
[^] # Re: HAHA
Posté par Misc (site web personnel) . Évalué à 5.
Ben justement, c'est la question. Bien sur que c'est rapide, c'est un commentaire sur linuxfr, pas guerre et paix ( même si j'ai déjà écrit des romans en commentaire ). On peut en discuter pendant des heures, comme déjà savoir si il y a une montée ou pas.
Mais par exemple, on peut comparer avec d'autres pays de taille comparable. Est ce qu'il y a autant de choses autour de la sécurité en espagne, en allemagne ? L'allemagne a toujours eu le CCC, mais c'est pas le même public visé que Hackito Ergo Sum ou d'autres comme le SSTTIC.
Est ce que la présence du minitel ( et donc la monétisation des services qui va avec ), le fait d'avoir des accès au net pas cher ( ou plutot moins cher qu'ailleurs ) est aussi une cause de la démocratisation de l'internet, donc de la montée de la sécurité informatique en France ? Peut être.
Il est généralement reconnu que ça a fait un bond après les attentats du 11 septembre, parce que l'état américain a financé plein de projets et donc a lancé la machine économique ( et j'aurais tendance à le croire aussi ). Ensuite, une fois les deniers publiques épuisés, la technologie s'est retrouvé dans le civil, vu que la croissance du point de vue des militaire et de l'état était soit bouché, soit illégal ( ie, dictature, etc, ce qui n'a pas empêché ).
Mais ensuite, la politique sécuritaire du gouvernement sarkozy, peut être lié aussi aux retombées en occident du 11/09 n'ont pas aidé à instauré cette montée ? La loi HADOPI, le concept d'"internet civilisé", etc, tout ça, c'est aussi des choses qui ont instauré l'idée que l'internet est une source de danger et de non droit.
Et mon point, c'est pas qu'il n'y avait pas de sécurité avant, mais qu'il y a en a beaucoup plus maintenant. C'est pas une croissance faible ou un niveau constant, c'est une croissance des plus fortes. ( encore une fois, on passe de 1 conf franchouillarde par an à 4 ce trimestre ). Et ces conférences sont organisés par des personnes locales. Les gens du milieux se plaignent que le STICC est noyauté par l'ANSII et les grosses boites, mais c'est aussi parce que ces groupes ont grossis. Thales, EADS, etc, y a quoi comme équivalent à l'étranger, et est ce qu'il y a une corrélation entre la présence de grand groupe du même genre et d'un milieu de la sécurité vivace ?
Peut être qu'il y a une monté de la visibilité des crimes qui irait avec une monté de l'information disponible. Peut être qu'il y a une montée parce que les barrières à l'entrée sont plus basses, que les risques sont moindres, c'est sans doute aussi une explication. peut être qu'il y a juste une montée de la visibilité de la sécurité informatique, je sais pas.
Il y a sans doute plus d'une raison, et je ne dit pas que ma proposition est la seule cause, loin de la. La question est de savoir si c'est une cause ou pas. Ou une conséquence. Ou un hasard. Après tout, l'extrémisme politique arrive ailleurs, et pour d'autres raisons. Mais par exemple, ailleurs en europe, je ne croit pas qu'on retrouve les mêmes choses qu'en France ( ie, climat poussant à ne pas croire l'internet, tout en ayant favorisé la montée de l'internet dans les années avant via la mise en place d'infrastructure, et via des initiatives privés ( free par exemple )). Par exemple, je pense que la France est très avance sur le libre ( dans le sens ou on a beaucoup de contributeurs francais ) parce que la DST a coupé une montée des "hackers" dans les années 80, ce qui fait qu'une génération de gens se sont retrouvés à faire du libre au lieu de faire des mouvements comme le CCC comme en Allemagne. Et peut être que cette montée des libristes a permis l'arrivé de FDN, de Free, et une certaine compréhension du fonctionnement du réseau, qui a permis d'avoir plus de libristes, plus d'internet, et à la fin, plus de gens dans le milieu de la sécurité.
[^] # Re: HAHA
Posté par Antoine . Évalué à 4.
Pourtant il y a aussi énormément de contributeurs allemands, peut-être plus que de français.
[^] # Re: HAHA
Posté par mazarini . Évalué à 4.
2 ans pour écrire l'exploit, ca devait être très complexe.
---->[]
[^] # Re: HAHA
Posté par ariasuni . Évalué à 2.
Humour toussa… Vu le titre je pensais que ça serais évident. Et le fait que mon serveur soit sous Arch Linux contrairement à 99,99% des serveurs sous GNU/Linux.
Eh bien ça mérite d'être ajouté à la dépêche, parce que ça touche de vieux noyaux mais ça veut pas dire qu'elle était connue/utilisée.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: HAHA
Posté par fravashyo (site web personnel) . Évalué à 10.
C'est très intéressant un serveur que tu dois redémarrer toutes les 2 semaines pour une mise à jour du noyau…
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: HAHA
Posté par stopspam . Évalué à 3.
Ce genre d'actu remet régulièrement en cause le choix du mode de distribution : rolling release ou par version longue…
J'imagine les ressources nécessaires qu'il faut avoir pour de suivre les bugs, trous de sécu et les patcher sur une ancienne version. Mais quand l'upstream ne communique même pas alors ce travail ne sert tout simplement à rien !
Autant prendre la dernière version.
[^] # Re: HAHA
Posté par Maclag . Évalué à 5.
En suivant cette logique jusqu'au bout, tu devrais même prendre un nightly build et redémarrer une fois par jour: on ne sait jamais, la correction a peut-être eu lieu dans une branche expérimentale sans que le correcteur réalise que c'est une faille de sécurité exploitable.
Sérieusement, la question ici, c'est fréquence du redémarrage contre sécurité.
La "faille" non du noyau, mais du système, c'est que le trou de sécurité n'a pas été rapporté en tant que tel, mais en tant que bug. Et apparemment, c'est souvent le cas.
Alors, moi je ne suis pas développeur ni admin sys, mais j'aurais envie de poser la question: est-ce qu'il ne vaut pas mieux rapporter en tant que faille de sécurité tout bug que le développeur pense être exploitable comme faille?
C'est sûr, vu ce qu'explique le dév, ça risque d'augmenter le volume de la liste sécu, mais cette liste ne devrait pas être limitée par autre chose que les considérations purement technique, non? S'il faut vraiment faire des mises à jour plus fréquentes, alors c'est du ressort de l'admin sys que de décider de ces fréquences, par le dév noyau qui ne rapporte pas parce que c'est pas officiellement connu et exploité.
Mais j'ai peut-être mal compris le fil?
[^] # et quid de Ksplice ?
Posté par Kioob (site web personnel) . Évalué à 3.
Le module Ksplice permet de faire les mises à jour de kernel à chaud, sans devoir rebooter. J'adorerais voir ce module intégré nativement dans la plupart des distributions, ce qui résoudrait en partie la problématique de la fréquence de mise à jour du noyau.
Mais je suppose qu'il s'agit d'un problème de Licence, bien que Wikipedia indique que le module est libre.
alf.life
[^] # Re: et quid de Ksplice ?
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 18 mai 2013 à 17:15.
Ce n'est plus le cas depuis qu'Oracle a pris le contrôle de la chose (merci Oracle…).
Perso, ce qui m'étonne est que personne (à ma connaissance) n'a forké la chose (c'était vraiment lire avant?), je me dis que j'en ai clairement pas l'utilité mais qu'il doit bien y avoir du monde qui aime la haute dispo.
[^] # Re: et quid de Ksplice ?
Posté par manawy (site web personnel) . Évalué à 2.
De ce que je comprends de la définition de la haute disponibilité, même une panne matériel grave ne doit pas impacter les services.
Par conséquent, ce n'est pas rebooter qui doit empêcher le service.
Je ne vois pas trop comment ça peut marcher ce truc… Car quand je vois les problèmes, pour reloader dynamiquement un simple module python, je me dis que quand il s'agit du noyau, il est plus prudent de rebooter. Surtout si il s'agit d'update de sécurité, non ?
[^] # Re: et quid de Ksplice ?
Posté par Zenitram (site web personnel) . Évalué à 1.
Ce que j'en comprend, c'est que si tout est redondé, mais que pendant 2 minutes tu rebootes, ben tu as volontairement cassé ta redondance et donc tu es en période de danger. Donc toute suppression d'indispo est bonne à prendre, même tout redondé (justement car tu enlèves ta redondance lors du reboot).
Après, est-ce que ça vaut le coup de risquer une merde complexe avec ksplice ou tripler le matos… Question à laquelle je ne peux répondre (perso, je vois le matos comme pas cher de nos jours, je voterai pour tripler le matos plutôt, mais c'est 100% subjectif et certain matos est très cher).
Troll: après, tu parles d'un langage de prototypage… ;-)
Ca change les adresses pour les nouveaux appels, c'est vraiment pas idiot. Mais c'est pas trivial, donc pas fait par tous (genre Python que tu as cité : c'est peut-être pas leur priorité)
[^] # Re: et quid de Ksplice ?
Posté par groumly . Évalué à 2.
Ceux qui aiment la haute dispo ont probablement un pool de serveurs derriere un load balancer et rebootent les machines une a une, donc ils voient pas trop la difference.
Sans compter qu'il reste toujours des mises a jour soft qui sont plus simple a appliquer avec un reboot: si tu met a jour libssl, t'as le choix entre redemarrer tous les process qui l'utilisaient, ou rebooter la machine. Perso je prefere rebooter la machine: quitte a avoir du downtime, autant etre sur que t'as effectivement tout redemarre.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: et quid de Ksplice ?
Posté par Spack . Évalué à 3.
Sinon il y a kexec qui permet de charger un nouveau noyau sans redémarrer.
[^] # kexec ?
Posté par kadalka . Évalué à -6.
kexec ?
Vous avez personnellement essayé ?
Et… euh… çà marche ?
[^] # Re: et quid de Ksplice ?
Posté par Misc (site web personnel) . Évalué à 4.
s/sans redémarrer/sans passer par le BIOS/
Ce qui est déjà pas mal, je le reconnais, mais tu ne coupes pas au reboot de l'userspace, à la perte de l'état, etc, etc.
[^] # Re: et quid de Ksplice ?
Posté par Spack . Évalué à 3.
Ça c'est quand on fait un reboot avec
kexecinstallé.Pas besoin de couper l'espace utilisateur. En utilisant
kexecmanuellement, on peut charger un nouveau noyau à chaud tout en gardant l'état des services (plus ou moins).Bon ça coupera les connexions réseaux (l'option
--no-ifdownexiste mais je n'ai jamais essayé) mais l'espace utilisateur remarque à peine le changement.[^] # Re: et quid de Ksplice ?
Posté par oinkoink_daotter . Évalué à 1. Dernière modification le 20 mai 2013 à 12:33.
edit : commentaire enlevé, ça m'apprendra à lire.
[^] # Re: et quid de Ksplice ?
Posté par Misc (site web personnel) . Évalué à 4.
Non, le souci n'est pas la licence (en tout cas, ça n'était pas la licence au début), le souci, c'est soit y a des limitations (genre pas le droit de toucher à la taille du code binaire sinon tu décales tout les pointeurs, pas le droit de toucher aux structures, etc, etc), soit tu es obligé de faire des grosses réécritures de la mémoire, et ton kernel est dans un sale état. En fait, quand tu vois que les devs kernels voulait retirer la possibilité de retirer les modules car c'était trop compliqué (à l'époque du 2.6, je crois), c'est bien qu'il y a quelque choses.
Donc pour mettre à jour ton kernel, tu dois "juste" changer du code, mais pour change rle code, faut le faire de tel façon que le kernel soit le même du point de vue du layout. Même si pour les failles les plus importantes, ça semble être bon d'aprés wikipedia, il semble que pour une petite partie des failles ( 12% ), il faut faire intervenir un développeur pour bidouiller la mémoire du kernel. Et bien sur, les chiffres ne parlent que de 64 failles sur 3 ans, quid des autres updates que tu voudrait aussi appliquer sans rebooter ?
Et ça, ça part du principe que tu part avec un kernel connu dont tu as le code, pas un kernel bidouillé ou avec des modules customs ou ce genre de choses. Et bien sur, chaque modif implique un patch spécifique, et chaque patch spécifique implique des tests poussés (car bon, c'est une chose de tester un soft dans un état connu contre une faille, c'est autre chose de tester un soft dans un état inconnu contre une faille et tout les emmerdes possibles, surtout face à des soucis de processeurs multiples, etc. Et tu veux pas non plus que ton update bloque le kernel trop longtemps pendant que tu fait la mise à jour, vu que le kernel est freezé le temps de magouiller tout)
Et je sais pas si tu peux enchainer les updates ksplices advitam eternam.
Donc non, en pratique, la plupart des distributions n'ont pas les ressources (en plus maintenant de plus avoir le code à jour). En pratique, Oracle n'a visiblement même pas les ressources suffisante pour faire ça sur les 2 kernels de sa distribution malgré le fait que leur distribution ne soit qu'un rebuild de l'original (ou alors, ils mentent quand ils disent qu'ils sont compatibles de façon binaire, mais Oracle peut pas jouer sur les 2 tableaux à ce niveau la). IE oracle ne propose ksplice que pour son kernel maison, celui qu'ils rebasent sur le 3.0 (vu qu'ils ont pas envie de faire des rebases peut êtrepour des questions de moyens) avec btrfs en production et supporté, voir http://www.h-online.com/open/news/item/Btrfs-ready-for-production-in-new-Oracle-Linux-kernel-1471706.html .
Ensuite, peut être que je suis mauvaise langue, c'est vrai, ksplice inc avait réussi à avoir 70 clients en 2 ans d'existence, c'est pas mal.
[^] # Re: et quid de Ksplice ?
Posté par Zenitram (site web personnel) . Évalué à 2.
Euh… Je ne connais pas du tout à part le site web, mais sur le site web il y a RHEL, Fedora 2 versions, Ubuntu 4 versions.
Vu le domaine, c'est un marché de niche. Et c'est mieux d'avoir 70 clients à 1 Million que 1 million de client à 10€.
Ce nombre seul ne suffit pas dans ce domaine. On ne sait rien de la valorisation de la chose (Le prix d'achat na pas été rendu public à a connaissance)
[^] # Re: et quid de Ksplice ?
Posté par Misc (site web personnel) . Évalué à 5.
Ben la doc qu'on trouve sur le web ( https://oss.oracle.com/ksplice/docs/ksplice-quickstart.pdf ) dit qu'il faut le kernel maison d'oracle :
Ensuite, la documentation est dite "outdated" ( http://kkempf.wordpress.com/2013/01/24/ksplice-another-reason-to-love-oracle-linux/ ).
Donc je pense plus que tu as le support entreprise pour le kernel maison ( ie la partie intéressante ), et que le reste est disponible grâce à une moulinette semi-automatique et moins intensivement testé et sur laquelle y a pas de garantie (notamment pour les drivers tierces). IE, que le support Fedora/Ubuntu est juste la pour servir de demo sur des machines de test afin d'attirer les clients, tout comme leur version d'essai de 30 jours pour RHEL. Bien sur, Oracle ne parle pas du fait que la version d'essai doit sans doute annuler le support RHEL.
En fait, au vu des postes de blogs ( https://blogs.oracle.com/ksplice/entry/ksplice_update_for_cve_2013 ), il semble que ksplice oblige à attendre le distributeur de base quand même, et au final, vu qu'il y a assez souvent de mesures qui vont réduire l'impact ( mitigation feature, je suis pas sur de traduire ça comme il faut ), ç'est AMHA mieux de passer par les dites features si ton but est d'être protégé vite fait. Du coup, une fois que tu es protégé sans avoir rebooté, tu as plus besoin de ksplice.
Donc oui, comme tu dit, c'est un marché de niche même si 70 clients, c'est déjà pas mal (ie, moi, je connais des boites avec moins de clients en 5 ans) et je pense que plein de gens voudraient ça (mais je connais personne qui utilise ça, alors que le support pour Ubuntu LTS est fourni).
La valorisation de la chose, suffit de voir que c'est juste fourni de base avec le support oracle. Donc ils ont fait le calcul sur le fait que vendre ça comme service, ça rapporte moins que comme "cadeau gratuit" à leur clients existants.
[^] # Re: et quid de Ksplice ?
Posté par ckyl . Évalué à 4.
Ksplice, l'utilité évidente c'est pour les hosting mutualisés, hébergements pourri et assimilés. Bref des environnements exposés ou les solutions techniques des clients est cheap. Ce n'est clairement pas un marché de niche, c'est la majorité du marché.
Les marchés de niche qui ont vraiment besoin de dispo, ils s'ent balance. C'est déjà géré ailleurs dans l'archi. D'ailleurs tu passes déjà ton temps à couper des composants pour faire de la maintenance, des upgrades ou simplement pour vérifier que ca marche bien comme prévu. On coupe déjà des data-center entiers volontairement ou non…
Et pour les niches encore plus spécifiques (lire hors grosse infra web), c'est souvent tellement spécialisé et cloisonné que t'as moins de pression qu'un hosteur ultra-exposé ou que tu as des fenêtres d'upgrade/maintenance régulièrement.
[^] # Re: et quid de Ksplice ?
Posté par Kioob (site web personnel) . Évalué à 2.
Moi je voyais surtout l'intérêt pour les machines chiantes à rebooter, tels les gros serveurs MySQL : tu flush tous les buffers, et la prod peut mettre des plombes à atteindre à nouveau les mêmes perfs.
Maintenant il est vrai que depuis il y a eu quelques avancées à ce niveau :
- XtraDB a l'option «innodb_buffer_pool_restore_at_startup» permettant de rapidement recharger le buffer pool.
- Galera permet de couper un master sans coupure de la prod
Avant ça, c'était parfois problématique de devoir rebooter un serveur MySQL : la réplication asynchrone n'étant pas suffisamment fiable (à mon goût ?), et les solutions disque type DRBD ne règlent pas le problème du buffer pool.
Mais oui, c'était peut-être chercher coté kernel une solution à un problème userspace, MySQL en l'occurrence.
alf.life
[^] # Re: et quid de Ksplice ?
Posté par ckyl . Évalué à 2.
Les DB c'est clairement pas mon domaine. Mais si tu as des contraintes de dispo tu as déjà résolu le problème de "mon master par en vrille". Par ce que de toute facon il va exploser, devoir être mis à jour ou être injoignable un jour ou l'autre.
C'est exactement ce que j'opposais à zenitram. Ce n'est pas un marché de niche, les marchés de niche ont déjà trouvé leur solution. C'est utile pour tout les autres par contre… Pour qui ça peut être un mieux à pas cher, surtout dans les environnements exposés.
Après il faut aussi voir l'exposition de tes services. Une local privilege escalation sur une machine DB on s'en balance un peu à priori ca peut attendre la prochaine maintenance. Même pour un remote tu peux contrer le truc en attendant le slot.
[^] # Re: et quid de Ksplice ?
Posté par Kioob (site web personnel) . Évalué à 1.
Justement, avant les dernières évolutions coté MySQL (Galera & buffer_pool_restore), on avait déjà un failover pour MySQL, mais ce failover avait un coût non négligeable ; donc rebooter un serveur pour une faille locale, clairement on ne le faisait pas, et c'est là que je voyais un intérêt pour les solutions de type Ksplice.
Mais je suis d'accord, une fois que tu as passé le cap du cluster, Ksplice perd tout son intérêt.
alf.life
[^] # Re: HAHA
Posté par stopspam . Évalué à 3.
Belle caricature.
Il y a une vraie différence entre prendre la dernière release upstream et maintenir des patchs sécu sur une ancienne version. Surtout quand on est sûr de passer à côté. A mettre en parallèle avec le temps passer à maintenir ces patchs, je ne suis pas sûr que ça vaille le coup.
[^] # Re: HAHA
Posté par Anonyme . Évalué à 3.
C'est souvent le cas, par ce qu'il n'est pas forcement evident en corrigeant un bug que c'est une faille de sécurité exploitable.
Le truc c'est que dans le kernel, 90% des bugs sont peu etre exploitables, et il n'est pas souvent simple de dire si oui ou non ca l'est. Alors rapporter tous les bugs en tant que faille, je ne suis pas sur que ca change grand chose, ca va juste rendre invisibles les vraies failles qui sont annoncées comme tel.
[^] # Re: HAHA
Posté par Misc (site web personnel) . Évalué à 7.
Bien sur, tu prends en compte le fait que certaines failles sont justes dans les noyaux récents et que ta distro pas-rolling-release n'est pas touché ?
exemple, CVE-2013-1858 CVE-2013-1979 et CVE-2013-1959 dans le noyau 3.8 uniquement, pour ne citer que les plus récentes qui me viennent à l'esprit. Ou justement la faille dont parle le journal, qui touche pas RHEL5 ou plus vieux. Ou par exemple, CVE-2009-1527 qui touche que le 2.6.29.
Et j'ai pris juste une paire d'exploit au pif dans la liste des CVEs, j'ai peut être eu de la chance, mais je suis pas sur.
[^] # Re: HAHA
Posté par Olivier Serve (site web personnel) . Évalué à -3.
C'est très intéressant un serveur où tu laisses un noyau troué pour ne pas avoir à le relancer…
[^] # Re: HAHA
Posté par Zenitram (site web personnel) . Évalué à 5.
C'est très intéressant un serveur que tu redémarres, donc indisponibilité et donc pas terrible du tout, pour mettre à jour un noyau alors qu'il n'y a pas eu de trou de sécurité et que donc c'est inutile pour toi.
[^] # Re: HAHA
Posté par ariasuni . Évalué à 0.
Bof, et alors? Il met pas 45 minutes pour redémarrer. Après je le redémarre pas toutes les deux semaines forcément, ça peut être plus ou moins, mais ça apprend plein de choses de faire tout à la main.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: HAHA
Posté par Kerro . Évalué à 3.
Sur un serveur ?
Je suppose que tu parles d'une machine perso. Dans ce cas effectivement aucun problème. Et dans ce cas on précise « serveur perso » sauf à vouloir embrouiller volontairement les gens.
[^] # Re: HAHA
Posté par Zenitram (site web personnel) . Évalué à 2.
Oui, on peut tout faire à la main, même à manger, faire sa maison et son lit, et construire ses moyens de transports.
Si tu as le temps.
Perso, je ne sais pas comment tu fais, mais moi je n'ai pas le temps de tout faire à la main.
Alors quand on peut ne pas le faire… Surtout sur de la prod.
J'espère qu'on ne te paye pas pour perdre ton temps à apprendre des choses si peu utiles, sinon il y a de quoi râler de la part de celui qui paye si tu ne l'as pas mis au courant de ce que tu fais.
[^] # Re: HAHA
Posté par spider-mario . Évalué à 1.
À moins d’utiliser ksplice.
[^] # Re: HAHA
Posté par claudex . Évalué à 5.
De l'utilité de lire les autres messages avant de poster.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: HAHA
Posté par spider-mario . Évalué à 1.
Contrairement à l’autre message qui mentionne ksplice, le mien lie vers le paquet de l’AUR. Il était bien question d’Arch en particulier, au début de la discussion, et ce paquet permet de l’y utiliser.
[^] # Re: HAHA
Posté par fravashyo (site web personnel) . Évalué à 2.
vu les commentaires, ça n'a pas l'air de fonctionner très bien…
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: HAHA
Posté par Maderios . Évalué à 0.
uname -a
Linux machin 3.9.2 #1 SMP Sat May 18 11:17:11 CEST 2013 x86_64 GNU/Linux
zgrep CONFIG_PERF_EVENTS /boot/config-*
/boot/config-3.9.2:CONFIG_PERF_EVENTS=y
Poster une information ne signifie pas nécessairement adhésion
[^] # Et avant une semaine il était où votre arch linux ?
Posté par kadalka . Évalué à -6.
Et avant une semaine il était où votre arch linux ?
Je vous demande çà parce que je pense que pendant tout ce temps là, ils avaient bien le temps de se balader du côté de chez vous…
(bon c'est vrai qu'il faut avoir un accès à votre machine mais quand même…)
# ArchLinux non affecté ?
Posté par twix . Évalué à 2.
Apparemment mon installation n'est pas impactée, avec un noyau vanilla :
% uname -r
3.7.7-1-ARCH
% zgrep CONFIG_PERF_EVENTS /proc/config.gz
CONFIG_PERF_EVENTS=y
gcc --version
gcc (GCC) 4.8.0 20130502 (prerelease)
% gcc -O2 semtex.c && ./a.out
[1] 16558 killed ./a.out
[^] # Re: ArchLinux non affecté ?
Posté par hitmanu . Évalué à -5.
Pas de chance tu es touché.
Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.
[^] # Re: ArchLinux non affecté ?
Posté par Renault (site web personnel) . Évalué à 6.
Sauf qu'après il compile le programme pour utiliser l'exploit et le programme est tué avant de lui donner les droits root.
Au final il a l'option incriminée, le noyau qui va bien mais l'exploit n'aboutit pas…
[^] # Re: ArchLinux non affecté ?
Posté par patrick_g (site web personnel) . Évalué à 10.
Sauf que l'exploit ne vise pas à marcher partout et sur tous les noyaux de toutes les distros. Il faut faire de petites modifs pour s'adapter aux différences mais cela ne veut pas dire que ton noyau n'est pas vulnérable.
Pour les détails lire le post de Spender ici : http://www.reddit.com/r/netsec/comments/1eb9iw/sdfucksheeporgs_semtexc_local_linux_root_exploit/c9ykrck
# petites precisions
Posté par Guillaume Estival . Évalué à 0.
Juste pour répondre aux quelques commentaires:
_La debian est peut être impacté, je ne sais pas, mais elle présente le CVE dans son DSA donc j'imagine que c'est utile.
_Concernant la solution de regarder /proc/config.gz, ca vient pas de moi, je l'ai lu et la machine que j'ai utilisé pour constater tout ça est une debian squeeze équipé d'un noyau 3.4.4 avec /proc/config.gz présent (un peu de pub pour mon nouveau firewall qui marche très bien http://www.globalscaletechnologies.com/t-dreamplugdetails.aspx )
Je regarderais sur ma debian stock x86 mais il me semblait que config.gz etait present (sur squeeze en tout cas)
Voila. Happy patching ;)
[^] # Re: petites precisions
Posté par kadalka . Évalué à -10.
Le fait de présenter une CVE sous entend que le risque existe. Cela ne veut pas dire qu'il est impacté bien sûr.
Pour votre pub, c'est de l'ASP.NET votre site ? Non ? :D
# Silent patching
Posté par tuxicoman (site web personnel) . Évalué à 1.
Je ne comprends pas vraiment l'histoire.
L'article dit que le patch existe depuis quelque temps mais si il n'y a pas d'annonce de faille de sécurité, je comprends que les distributions ne poussent pas les utilisateurs à faire une mise à jour de noyau sur leur version "stable".
[^] # Re: Silent patching
Posté par pasBill pasGates . Évalué à 4.
b) C'est tres frequent dans le monde de la vente d'exploits, il n'a rien fait d'etonnant. VUPEN a fait de meme il y a 2 semaines quand on a corrige 2 bugs trouves en interne mais qu'ils avaient deja trouve il y a longtemps et exploite.
[^] # Re: Silent patching
Posté par Maclag . Évalué à 3.
Bon je te pose la question à toi mais j'aurais pu plus haut:
C'est légal le commerce d'exploit??
Parce qu'on peut toujours parler de simple programme ou démonstration, mais le patch de correction et quelques explications seraient aussi bien, alors comment justifier la non intention de nuire?
[^] # Re: Silent patching
Posté par lolop (site web personnel) . Évalué à 5.
C'est leur utilisation pour pénétrer ou saboter un système qui ne t'appartient pas qui est illégale. Un peu comme les armes quoi.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Silent patching
Posté par pasBill pasGates . Évalué à -1.
Ca depend ou tu vis, en Allemagne par exemple il est interdit de vendre des exploits.
[^] # Re: Silent patching
Posté par kadalka . Évalué à -7.
Et en donner c'est autorisé ?
(donner ce n'est pas vendre contre rémunération)
[^] # Re: Silent patching
Posté par Snoorky . Évalué à 3.
Même les boîtes comme HP suivent le marché des exploits pour leurs solutions de sécurité comme Fortify, donc j'imagine ça comme une grande Bourse avec d'un côté les éditeurs d'antivirus et autres sociétés et de l'autre, bin les mafias diverses et variées.
[^] # Re: Silent patching
Posté par fouinto . Évalué à 10.
Mais y a qui de l'autre côté ? (humour)
[^] # C'est légal le commerce d'exploit? J'en doute
Posté par kadalka . Évalué à 10.
A ma connaissance en France l'usage ou l'incitation à l'usage de moyen permettant de s'introduire dans un système informatique est illégal…
" Le fait, sans motif légitime, d'importer, de détenir, d'offrir, de céder ou de mettre à disposition un équipement, un instrument, un programme informatique ou toute donnée conçus ou spécialement adaptés pour commettre une ou plusieurs des infractions prévues par les articles 323-1 à 323-3 est puni des peines prévues respectivement pour l'infraction elle-même ou pour l'infraction la plus sévèrement réprimée "
Code pénal - Article 323-3-1 | Legifrance
[^] # Re: C'est légal le commerce d'exploit? J'en doute
Posté par Antoine . Évalué à 1.
Me demande pourquoi ce message est moinssé à fond les manettes, vu que pour le coup il est plutôt pertinent.
[^] # Re: C'est légal le commerce d'exploit? J'en doute
Posté par Zenitram (site web personnel) . Évalué à 1.
kadalka est trolleur professionnel (mais contrairement à moi, il tape surtout dans le négatif) et commence à -10 vu la merde (ce n'est pas moi qui le dit, mais les utilisateurs de ce site) qu'il raconte d'habitude. La, en fait, il a déjà eu plein de "pertinent" sur ce commentaire.
[^] # Re: C'est légal le commerce d'exploit? J'en doute
Posté par Antoine . Évalué à 2.
Ah, on peut commencer à -10 ? Purée :-)
[^] # Re: C'est légal le commerce d'exploit? J'en doute
Posté par Misc (site web personnel) . Évalué à 3.
Disons qu'on peut descendre très vite, y a que 150 messages à lire, tu peux te faire une idée.
[^] # Re: C'est légal le commerce d'exploit? J'en doute
Posté par kadalka . Évalué à -7.
Je n'ai pas remarqué qu'on me paye pour troller mais je n'ai pas vu mon compte bancaire évoluer depuis que j'ai mis les pieds à linuxfr…
Peut-être qu'il y a un délai d'attente ? :D
[^] # Re: C'est légal le commerce d'exploit? J'en doute
Posté par Tharkun2 (site web personnel) . Évalué à 1.
Tu as oublié de graisser la partie qui rend légal le commerce d'exploit : sans motif légitime. Toutes boites/labos bossant dans la sécurité, ou disposant d'au moins une personne s'assurant de la sécurité de son SI, peut invoquer un motif légitime pour acheter des exploits.
[^] # Re: C'est légal le commerce d'exploit? J'en doute
Posté par kadalka . Évalué à -10. Dernière modification le 20 mai 2013 à 21:50.
C'est volontaire, car je suis vu comme un trolleur professionnel…
Il faut décourager la légitimité, même chez les antivirus.
(Faut bien encourager Linux au détriment de windows… :P)
[Ah oui, c'est vrai que les rootkits…]
[^] # Re: C'est légal le commerce d'exploit? J'en doute
Posté par ariasuni . Évalué à 1.
Je comprend pas bien ce que tu veux dire…
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: C'est légal le commerce d'exploit? J'en doute
Posté par kadalka . Évalué à -10.
C'est une vanne : il me reproche de ne pas graisser. [Je lui dit que c'est volontaire :D]
Je sous entends que je ne veux pas engraisser les fabricants d'antivirus qui permettent indirectement à M$ Window$ de vivre.
Si Window$ est complétement vulnérable, personne n'en voudra…
Si il est interdit de faire des recherches dans le domaine des antivirus, et pas d'autre chose, Windows tombera facilement…
[^] # Re: C'est légal le commerce d'exploit? J'en doute
Posté par xcomcmdr . Évalué à 2.
Les virus, c'est pas que pour Windows.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C'est légal le commerce d'exploit? J'en doute
Posté par kadalka . Évalué à -9.
LOL
J'avais dit que c'était une vanne…
Tout système informatique risque d'être infecté par un code malveillant.
(rootkit, spyware, backdoor, worms, virus of course, etc.)
[^] # Re: C'est légal le commerce d'exploit? J'en doute
Posté par pasBill pasGates . Évalué à -3.
Ben sachant que VUPEN fait cela de maniere ouverte, avec l'assentiment du gouvernement francais(indice: ils n'ont que des employes francais…), je me permettrai de dire qu'en pratique c'est pas le cas.
[^] # Re: Silent patching
Posté par Littleboy . Évalué à 1.
Ca depend a qui tu les vends. Les organisations qui font ca de maniere ouverte bossent generalement avec les gouvernements, ca aide :)
Et puis on trouve plein de boites de secu qui ne vendent pas l'exploit en lui-meme mais le correctif, juste pour leur clients. On peut trouver ca pas gentil (suivant sa morale) mais ca va etre dur de prouver que c'est illegal.
[^] # Re: Silent patching
Posté par Maclag . Évalué à 3.
C'est ce que je veux dire: le correctif, même avec explications sur le possible exploit, tu pourrais dire que c'est à valeur éducative. Si tu veux ne le vendre qu'à tes clients, c'est un business comme un autre (moral ou pas, c'est une autre affaire).
Mais vendre un code qui n'a d'autres utilisations possibles que d'entrer illégalement sur un serveur tierce, je vois difficilement comment on peut justifier ça. C'est pas juste vendre une arme, c'est une tête chercheuse avec cible déjà entrée.
[^] # Re: Silent patching
Posté par groumly . Évalué à 0.
C'est discutable.
Faut bien verifier que le patch corrige le probleme, non? Il te faut l'exploit pour 1) prouver que le probleme existe 2) prouver que le probleme est corrige.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Silent patching
Posté par Zenitram (site web personnel) . Évalué à 1.
Pas forcément : par définition, on sait qu'un buffer non maîtrisé peut amener à tout et n'importe quoi.
1) est donc de voir que tu tapes pas la où il faut
2) est donc de voir que tu ne tapes plus
C'est ce qui a été fait sur le GIT si j'ai bien compris (la personne ne savait pas forcément que c'était utilisable en vrai)
Pas besoin de prouver que tu passes root pour devoir corriger ce type de problème, il faut le corriger dans tous les cas.
Par contre, pour sortir un CVE, il faut prouver que ça craint sinon on ne s'en sort plus (c'est simple, tu rebootes toutes les heures à partir du GIT, ou alors tu es noyé dans le flot et ne regardes plus), et donc la il faut ton 1) et 2).
Le hic est que ça prend 1000x plus de temps, et que pendant que certains s'amusent à faire un OS blindé inutile car le temps passé est sur l'écriture de CVE pour chaque patch, d'autres font un OS utile et utilisé avec parfois une faille mais pas tant que ça en fait.
Ca s'appelle un compromis (entre sécurité et fonctionnalité).
[^] # Re: Silent patching
Posté par groumly . Évalué à 1.
Ben si. Si tu veux vendre un patch comme resolvant une elevation de privilege, faut bien prouver qu'il ya une elevation de privilege. Si ca fait juste un segfault, personne ne va acheter le patch.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Silent patching
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 20 mai 2013 à 08:17.
J'ai zappé la partie "vente" du thread, forcément du coup je raconte n'importe quoi ou plutôt je te rejoins. Je nuancerai juste en disant que si tu es responsable, tu fais alors un logiciels closed-source avec obfuscation qui fait juste un appel root à la con pour démontrer en essayant d’empêcher le client de pouvoir l'utiliser pour autre chose.
[^] # Re: Silent patching
Posté par Misc (site web personnel) . Évalué à 5.
Un segfault peut aussi induire un DoS, et un DoS est un souci de sécurité. La sécurité vise à assurer la disponibilité et l'intégrité du SI entre autres choses. Si ton SI ( on va dire celui d'une agence de recrutement ) ne marche pas car un petit malin a mis un cv qui fait planté ton système, tu perds la disponibilité, don cdu pognon. Et ça, c'est pas bon(tm). Ensuite, bien sur, une elevation de privilége en root, ça fait tout de suite plus peur. "oh attention, quelqu'un va devenir root et à partir de la, envoyer du spam, ou piquer votre base de données de cv".
Curieusement, ce genre d'argument pour windows xp ne marche pas pour faire migrer les gens vers un autre OS bureautique, ce qui montre que les gens ont un modèle mentale spécifique des attaques.
[^] # Re: Silent patching
Posté par pasBill pasGates . Évalué à -4.
Bien souvent tu sais sans devoir le faire si le probleme est une elevation de privilege. Tu regardes la primitive que le bug te donne (disons par exemple la possibilite d'ecrire 4 bytes n'importe ou dans le processus) et tu sauras deja dans 90% des cas ce que tu as, sans avoir besoin d'ecrire une ligne de code.
[^] # Re: Silent patching
Posté par pasBill pasGates . Évalué à -4.
Faut comprendre ce qu'est un exploit :
Pour verifier le patch, tout ce dont tu as besoin est d'un bout de code qui cause le probleme, typiquement pour une elevation de privilege t'auras un crash. T'as pas besoin d'avoir un exploit complet qui s'occupe de gerer ASLR, NX, faire du ROP et executer ton code.
[^] # Re: Silent patching
Posté par Misc (site web personnel) . Évalué à 5.
C'est assez délicat de savoir si tu as un truc exploitable ou pas dans la plupart des cas. Même sur des failles simples ( genre usage de /tmp avec un nom un peu prévisible ), tu passes du temps à essayer de voir si tu as un scenario pour monter une attaque pour pas apparaitre comme celui qui dit de la merde et qui s'affole sans savoir de quoi il parle.
Et les attaques les plus simples ( genre buffer overflow ) sont de nos jours assez bien comprises et anticipés ( au moins dans le code du kernel ), donc il reste que les cas les plus compliqués qui sont dur à évaluer.
# Quel est le risque ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 9.
Est-ce que la vulnérabilité est depuis une session locale ou distante ?
Est-ce qu'un firewall qui bloque tous les services permet de protéger la machine depuis internet ?
Dans ce dernier cas, on a quelques répits avant d'être obligé de faire une (grosse) mise à jour.
[^] # Re: Quel est le risque ?
Posté par syntaxerror . Évalué à 9.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2094
Escalade de privilèges en local. Il faut déjà avoir un accès à la machine, légitime ou frauduleux :p
[^] # Re: Quel est le risque ?
Posté par Misc (site web personnel) . Évalué à 3. Dernière modification le 18 mai 2013 à 20:24.
Locale
On a déployé au boulot un fix basé sur systemtap, qui est d'ailleurs dans les liens :
https://bugzilla.redhat.com/show_bug.cgi?id=962792#c13
Ensuite, faut avoir systemtap sur sa distribution ( et vu que pour le moment, ça sert pas mal pour écrire ce genre de magouille, je pense que toute les distros devraient l'adopter vite fait )
# Hoax ?
Posté par david96 (site web personnel) . Évalué à -10.
C'est marrant,on dirait que cette annonce est un Hoax… Désolé, mais c'est la première impression que j'en ai.
Pas besoin d'être un pro pour aider la communauté Débiane : utilisez simplement apt-p2p
[^] # Re: Hoax ?
Posté par Marc Quinton . Évalué à 9.
pour ma part, ca marche : wget … ; gcc -O2 machin.c ; ./a.out ; id -> root ; ca n'a rien d'un hoax.
[^] # Re: Hoax ?
Posté par patrick_g (site web personnel) . Évalué à 4.
Ta distro n'a pas encore publié un noyau patché ? Tu utilises quoi ?
[^] # Re: Hoax ?
Posté par Marc Quinton . Évalué à 2.
c'est une debian wheezy 64 bits ; pas tout a fait à jour. Ne me demande pas trop pourquoi, ca m'étonne moi-même.
[^] # Re: Hoax ?
Posté par Space_e_man (site web personnel) . Évalué à 0.
… mais …
Cela signifie-t-il que mon noyau … "est cool" ? :)
# Dépêche bookmark
Posté par Spack . Évalué à 10.
Merci pour l'info mais je trouve la dépêche un peu vide : « Ah! Au fait il y a un exploit root sur Linux… » Il n'y a pas vraiment de détails sur la nature de la faille ni son histoire…
[^] # Re: Dépêche bookmark
Posté par Maclag . Évalué à 5.
À la décharge de l'auteur et les modérateurs, il y a justification à publier plus vite: la faille est mal rapportée mais déjà exploitée.
"La plupart des distros" ne couvre peut-être pas tout le monde ici, et je pense qu'il faut voir plutôt une manière de donner une alerte plutôt qu'un article technique.
[^] # Re: Dépêche bookmark
Posté par Guillaume Estival . Évalué à 10.
On va appeler ca un "choix éditorial":
* Soit tu publies la news au plus vite avec le minimum d'informations (savoir si on est impacté, le numéro du CVE pour surveiller les security advistory de sa distrib)
* Soit tu fais un papier détaillé, sachant que je ne peux pas (légalement) traduire bêtement le papier de ars pour le publier ailleurs (j'avais posé la question lors du dossier hb gary et… c'est compliqué…), qui sera plus long et plus intéressant pour les spécialistes du noyau mais qui fera chier la majorité des gens
Je fais donc un papier pour la majorité des gens sachant que:
* Les spécialistes sont a 99% sur la liste lkml et sont déjà au courant
* Les 1% restant sont capable de suivre les liens de ars pour avoir plus d'infos.
* La majorité des gens (et aussi un peu moi) se foutent des détails du bug en fait, on a juste besoin de savoir qu'on est POWNABLE.
Sinon pour un autre commentaire, je ne fais pas une news sur chaque CVE (vu le nombre…), il y a un certain nombre de conditions:
* uniquement root exploit local ou remote
* un exploit est dispo et LIVE
* Le patch n'existe pas encore
* Ou le patch existe mais n'est pas forcement backporté sur toute les distrib.
Ça reste relativement rare d'avoir toutes ses conditions, et je n’hésiterais pas a refaire une news si le cas se représente :)
Voili!
# résolu dans Mageia
Posté par CyrrusSmith (site web personnel) . Évalué à 1.
Après vérification auprès de l'équipe, ce problème n'atteint pas la Mageia 3, qui vient de sortir, car fonctionnant sur un kernel 3.8.13, et pour la Mageia 2, kernel 3.4.* un patch a été publié dans les mises à jour.
# root-exploit-sur-les-noyaux-linux
Posté par DanyL . Évalué à -3. Dernière modification le 20 mai 2013 à 01:35.
gzip: /proc/config.gz: No such file or directory
[^] # Re: root-exploit-sur-les-noyaux-linux
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Sur des Debian GNU/Linux ou Ubuntu Server :
$ grep CONFIG_PERF_EVENTS /boot/config*
CONFIG_PERF_EVENTS=y
(sur des 2.6.32-5-686, 2.6.32-5-686-bigmem, 2.6.38-*-server, 3.0.0-*-server, 3.2.0-*-686-pae, 3.2.0-*-generic, 3.8-2-686-pae, …)
[^] # Re: root-exploit-sur-les-noyaux-linux
Posté par jihele . Évalué à 1.
http://packages.qa.debian.org/l/linux.html
Apparemment, en debian stable c'est corrigé mais en testing ? Pourquoi est-ce que le fix n'est pas présent sur la branche testing ?
Parce qu'on attend la 3.8 de unstable qui arrive pas ?
Parce que quand on est en testing on doit aussi avoir une référence à stable-sec dans son sources.list de sorte que le paquet corrigé a priorité ? C'est quoi la ligne qui correspond ? Moi, j'ai ça, et je vois pas de 3.2.41-2+deb7u2 dans aptitude.
# root-exploit-sur-les-noyaux-linux
Posté par DanyL . Évalué à -6.
gzip: /proc/config.gz: No such file or directory
# Rien à foutre
Posté par Anonyme . Évalué à 2. Dernière modification le 20 mai 2013 à 11:41.
J’ai un kernel GRSec de Nazi, l’exploit se fait démonter la gueule :
[^] # Re: Rien à foutre
Posté par claudex . Évalué à 10.
Tu aurais monté ton /home en
noexec, tu aurais eu un résultat similaire, ça ne montre pas grand chose.« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.