S3 Ep112 : Les violations de données peuvent vous hanter plus d'une fois ! [Audio + Texte]

Horodatage: 9 décembre 2022 11h46
Nœud source: 1769637
by

VIOLATIONS DE DONNÉES – LA PIQUE DANS LA QUEUE

Cliquez et faites glisser sur les ondes sonores ci-dessous pour passer à n'importe quel point. Vous pouvez également écouter directement sur Soundcloud.

Avec Doug Aamoth et Paul Ducklin. Musique d'intro et d'outro par Edith Mud.

Vous pouvez nous écouter sur Soundcloud, Podcasts Apple, Podcasts Google, Spotify, piqueur et partout où l'on trouve de bons podcasts. Ou déposez simplement le URL de notre flux RSS dans votre podcatcher préféré.

LIRE LA TRANSCRIPTION

DOUG.  Échange de carte SIM, zero-days, le [voix dramatique] Ping of DEATH et LastPass… encore une fois.

Tout cela, et plus encore, sur le podcast Naked Security.

[MODÈME MUSICAL]

Bienvenue sur le podcast tout le monde.

Je suis Doug Aamoth.

Avec moi, comme toujours, Paul Ducklin.

Paul, comment vas-tu ?

CANARD.  Très bien, Doug.

Vous avez mis un son dramatique dans cette intro, je suis ravi de voir !

DOUG.  Eh bien, comment dire "Ping of Death" sans dire [doom metal growl] "Ping of DEATH" ?

Vous ne pouvez pas simplement dire [voix douce] "Ping of Death".

Il faut taper un peu...

CANARD.  Je suppose.

C'est différent à l'écrit – qu'avez-vous ?

Gras et italique.

Je suis juste allé avec du texte normal, mais j'ai utilisé des majuscules, ce qui aide.

DOUG.  Oui, je pense que je mettrais en gras et en italique le mot "death", donc [doom metal again] "The Ping of DEATH".

CANARD.  Et utilisez plusieurs couleurs !

Je ferai ça la prochaine fois, Doug.

DOUG.  Sortez l'ancien tag en HTML, faites-le clignoter un peu ? [DES RIRES]

CANARD.  Doug, pendant un moment, j'ai eu peur que tu utilises le mot [RIRES] .

DOUG.  [RIRES] Nous aimons les vieux trucs ici !

Et cela cadre bien avec notre Cette semaine dans l'histoire de la technologie segment - Je suis enthousiasmé par celui-ci parce que je n'en avais pas entendu parler, mais je suis tombé dessus.

Cette semaine, le 04 décembre 2001, le ver Goner a saccagé Internet à un rythme qui n'a dépassé que celui du virus Love Bug.

Goner s'est propagé via Microsoft Outlook et a promis aux victimes sans méfiance un économiseur d'écran amusant lors de son exécution.

CANARD.  Fini…

Je pense qu'il a reçu ce nom parce qu'il y avait un popup à la fin, n'est-ce pas, qui mentionnait le Pentagone ?

Mais c'était censé être un jeu de mots - c'était "Penta / Gone".

C'est certainement le ver qui a rappelé aux gens qu'en fait, les économiseurs d'écran Windows ne sont que des programmes exécutables.

