Bonjour,
Une fois n'est pas coutume, je vais commencer par parler de microsoft sur ce site francophone linuxien.
Vous le savez, microsoft prend la sécurité de ses produits très au sérieux depuis une dizaine d'année (windows XP SP2 environ). Ils ont mis en place un système de patch à date fixe, le second mardi du mois, surnommé rapidement "patch tuesday". Les équipes opérationnelles peuvent prévoir des astreintes supplémentaires ce mardi pour tester/qualifier et pousser les patchs.
Ce mardi a été un petit peu spécial. Microsoft, jaloux des failles openssl en balance une à son tour. Il décide de publier un patch appelé MS14-066 dont la gravité et l'impact font rêver tout pentesteur un peu sérieux: du remote code execution sur tout service utilisant SSL. Du velours pour les attaquants. Microsoft a par contre été un peu plus léger côté bulletin: ils ne parlent que d'un malformed packet qui peut faire crasher le service et éventuellement, exécuter du code.
Bref, la carotte est belle, et tous les experts sécu du monde se sont mis à analyser le patch binaire car un exploit de ce genre peut vous apporter la gloire, et accessoirement beaucoup de sous. Mais l'analyse est compliquée. Car vous le savez, Microsoft ne fournit ni les sources de ses produits, ni les sources de ses patchs. Et si je suis bien les différents communiqués, Microsoft a volontairement compliqué la tâche des attaquants. Le patch ne couvre pas la vulnérabilité, mais un ensemble de composants, allant de l'ajout de cipher SSL au correctif mineur, en passant par la fameuse faille critique. Tout ça enrobé dans un petit peu d'obfuscation apparemment puisque ce correctif amène des plantages sur certaines configurations. Microsoft ne prend pas toujours autant de précautions, mais dans ce cas présent et au vu de l'impact de la faille, ils ont mis le paquet.
Nous sommes lundi, presque une semaine après le patch Tuesday et il n'y a toujours aucun exploit disponible publiquement (en tout cas pas que j'aie vu). Quelques grands noms (metasploit par exemple), ont vaguement trouvé des heap overflow ou des crash, mais sans réussir à concrétiser une attaque derrière.
Maintenant que le décor est planté, revenons à notre open source.
Lorsqu'il y a une faille de sécurité de ce calibre (au hasard Heartbleed), les attaquants ont à disposition les sources, et le source du patch. Il ne leur faut pas très longtemps pour parvenir à un exploit fonctionnel. Pour Heartbleed il a fallu moins de 24h de mémoire, pour Shellshock, ça a été immédiat. Ca me fait mal au cul de le dire, mais dans certaines circonstances, le closed source permet de donner plus de chances à un défenseur pour protéger son parc. Microsoft a pas trop mal joué en faisant un pot-pourri de patchs livrés en un seul blob binaire, ce qui est impossible pour de l'open source. Il n'est pas question de sécurité par l'obscurité ici, le bug est connu, son impact est révélé, et les admins ont le temps de patcher. Seul l'exploit est obscur.
Cela m'amène à une question: est il possible de patcher une faille de sécurité open source sans en révéler l'exploit associé?
# Ne vas pas trop vite !
Posté par Jiehong (site web personnel) . Évalué à 10.
Il est tout à fait possible d'ouvrir une CVE, mais dont le contenu n'est pas public, et ne la révéler que quand elle est intégrée, et distribuée !
L'avantage de l'open source se voit sur le global : il y a plus d'yeux, donc de chance de trouver et de corriger des failles de sécurités. Les logiciels propriétaires dépendent entièrement du budget que l'entreprise leurs consacre, et il se peut qu'une faille trouvée, exploitée, ne soit jamais corrigée en amont… est-ce mieux ? Je ne crois pas.
Après, sur un logiciel libre n'impliquant que peu de personnes, statistiquement, le risque de failles est simplement plus élevée, mais ça tu n'y peux rien.
Il me semble que le sujet de rendre publique une faille et sa CVE avant sa correction était l'objet d'un débat houleux qui avait finalement conduit à la fermeture d'une liste de diffusion dont je viens de zapper le nom, puis finalement à sa rouverture.
[^] # Re: Ne vas pas trop vite !
Posté par cosmocat . Évalué à -9. Dernière modification le 17 novembre 2014 à 14:43.
J'adore les gens qui ne savent pas à qui ils s'adressent (et donc qui ne connait pas le background de ces personnes) et qui emploient des acronymes en espérant qu'ils soient déjà connu de tous.
En général, on explicite tout le temps un acronyme lors de la première utilisation, à moins d'être sûr que les interlocuteurs le connaisse (ce qui ne peut être vrai ici….)
CVE : Common Vulnerabilities and Exposures
[^] # Re: Ne vas pas trop vite !
Posté par barmic . Évalué à 10.
Et tu ne fais pas la remarque pour le journal qui parle de SSL sans dire de quoi il s'agit ? Il faut avoir vécu dans une grotte pour ne pas avoir entendu parler de shellchock et de heartbleed et des CVE associés (les journaux et dépêches qui en font mention ici n'explicitent jamais l'acronyme d'ailleurs).
Au passage dire que CVE signifie Common Vulnerabilities and Exposures n'apporte aucune information utile au lecteur (ou alors vraiment très peu). Indiquer que c'est un annuaire de faille de sécurité publique pouvant concerner n'importe quel logiciel est déjà plus intéressant AMHA, ou alors simplement donner un lien qui va bien.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ne vas pas trop vite !
Posté par Jiehong (site web personnel) . Évalué à 7.
C'est gentil, et c'est noté ;)
L'auteur du journal ne sait pas à qui il s'adresse : moi, je ne sais pas ce qu'MS-14-066 signifie. Serait-ce « Mission Satirique numéro 14, essai 66 » ?
J'aurais pu mettre un lien, c'est vrai, mais ce n'est pas la première fois que CVE apparaît sur linuxfr, alors je me disais que mitsurugi était un lecteur habitué…
Mais ce souci d'acronymes mystérieux se retrouve beaucoup trop dans les lois, et c'est un vrai problème là.
[^] # Re: Ne vas pas trop vite !
Posté par octane . Évalué à 10.
Le problème, si j'ai bien compris, ce n'est pas le numéro de CVE, c'est l'analysabilité de la chose. Donc si le correctif est distribué en open source, alors il est analysable, CVE ou pas…
Sauf que dans les faits, personne ne le fait. Ecrire du code, ça plait à tout le monde. Relire le code des autres, c'est pénible. Et généralement, lorsqu'il faut faire des audits de code, c'est tellement chiant qu'il faut payer des gens pour le faire. Close source payant => du budget pour payer des relecteurs. Opensource sans sous, pas de relecteurs, on compte sur la bonne volonté. Lorsqu'openBSD forke openssl, il tombe sur je ne sais plus combien de bugs. Moralité: personne n'a lu sérieusement openssl. Et c'est un peu pareil pour tout les logiciels open source.
Ca oui. Le logiciel libre te permet de patcher toi même le code, indépendemment d'un éditeur quelconque. Et ça, c'est vraiment un plus énorme!
"full disclosure", et non la fermeture et réouverture n'avait rien à voir avec le disclosure, mais avec l'attitude pénible de certains contributeurs.
[^] # Re: Ne vas pas trop vite !
Posté par Inso . Évalué à 3.
C'est clairement le soucis principal de l'opensource, le manque de financements.
Il faudrait peut-être travailler de ce coté là. Techniquement, l'opensource est supérieur sur tout les points (il suffit de mesurer son succès, en se rappelant que tout ceci s'est développé en concurrence avec du closedsource).
Mais il faut vraiment que le financement de l'opensource cesse d'être tant négligé par les communautés. Ca avance (beaucoup de "libristes" lancent des projets libres sans oublier le problème du financement), mais on est très loin d'avoir les capacités monétaires d'un outil closedsource…
[^] # Re: Ne vas pas trop vite !
Posté par Etienne Bagnoud (site web personnel) . Évalué à 10.
Je lis du code souvent pour voir comment c'est fait et j'ai envoyé des patch parce que "oh ! le pointeur est utilisé après un malloc sans vérifier le cas où NULL aurait été retourné". Donc au moins une personne le fait (pas des masses de bug corrigé ainsi, mais c'est mieux que rien).
Avant de me décider pour utiliser un logiciel opensource plutôt qu'un autre, je passe en revu des morceaux de codes, tirés au hasard, pour savoir si le code est propre (selon mes propres standards évidemment).
Beaucoup de monde a lu openssl et, après avoir lu aussi des parties de codes, je me suis dis "oh, c'est dégueulasse, ça peut pas marcher", en cherchant un peu j'ai trouvé d'autres personnes ayant eu la même pensée que moi, publié sur ce sujet et s'être fait ridiculiser parce que non, quand même, openssl c'est trop la classe, ils sont trop bons les gars … alors j'ai rien dis et évité openssl autant que possible.
Le problème est le même partout, tu as les "grands noms" et les autres. Tu peux voir des trucs absurdes dans des gros projets, si tu n'es pas un grand nom personne ne t'écoute. Il y a peu je suis tomber sur un article à propos d'un projet opensource, je vais, je regarde le code, je trouve une série de malloc sans contrôle de la valeur de retour. Je prépare un patch, l'envoie, en retour je reçois d'un "grand nom" que ça sert à rien, ça rend le code moche, les OS ils gèrent de toute façon, blablabla …
J'ai des semaines de travail qui sont partis à la poubelle à cause de ça sur php-ldap …
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Ne vas pas trop vite !
Posté par barmic . Évalué à 5.
En même temps beugler que le code est moche ça n'est ni très utile, ni très intéressant. Pointer des problèmes précis et remonter des bugs ça ça fait avancer les choses ("hé regarde là tu ne vérifie pas la taille de ce que l'on t'envoie"). Le nom en s'en fou ! Tu n'a pas à avoir un grand nom, tu peut te contenter de remonter le bug à ta distro qui s'occupera d'aller secouer l'upstream.
Je ne fais plus beaucoup de C, mais c'est un débat qu'il y a eu ici même via 2 journaux de Etienne Bagnoud :
Je ne vais pas te dire qui a tord et qui a raison, mais ça ne semble pas aussi évident que ce que tu avance.
Par contre si ta relecture consiste surtout à vérifier que les retours d'allocations sont vérifiés je te conseil d'investir (pas forcément financièrement) dans un analyseur statique de code ça permet d'être exhaustif plutôt que d'aller piocher quelques bouts de code au hasard.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ne vas pas trop vite !
Posté par Etienne Bagnoud (site web personnel) . Évalué à 7. Dernière modification le 18 novembre 2014 à 10:28.
Si je vois quelque chose et que je peux le corriger, je le fais, si je ne peux pas j'ouvre un rapport de bug. À aucun moment je dis que je fais juste gueuler sur le code des autres, au contraire je suis plutôt silencieux. Ces expériences sont chaque fois liées à un patch n'apportant rien qu'une correction évitant des bugs triviaux.
J'ai corrigé un bout de code dans openldap, ça faisait planter le serveur dès qu'on envoyait une requête correctement formée, suivant le protocole, mais qui retournait pas de résultat. À partir du moment où l'authentification, et certainement d'autres services, s'arrêtent de fonctionner pour une requête correcte mais ne retournant pas de résultat, je penses que c'est évident que le retour doit être vérifié (il me semble, ça fait longtemps donc ma mémoire peut me tromper, qu'il n'y avait pas besoin d'être authentifié sur le serveur avant d'envoyer la requête).
Ma relecture est simplement dans un processus de sélection entre X ou Y. Quand j'arrive pas à me décider entre les deux, je prends un peu de code et si le code me plaît, dans un sens totalement subjectif, ben je vais préférer ce dernier. Si je vois un bug durant cette lecture, je le corrige ou le signal. Je n'ai pas le temps de faire de la relecture de code complète avec analyse statique, détection de fuites de mémoire, …
Et j'aime lire du C, je ne vais pas m'en priver.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Ne vas pas trop vite !
Posté par barmic . Évalué à 3.
En principe il faut toujours remonter un bug (dans le quel tu fourni le patch si tu en a un). Ça permet de mettre en évidence le problème en question.
Probablement trop abstrait pour moi, je vois pas de liens entre ce que peut te répondre ou pas un serveur et le fait qu'une allocation mémoire plante. Si tu as un cas d'erreur claire, tu peux le remonter. Ensuite si l'upstream ne réagis pas, il y a une probabilité non nulle qu'il y ai des
fork(par exemple que les distributions fournissent des versions patchées du logiciel).Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ne vas pas trop vite !
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Je me suis mal-exprimé parce que je considère qu'envoyer un patch se fait par le système de bug donc ouvrir un nouveau bug c'est un pré-requis (et je considère que rechercher si un patch existe déjà, ainsi qu'un bug déjà ouvert, fait partie des pré-requis pour ouvrir un bug).
Au sein d'un module openldap il n'assumait pas ce cas et c'est tout slapd qui tombait, donc plus de serveur openldap.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Ne vas pas trop vite !
Posté par Okki (site web personnel, Mastodon) . Évalué à 8.
À la suite d'Heartbleed, la Linux Foundation a monté le projet Core Infrastructure Initiative, justement pour financer un certain nombre de projets libres cruciaux, qui étaient clairement sous-financés jusqu'à présent.
De son côté, Google a également mis en place un projet pour récompenser financièrement toute personne qui rapporterai des failles de sécurité sur un certain nombre de projets libres importants pour le fonctionnement d'Internet.
On peut donc se dire que les entreprises commencent à se réveiller, à réaliser que d'utiliser tout un tas de logiciels libres gratuitement, sans jamais rien donner en retour, pouvait leur être tôt ou tard, particulièrement préjudiciable.
[^] # Re: Ne vas pas trop vite !
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 17 novembre 2014 à 15:11.
tu parles de toi?
Ici, l'auteur du journal parle d'avoir toujours pas d'exploit après que le patch soit dans la nature.
Tu n'as pas compris le journal : l'auteur du journal a écrit (le gras de moi) "Nous sommes lundi, presque une semaine après le patch Tuesday et il n'y a toujours aucun exploit disponible publiquement". Tu devrais vraiment lire le journal avant d'écrire un commentaire, car c'est bien le sujet principal de son journal : révéler la faille quand le patch commence (donc pas encore fini de) à être distribué est problématique, et tu as zappé ça.
belle théorie. La pratique a montré que ça ne marche pas comme ça.
Oui, clair, OpenSSL c'est vraiment peu de personnes, avec peu d'utilisateurs… ou pas.
Le Full Disclosure n'est pas le sujet (c'est encore pire que le sujet du journal). Le sujet est la problématique de connaitre la faille lors du début de distribution du patch en Open-source contre plus long en Closed-Source (et c'est un sujet très interessant). Relit le journal.
[^] # Re: Ne vas pas trop vite !
Posté par Jiehong (site web personnel) . Évalué à 5.
Il semblerait ;)
Un seul exemple permet une conclusion générale ? Contre exemple : le noyau Linux. Bref, c'est statistiquement biaisé de répondre ça. La théorie rend ça possible, ce qui l'est moins avec du propriétaire ; il n'y a pas de données pour comparer l'open source du propriétaire de toutes façons.
[^] # Re: Ne vas pas trop vite !
Posté par khivapia . Évalué à 0.
révéler la faille quand le patch commence (donc pas encore fini de) à être distribué est problématique,
Oui, d'où ce que disait Jiehong justement, de ne "la révéler que quand elle est intégrée, et distribuée !"
je pense que "Tu devrais vraiment lire
le journalle commentaire avant d'écrire un commentaire" auquel tu réponds…Il est bien possible de ne révéler la faille qu'une fois que le correctif est largement déployé (ce qui doit pas prendre longtemps, comme pour tous les patches de sécurité). Après si déployer le patche lui-même donne (un peu) plus d'information sur la nature du correctif quand le code source est ouvert, sans détail supplémentaire il est noyé dans la masse des patches de sécurité du jour, dont la facilité d'exploitation est extrêmement variable. En outre de toutes façons l'exploitation dépend toujours du code assembleur réellement utilisé par la cible ; dans cette course, c'est une question d'heures (soit pour déployer le correctif, soit pour mettre au point et déployer une attaque). Les cibles les plus faciles (les plus exposés) pour l'attaquant sont celles qui, étant justement exposées, ont dû mettre en place un déploiement des correctifs rapide !
[^] # Re: Ne vas pas trop vite !
Posté par groumly . Évalué à 7.
Debian openssl, apple ssl, heartbleed et shellshock en sont de parfait exemples, d'alleurs. Ou encore php (just formthe lulz).
Non, la realite c'est que personne ne relir le code parce que c'est chiant a mourir, et que c'est de toutes facons pas comme ca qu'on trouve la plupart des failles, et personne n'ecrit de tests parce que c'est chiant a mourir et que ca casse les builds.
La realite c'est qu'a moins de payer des gens a plein temps pour faire ce boulot, personne ne le fait. Libre ou pas n'est pas la question.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Ne vas pas trop vite !
Posté par anaseto (site web personnel) . Évalué à 4.
Je pense que c'est plus compliqué que ça. Dans les programmes libres qui sont en grande partie bénévoles, il est logique que chacun fasse ce qui l'intéresse le plus. C'est pour ça que dans ces la sécurité ne sera probablement pas une priorité, ni les relectures de code dans cet esprit, même si le fait de publier le code doit en pousser plus d'un à, au moins, laisser quelque chose qui fait pas trop mal aux yeux. Dans les projets libres qui font suffisamment d'argent, il y a peut-être des gens payés pour s'inquiéter de la sécurité, mais comme probablement dans le propriétaire, j'imagine que ce n'est pas souvent une priorité. Du coup, par rapport au code propriétaire d'une entreprise s'inquiétant spécialement pour la sécurité, beaucoup de projets libres peuvent faire moins bien, parce que personne n'est payé pour vérifier les fonctionnalités qui s'ajoutent à l'infini, et c'est pas dit qu'il y ait plus d'yeux à la fin. Mais tu peux aussi avoir l'effet contraire : si tu ne dépends d'aucune entreprise ou sponsor en particulier, tu as plus la liberté de faire ce que tu veux, et tu peux obtenir des projets comme OpenBSD où les audits et la sécurité font partie d'un effort et d'une philosophie qui ne serait pas facile à justifier pour une entreprise où on fait pas les dépenses au hasard.
# Sécurité et confiance
Posté par THE_ALF_ . Évalué à 10. Dernière modification le 17 novembre 2014 à 15:29.
D'un autre coté, le fait ne pas avoir l'exploit associé empêche de pouvoir tester l'efficacité du patch, non? On se retrouve alors à devoir faire confiance au développeur closed-source: on sait qu'il y a eu un problème, que celui-ci est censé être corrigé, mais cela reste obscur sur ce qui a été effectivement corrigé, et sur la nature de ce correctif (le problème est-il vraiment résolu? Est-ce un gros quick and dirty hack pour boucher le trou le temps de trouver plus propre?).
D'où ma question (naïve?): est-il possible de patcher un faille de sécurité sans en révéler l'exploit associé?
[^] # Re: Sécurité et confiance
Posté par Liorel . Évalué à 6.
Pour faire court, pas si le code source est public. La raison en est simple : si tu publies un patch, il suffit de lire le patch pour voir la vulnérabilité (ou même encore plus simple : tu appliques le patch, tu fais un diff "à l'envers" (en passant le code final en code intital et vice versa) et tu obtiens un patch qui implémente la vulnérabilité).
En pratique, ça peut être plus compliqué. Sur un projet complexe, si la vulnérabilité est elle-même complexe et le diff conséquent, ça peut être difficile de comprendre en quoi un logiciel est faillible. L'attaquant doit donc :
Le tout dans un temps limité puisqu'à chaque minute consacrée par l'attaquant à attaquer, ce sont des centaines de serveurs qui sont patchés (et donc le périmètre de l'attaque se réduit).
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Sécurité et confiance
Posté par Jiehong (site web personnel) . Évalué à 7.
Bon, je sors…
# Noyau
Posté par bubar🦥 (site web personnel) . Évalué à 10. Dernière modification le 17 novembre 2014 à 16:13.
Loin de ce commentaire l'idée de commenter ou juger le noyau, mais bien plus simplement de faire cette remarque :
C'est la démarche générale du noyau. Une faille de sécurité est un bug comme un autre. Et des bugs peuvent conduire à une faille de sécurité. Il n'y a donc pas de raison technique et organisationnelle pour traiter différement ce qui relève finalement d'une identification.
On peut dire, et sans (trop) capillotracter, que Microsoft vient de traiter un pb de sécu selon la méthode linux : ils ont patchés des bugs sans distinction. La question du closed vs open est un autre question.
On peut cependant mettre un petit bémol au sujet du noyau pusiqu'il y a maintenant une liste de diffusion dédiée à cela (et portée par openwall), mais cela concerne (il me semble, tu pourra confirmer ou contredire) des méthodes d'enquêtes qui divergent, entre la classique : examen de code source (classique et historique) et celle(s) dont les experts sécu ont l''habitude (fuzzing, examen de binaire, etc…) et dont tu avais parlé dans un excellent journal précédent (sur un sujet de décompilation et d'outillage). Là encore ce n'est pas tellement une histoire de traitement différent selon le type de bug, mais plutôt l'approche pour la recherche du bug, qui diffère.
Non ?
Mes deux centi-cents :-)
[^] # Re: Noyau
Posté par oinkoink_daotter . Évalué à 3. Dernière modification le 17 novembre 2014 à 19:05.
Ben si. Ce que tu expliques la est la méthode Linus. Le problème, c'est que quand tu fais ça, tu mets en porte à faux tous les gens qui ne peuvent pas patcher immédiatement. Style genre tu trouves un truc dans openssl, un patch sort, ben ptet qu'Ingénico (admettons qu'ils l'utilisent, ce qui n'est probablement pas le cas) va tester un peu le truc avant de télédistribuer la mise à jour aux terminaux de paiement. La gestion a la YOLO, ça va bien deux secondes. Sauf que pendant ce temps là, t'es à pwal. Tu n'as aucune méthode faisable de réduction de risque.
Donc désolé, mais pour beaucoup de monde, les bugs de sécus ne sont pas des bugs comme les autres.
Non, pas vraiment. Ils ont mélangé du bugfix avec des évols fonctionnelles (ajout de Cipher suites d'après le nourjal), ce qui est un cauchemar pour la gestion de conf et la maitrise de ton système (pour un indus, hein. Chez le particulier, on s'en fout).
[^] # Re: Noyau
Posté par xcomcmdr . Évalué à 4. Dernière modification le 17 novembre 2014 à 20:09.
Selon Linus, n'importe quel bug peut être un bug de sécurité, et je suis bien d'accord.
A partir de là "bug de sécurité" n'a pas vraiment de sens. Si tous les bugs sont potentiellement des bugs de sécurité (surtout en C…), alors ce sont tous des bugs de sécurité, et il sont alors tous tout autant importants.
CQFD.
Et puis ne pas distinguer les bugs "de sécurité" et les bugs "normaux" c'est indiquer les failles connues qu'on vient de patcher. Pas top pour la sécurité…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Noyau
Posté par xcomcmdr . Évalué à 4.
s/ne pas distinguer/distinguer (sinon ça n'a pas de sens)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Noyau
Posté par pasBill pasGates . Évalué à -3.
Il a totalement tort, et c'est incroyablement facile a demontrer. Tu prends la plupart des bugs corriges dans une release de kernel, et tu essayes de les detourner pour faire qqe chose de Mal(TM). Tu te rendras tres tres vite compte que pour la plupart c'est infaisable, n'a aucune valeur.
[^] # Re: Noyau
Posté par woprandi . Évalué à 2.
Tu démontres seulement qu'en réalité peu le sont.
[^] # Re: Noyau
Posté par pasBill pasGates . Évalué à 1.
Ben oui justement !
[^] # Re: Noyau
Posté par Lebas Sébastien . Évalué à 6. Dernière modification le 18 novembre 2014 à 13:52.
Euh non, il ne démontre rien du tout.
1/ Déjà, une affirmation lancée comme ça n'est pas une démonstration, quelle que soit la compétence de la personne qui la fait. Tu peut faire entièrement confiance à un grand spécialiste d'un domaine, par exemple, mais çà reste de la confiance, pas une démonstration
2/ Ensuite, le fait de ne rien trouver ne prouve … rien. Surtout pas la non existence de ce que tu cherches.
3/ Un bug non exploitable peut rendre (ou être rendu) exploitable par un autre bug, donc prendre les bugs isolément est de toutes façons une très mauvaise méthode …
[^] # Re: Noyau
Posté par barmic . Évalué à 3. Dernière modification le 18 novembre 2014 à 13:53.
Non, ceux dont l'aspect sécuritaire est mis en évidence sont plus importants que les autres (par exemple si un exploit est disponible). Tu remarquera que dans les bugs du noyau certains sont jugés suffisament graves pour que leurs corrections soient backportées. On est loin du "tous aussi importants". D'ailleurs le gestionnaire de bugs du noyau gère les priorités (et ils sont utilisés).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Noyau
Posté par khivapia . Évalué à 6. Dernière modification le 18 novembre 2014 à 11:04.
Sauf que pendant ce temps là, t'es à pwal.
Honnêtement, c'est un choix.
Pour les systèmes les plus exposés, la priorité doit aller à la sécurité au détriment, le cas échéant, de la disponibilité (puisque de toutes façons, une fois compromis la disponibilité n'est plus assurée non plus, et c'est toujours plus compliqué pour s'en débarrasser). Donc la pratique saine est de déployer le correctif de sécurité, en parallèle des tests pour sa validation qui fournira peut-être un deuxième patch dans la foulée, de fonctionnalités cette fois là. Ou alors c'est un choix assumé de laisser une faille ouverte sur un système exposé. On ne peut pas tout avoir !
En pratique, ça veut aussi dire que quand si le système est très exposé et critique, il faut faire des tests élaborés supplémentaires avant de déployer pour réduire encore plus la probabilité de découverte de failles (OpenBSD n'a connu que 2 exploits distants en 10 ans, c'est donc possible !), et ajouter de la variabilité dans le code déployé pour limiter la portée d'un exploit développé en vitesse.
Au final, déployer des programmes
bourrés de faillespeu testés d'un point de vue sécurité sur des systèmes très exposés et critiques est un choix qui coûte moins cher au déploiement, mais qui a des conséquences.# De la fumée sans feu
Posté par Kerro . Évalué à 9.
Tu pars du principe qu'il y a une énorme faille. Les précautions prises par Microsoft en sont un indice.
Je ne suis pas convaincu par les indices.
Microsoft indique une potentialité d'exécution de code, ça veut peut-être dire qu'ils ont vu un problème, qu'ils se disent qu'éventuellement ça pourrait autoriser de l'exécution, mais ils n'ont eux-même pas réussi (car il faut conjuguer plusieurs facteurs dans des cas extrêmes, ou tout simplement ce n'est pas possible).
Bref, ils corrigent peut-être simplement des bugs « normaux ». Ils ont fait des tests dans tous les sens, ce qui permet d'en profiter pour ajouter des fonctionnalités mineures. Quant aux plantages sur certaines configurations ce n'est pas un indice : il y a eu bien d'autres correctifs qui ont fichus la pagaille.
[^] # Re: De la fumée sans feu
Posté par pasBill pasGates . Évalué à 4.
Totalement correct.
Ils ont ici sorti le patch eux-meme tout simplement a cause de ce qu'est le bug : dans SSL donc touchant plein de systemes a distance, sans authentification necessaire. Ce bug posait un risque suffisant au public pour qu'ils le patchent de la maniere la plus rapide possible.
# Tu t'es avancé un peu trop vite
Posté par inico (site web personnel) . Évalué à 6.
Voici le reverse du patch: Triggering MS14-066
Tu peut parier qu'il y a des exploits privés qui sortiront dès qu'ils se seront fait avoir sur un honeypot :)
[^] # Re: Tu t'es avancé un peu trop vite
Posté par Zenitram (site web personnel) . Évalué à 3.
"November 17, 2014"
"Further analysis and exploitation are left as an exercise to the reader."
Merci de la démonstration inverse du titre de ton commentaire : le temps de réaction est justement le sujet!
[^] # Re: Tu t'es avancé un peu trop vite
Posté par reno . Évalué à 2.
1 semaine (MS14-066) vs 24h(Heartbleed), ça change beaucoup de choses!!
[^] # Re: Tu t'es avancé un peu trop vite
Posté par khivapia . Évalué à 2.
1 semaine (MS14-066) vs 24h(Heartbleed), ça change beaucoup de choses!!
Ça dépend de si MS14-066 connaissant les sources est aussi facile à exploiter qu'Heartbleed. Sinon ça veut juste dire qu'Heartbleed était une faille de plus grande importance.
# rira bien qui rira le dernier
Posté par yohann (site web personnel) . Évalué à 9.
Et oui on s'est pourtant bien moqué de lui à l'époque, mais 10 ans plus tard on prend enfin conscience qu'il avait raison:
ps: pour éviter que le troll ne soit trop flagrant nous ne révélerons pas l'identité de ce visionnaire.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.