Donc, si vous recherchiez spécialement .EXE fichiers, eh bien, ils pourraient être enveloppés dans .SCR (économiseur d'écran) également.

Si vous ne comptiez que sur les noms de fichiers, vous pourriez facilement être trompé.

Et beaucoup de gens l'étaient, malheureusement.

DOUG.  Très bien, nous allons passer de la vieille école à la nouvelle école.

On parle de LastPass : il y a eu une brèche ; la brèche elle-même n'était pas terrible ; mais cette brèche a maintenant conduit à une autre brèche.

Ou peut-être s'agit-il simplement d'une continuation de la violation d'origine ?

LastPass admet la violation des données client causée par une violation précédente

CANARD.  Oui, LastPass a écrit à ce sujet essentiellement dans le cadre d'un suivi de la violation précédente, qui, je pense, était d'août 2022, n'est-ce pas ?

Et comme nous l'avons dit à l'époque, c'était un look très embarrassant pour LastPass.

Mais au fur et à mesure des violations, c'était probablement pire pour leurs relations publiques, leur marketing et (je suppose) pour leurs départements de propriété intellectuelle, car il semble que la principale chose que les escrocs ont supprimée était le code source de leur système de développement.

Et LastPass n'a pas tardé à rassurer les gens…

Premièrement, leurs enquêtes ont suggéré que, pendant qu'ils étaient là-dedans, les escrocs n'étaient pas en mesure d'apporter des modifications non autorisées qui pourraient ensuite s'infiltrer dans le code réel.

Deuxièmement, l'accès au système de développement ne vous donne pas accès au système de production, où le code réel est construit.

Et troisièmement, ils ont pu dire qu'il semblait qu'aucun coffre-fort de mots de passe cryptés n'avait été volé, de sorte que le stockage en nuage de vos mots de passe cryptés n'était pas accessible.

Et même s'il y avait été accédé, alors vous seul connaîtriez le mot de passe, car le décryptage (ce que vous avez appelé le "gros travail" quand nous en avons parlé sur le podcast) se fait en réalité en mémoire sur vos appareils - LastPass ne voit jamais votre le mot de passe.

Et puis, quatrièmement, ils ont dit, pour autant que nous puissions en juger, à la suite de cette violation, certaines des choses qui se trouvaient dans l'environnement de développement ont maintenant donné soit la même chose… soit peut-être une charge complètement différente d'escrocs qui ont acheté le données volées du lot précédent, qui sait ?

Cela leur a permis d'accéder à un service cloud où un ensemble de données client encore apparemment inconnu a été volé.

Je ne pense pas qu'ils le sachent encore très bien, car cela peut prendre un certain temps pour déterminer ce qui a réellement été consulté après qu'une violation s'est produite.

Je pense donc qu'il est juste de dire que c'est en quelque sorte le côté B de la violation d'origine.

DOUG.  Très bien, nous suggérons que si vous êtes un client LastPass, gardez un œil sur le rapport d'incident de sécurité de l'entreprise.

Nous garderons un œil sur cette histoire car elle est encore en développement.

Et si vous, comme Paul et moi, combattez la cybercriminalité pour gagner votre vie, il y a d'excellentes leçons à tirer de la violation d'Uber.

C'est donc un épisode de podcast - un "minisode" - avec Chester Wisniewski que Paul a intégré au bas de l'article LastPass :

S3 Ep100.5 : Violation d'Uber – un expert parle [Audio + Texte]

Beaucoup à apprendre sur ce front !

CANARD.  Comme vous le dites, c'est une excellente écoute, car c'est, je crois, ce que l'on appelle en Amérique des "conseils exploitables", ou des "informations que vous pouvez utiliser".

DOUG.  [RIRES] Merveilleux.

En parlant de nouvelles que vous ne pouvez pas vraiment utiliser, Apple est généralement discret sur ses mises à jour de sécurité… et il y a eu une mise à jour de sécurité :

Apple publie une mise à jour de sécurité iOS plus discrète que jamais

CANARD.  Oh, Doug, c'est l'un de tes meilleurs... J'aime cette suite.

DOUG.  [RIRES] Merci ; merci beaucoup.

CANARD.  Oui, cela m'a surpris.

J'ai pensé: "Eh bien, je vais prendre la mise à jour parce que ça a l'air sérieux."

Et je me suis donné la raison, "Laissez-moi le faire pour les lecteurs de Naked Security."

Parce que si je le fais et qu'il n'y a pas d'effets secondaires, alors je peux au moins dire aux autres : « Écoutez, je l'ai fait aveuglément et aucun mal ne m'est arrivé. Alors peut-être que vous pouvez le faire aussi.

J'ai tout à coup remarqué qu'une mise à jour iOS 16.1.2 était disponible, même si je n'avais reçu aucun e-mail d'avis de sécurité d'Apple.

Pas d'e-mail ? !

C'est bizarre.. alors je suis allé au HT201222 page de portail qu'Apple a pour ses bulletins de sécurité, et voilà : iOS 16.1.2.

Et que dit-il, Doug, "Les détails suivront bientôt" ?

DOUG.  Et ont-ils suivi bientôt?

CANARD.  Eh bien, c'était il y a plus d'une semaine, et ils n'y sont pas encore.

Parlons-nous donc de « bientôt » signifiant des heures, des jours, des semaines ou des mois ?

Pour le moment, cela ressemble à des semaines.

Et, comme toujours avec Apple, rien n'indique quoi que ce soit à voir avec d'autres systèmes d'exploitation.

Ont-ils été oubliés ?

N'ont-ils pas besoin de la mise à jour ?

Avaient-ils également besoin de la mise à jour, mais elle n'est tout simplement pas encore prête ?

Ont-ils été retirés de l'assistance ?

Mais cela semblait, comme je l'ai dit dans le titre, encore plus discret que d'habitude pour Apple, et pas nécessairement la chose la plus utile au monde.

DOUG.  OK, très bien… encore quelques questions, ce qui nous amène à notre prochaine histoire.

Une question très intéressante !

Parfois, lorsque vous vous inscrivez à un service et qu'il applique une authentification à deux facteurs, il est écrit : "Voulez-vous être averti par SMS ou souhaitez-vous utiliser une application d'authentification ?"

Et cette histoire est un avertissement pour ne pas utiliser votre téléphone - utilisez une application d'authentification, même si c'est un peu plus lourd.

C'est une histoire très intéressante :

Un échangeur de carte SIM envoyé en prison pour un braquage de crypto-monnaie 2FA de plus de 20 millions de dollars

CANARD.  C'est ça, Doug !

S'il vous est déjà arrivé de perdre un téléphone portable, ou de vous être bloqué sur votre carte SIM en saisissant trop souvent le code PIN incorrect, vous saurez que vous pouvez vous rendre dans la boutique de téléphonie mobile…

… et généralement, ils demandent une pièce d'identité ou quelque chose du genre, et vous dites : « Hé, j'ai besoin d'une nouvelle carte SIM.

Et ils en généreront un pour vous.

Quand vous le mettez dans votre téléphone, bingo !… il y a votre ancien numéro dessus.

Donc, cela signifie que si un escroc peut passer par le même exercice que vous feriez pour convaincre la compagnie de téléphonie mobile qu'il a "perdu" ou "cassé" sa carte SIM (c'est-à-dire *votre carte SIM*), et qu'il peut obtenir cette carte soit remise, soit envoyée, soit donnée d'une manière ou d'une autre…

… puis, lorsqu'ils le branchent sur leur téléphone, ils commencent à recevoir vos codes d'authentification à deux facteurs par SMS, *et* votre téléphone cesse de fonctionner.

C'est la mauvaise nouvelle.

La bonne nouvelle dans cet article est qu'il s'agissait d'un cas d'un type qui s'est fait arrêter pour cela.

Il a été envoyé en prison aux États-Unis pendant 18 mois.

Lui, avec une bande de complices – ou, selon les termes du ministère de la Justice, le Participants au programme… [DES RIRES]

… ils se sont enfuis avec la crypto-monnaie d'une victime en particulier, apparemment à hauteur de 20 millions de dollars, si cela ne vous dérange pas.

DOUG.  Ouf !

CANARD.  Il a donc accepté de plaider coupable, de prendre une peine de prison et de renoncer immédiatement… le montant était [en lisant attentivement] 983,010.72 XNUMX $… juste pour perdre cela tout de suite.

Donc, vraisemblablement, il avait ça qui traînait.

Et il a apparemment aussi une sorte d'obligation légale de rembourser plus de 20 millions de dollars.

DOUG.  Bonne chance avec ça, tout le monde! Bonne chance.

Ses autres [vocaux en italique] Participants au programme pourrait causer des problèmes là-bas! [DES RIRES]

CANARD.  Oui, je ne sais pas ce qui se passe s'ils refusent de coopérer également.

Comme, s'ils le suspendent juste pour qu'il sèche, que se passe-t-il ?

Mais nous avons quelques astuces et des conseils sur la façon de renforcer la sécurité (en plus du simple 2FA que vous utilisez) dans l'article.

Alors allez lire ça… chaque petit geste compte.

DOUG.  OK, en parlant de "petits morceaux"…

…c'était une autre histoire fascinante, comment les humbles ping peut être utilisé pour déclencher l'exécution de code à distance :

Ping de la mort ! FreeBSD corrige un bogue crashtastic dans l'outil réseau

CANARD.  [J'aime encore la suite] Je pense que tu t'es amélioré, Doug !

DOUG.  [RIRES] J'ai le vent en poupe aujourd'hui…

CANARD.  D'Apple à la [faible tentative de chant doom] Ping of DEATH !

Oui, c'était un bug intrigant.

Je ne pense pas que cela causera beaucoup de mal à beaucoup de gens, et il * est * patché, donc il est facile de le réparer.

Mais il y a un excellent article dans FreeBSD avis de sécurité...

… et cela en fait un récit divertissant et, si je le dis moi-même, très instructif pour la génération actuelle de programmeurs sur laquelle s'est peut-être appuyée « Les bibliothèques tierces le feront pour moi. Vous avez affaire à des paquets réseau de bas niveau ? Je n'ai jamais à y penser..."

Il y a de grandes leçons à tirer ici.

La ping L'utilitaire, qui est le seul outil réseau que presque tout le monde connaît, tire son nom de SONAR.

Tu vas [fait du bruit sous-marin de film] ping, puis l'écho revient du serveur à l'autre bout.

Et c'est une fonctionnalité qui est intégrée au protocole Internet, IP, en utilisant une chose appelée ICMP, qui est Internet Control Message Protocol.

C'est un protocole spécial de bas niveau, bien inférieur à UDP ou TCP auquel les gens sont probablement habitués, qui est à peu près conçu exactement pour ce genre de chose : votre serveur Web ne fonctionne pas ? »

Il existe un type spécial de paquet que vous pouvez envoyer appelé "ICMP Echo".

Donc, vous envoyez ce tout petit paquet contenant un court message (le message peut être ce que vous voulez), et il vous renvoie simplement ce même message.

C'est juste une façon basique de dire : « Si ce message ne revient pas, soit le réseau soit tout le serveur est en panne », plutôt qu'il y a un problème logiciel sur l'ordinateur.

Par analogie avec SONAR, le programme qui envoie ces requêtes d'écho s'appelle… [pause] Je vais faire le bruitage, Doug… [fake submarine movie noise again] ping. [RIRE]

Et l'idée est, vous allez dire, ping -c3 (cela signifie vérifier trois fois) nakedsecurity.sophos.com.

Vous pouvez le faire dès maintenant, et vous devriez obtenir trois réponses, chacune à une seconde d'intervalle, des serveurs WordPress qui hébergent notre site.

Et c'est dire que le site est vivant.

Il ne vous dit pas que le serveur Web est opérationnel ; il ne vous dit pas que WordPress est en place ; cela ne dit pas que Naked Security est réellement disponible pour la lecture.

Mais cela au moins confirme que vous pouvez voir le serveur et que le serveur peut vous joindre.

Et qui aurait pensé que cette humble petite réponse ping pourrait faire trébucher FreeBSD ping programme de telle sorte qu'un serveur malveillant puisse renvoyer un message piégé "Oui, je suis vivant" qui pourrait, en théorie (en théorie seulement ; je ne pense pas que quelqu'un l'ait fait en pratique) déclencher l'exécution de code à distance sur ton ordinateur.

DOUG.  Oui, c'est incroyable; c'est la partie incroyable.

Même si c'est une preuve de concept, c'est une si petite chose !

CANARD.  La ping programme lui-même récupère l'intégralité du paquet IP, et il est censé le diviser en deux parties.

Normalement, le noyau gèrerait cela pour vous, donc vous ne verriez que la partie données.

Mais quand vous avez affaire à ce qu'on appelle douilles brutes, ce que vous obtenez en retour est l'en-tête du protocole Internet, qui dit simplement : "Hé, ces octets proviennent de tel ou tel serveur".

Et puis vous obtenez une chose appelée "ICMP Echo Reply", qui est la seconde moitié du paquet que vous récupérez.

Maintenant, ces paquets ne font généralement que 100 octets environ, et s'il s'agit d'IPv4, les 20 premiers octets sont l'en-tête IP et le reste, quel qu'il soit, est la réponse d'écho.

Cela a quelques octets pour dire "Ceci est une réponse d'écho", puis le message d'origine qui est revenu.

Et donc la chose évidente à faire, Doug, quand vous l'obtenez, c'est de le diviser en...

… l'en-tête IP, qui fait 20 octets de long, et le reste.

Devinez où se situe le problème ?

DOUG.  Dites-le !

CANARD.  Le problème est que les en-têtes IP font *presque toujours* 20 octets de long - en fait, je ne pense pas en avoir jamais vu un qui ne l'était pas.

Et vous pouvez dire qu'ils font 20 octets car le premier octet sera hexadécimal 0x45.

Le « 4 » signifie IPv4, et le « 5 »… « Oh, nous allons l'utiliser pour indiquer la longueur de l'en-tête. »

Vous prenez ce nombre 5 et vous le multipliez par 4 (pour les valeurs 32 bits), et vous obtenez 20 octets.

… et c'est probablement la taille de six sigma d'en-têtes IP que vous ne verrez jamais dans le monde entier, Doug. [RIRE]

Mais ils *peuvent* aller jusqu'à 60 octets.

Si vous mettez 0x4F au lieu de 0x45, cela signifie qu'il y a 0xF (ou 15 en décimal) × 4 = 60 octets dans l'en-tête.

Et le code FreeBSD a simplement pris cet en-tête et l'a copié dans un tampon sur la pile d'une taille de 20 octets.

Un simple débordement de tampon de pile à l'ancienne.

Il s'agit d'un vénérable outil de dépannage réseau avec un type vénérable de bogue. (Eh bien, plus maintenant.)

Ainsi, lorsque vous programmez et que vous devez gérer des choses de bas niveau auxquelles personne n'a vraiment pensé depuis des lustres, ne vous contentez pas de suivre la sagesse reçue qui dit : « Oh, ce sera toujours 20 octets ; vous ne verrez jamais rien de plus grand.

Parce qu'un jour tu pourrais.

Et quand ce jour viendra, il pourrait être là délibérément parce qu'un escroc l'a fait exprès.

Alors le diable, comme toujours, est dans les détails de la programmation, Doug.

DOUG.  D'accord, très intéressant ; grande histoire.

Et nous nous en tiendrons au sujet du code avec cette dernière histoire sur Chrome.

Un autre jour zéro, qui porte le total de 2022 à neuf fois :

Numéro neuf! Chrome corrige un autre zero-day 2022, Edge également corrigé

CANARD.  [Voix formelle, ressemblant à un enregistrement] "Numéro 9. Numéro 9. Numéro 9, numéro 9", Douglas.

DOUG.  [RIRES] Est-ce Yoko Ono ?

CANARD.  Passer du temps au contact de la nature au quotidien augmente notre bien être. Les bénéfices sont physiques et mentaux. Réaliser des activités comme le jardinage, faire de l'exercice en extérieur ou être entouré d'animaux ont de nombreux effets positifs. Révolution 9 extrait du "White Album" des Beatles.

On peut entendre Yoko riffer dans cette chanson - ça paysage sonore, je crois qu'ils l'appellent - mais apparemment le morceau au début où il y a quelqu'un qui dit "Numéro 9, numéro 9" encore et encore, c'était, en fait, une bande de test qu'ils ont trouvée qui traînait.

DOUG.  Ah, très cool.

CANARD.  Un ingénieur EMI disant quelque chose comme "Ceci est la bande de test EMI numéro 9" [RIRES], et apparemment je ne pense même pas que quiconque sache de qui il s'agissait.

Cela n'a *rien* à voir avec Chrome, Doug.

Mais étant donné que quelqu'un a commenté sur Facebook l'autre jour, "Ce type de Paul commence à ressembler à un Beatle"… [interrogateur] ce que j'ai trouvé un peu étrange.

DOUG.  [RIRES] Oui, comment êtes-vous censé prendre ça ?

CANARD.  … J'ai pensé que je pourrais dîner au « Numéro 9 ».

C'est le neuvième jour zéro de l'année jusqu'à présent, semble-t-il, Doug.

Et c'est une correction d'un bogue, avec le bogue identifié comme CVE 2022-4282.

Parce que Microsoft Edge utilise le noyau open source Chromium, il était également vulnérable, et quelques jours plus tard, Microsoft a suivi avec une mise à jour pour Edge.

Il s'agit donc à la fois d'un problème Chrome et Edge.

Bien que ces navigateurs doivent se mettre à jour, je vous recommande de vérifier quand même - nous vous montrons comment faire cela dans l'article - juste au cas où.

Je ne lirai pas les numéros de version ici car ils sont différents pour Mac, Linux et Windows sur Chrome, et ils sont à nouveau différents pour Edge.

Comme Apple, Google est un peu discret à ce sujet.

Il a été trouvé par l'un de leur équipe de chasse aux menaces, je crois.

J'imagine donc qu'ils l'ont trouvé en enquêtant sur un incident qui s'est produit dans la nature, et donc ils veulent probablement le garder sous leur chapeau, même si Google a généralement beaucoup à dire sur "l'ouverture" en matière de correction de bogues.

Vous pouvez voir pourquoi, dans un cas comme celui-ci, vous voudrez peut-être un peu de temps pour creuser un peu plus avant de dire à tout le monde exactement comment cela fonctionne.

DOUG.  Excellent… et nous avons une question de lecteur qui est probablement une question à laquelle beaucoup de gens pensent.

Cassandra demande : « Est-ce que les chercheurs de bogues ont juste de la chance de trouver des bogues ? Ou ont-ils touché une « couture » pleine de bugs ? Ou Chromium publie-t-il un nouveau code qui est plus bogué que la normale ? Ou est-ce qu'il se passe autre chose ?

CANARD.  Oui, c'est une excellente question, en fait, et j'ai bien peur de ne pouvoir y répondre que d'une manière un peu facétieuse, Doug.

Parce que Cassandra avait donné les choix A), B) et C), j'ai dit: "Eh bien, peut-être que c'est Tout ce qui précède. »

Nous savons que lorsqu'un bogue d'un type particulier apparaît dans le code, il est raisonnable de supposer que le même programmeur peut avoir créé des bogues similaires ailleurs dans le logiciel.

Ou d'autres programmeurs de la même entreprise ont peut-être utilisé ce qui était considéré comme une sagesse reçue ou une pratique courante à l'époque, et ont peut-être emboîté le pas.

Et un bon exemple est, si vous regardez en arrière à Log4J… il y avait un correctif pour corriger le problème.

Et puis, quand ils sont allés chercher, "Oh, en fait, il y a d'autres endroits où des erreurs similaires ont été commises."

Il y avait donc un correctif pour le correctif, puis il y avait un correctif pour le correctif pour le correctif, si je me souviens bien.

Il y a, bien sûr, aussi le problème que lorsque vous ajoutez un nouveau code, vous pouvez avoir des bogues qui sont uniques à ce nouveau code et qui surviennent en raison de l'ajout de fonctionnalités.

Et c'est pourquoi de nombreux navigateurs, y compris Chrome, ont une version "légèrement plus ancienne" que vous pouvez conserver.

Et l'idée est que ces versions "plus anciennes"… elles n'ont aucune des nouvelles fonctionnalités, mais tous les correctifs de sécurité pertinents.

Donc, si vous voulez être prudent sur les nouvelles fonctionnalités, vous pouvez l'être.

Mais nous savons certainement que, parfois, lorsque vous insérez de nouvelles fonctionnalités dans un produit, de nouveaux bogues accompagnent les nouvelles fonctionnalités.

Et vous pouvez le dire, par exemple, lorsqu'il y a une mise à jour, par exemple, pour votre iPhone, et que vous obtenez des mises à jour, par exemple, pour iOS 15 et iOS 16.

Ensuite, lorsque vous regardez les listes de bogues, il y a peu de bogues qui ne s'appliquent qu'à iOS 16.

Et vous pensez, "Bonjour, ce doivent être des bogues dans le code qui n'étaient pas là avant."

Donc, oui, c'est une possibilité.

Et je pense que les autres choses qui se passent peuvent être considérées comme bonnes.

La première est que je pense que, en particulier pour des choses comme les navigateurs, les fabricants de navigateurs sont de mieux en mieux capables de proposer des reconstructions complètes très, très rapidement.

DOUG.  Intéressant.

CANARD.  Et je pense que l'autre chose qui a changé est que, dans le passé, vous pouviez dire que pour de nombreux fournisseurs... il était assez difficile d'amener les gens à appliquer des correctifs, même lorsqu'ils ne sortaient que sur un calendrier mensuel, et même si ils contenaient plusieurs correctifs zero-day.

Je pense que c'est peut-être aussi une réponse au fait que de plus en plus d'entre nous sont de plus en plus susceptibles non seulement d'accepter, mais en fait de *s'attendre* à une mise à jour automatique qui est vraiment rapide.

Donc, je pense que vous pouvez lire de bonnes choses là-dedans.

Le fait non seulement que Google peut proposer un seul correctif zero-day presque instantanément, mais aussi que les gens sont prêts à l'accepter et même à l'exiger.

J'aime donc voir ce problème de "Wow, neuf jours zéro dans l'année fixés individuellement!"…

… J'aime penser à cela plus comme "le verre à moitié rempli et se remplissant" que "le verre à moitié vide et s'écoulant par un petit trou au fond". [RIRE]

C'est mon avis.

DOUG.  D'accord, très bien.

Merci pour la question, Cassandre.

Si vous avez une histoire intéressante, un commentaire ou une question que vous aimeriez soumettre, nous serions ravis de le lire sur le podcast.

Vous pouvez envoyer un e-mail à tips@sophos.com, commenter n'importe lequel de nos articles ou nous contacter sur les réseaux sociaux : @NakedSecurity.

C'est notre émission d'aujourd'hui; merci beaucoup pour votre écoute.

Pour Paul Ducklin, je m'appelle Doug Aamoth, je vous rappelle : à la prochaine fois…

TOUS LES DEUX.  Restez en sécurité!

[MODÈME MUSICAL]

Horodatage:

Plus de Sécurité nue