le seul point de pénétration facile dans un système semble être via javascript exécuté dans un navigateur Web.

Et Flash? Java? Silverlight? VBA dans un document de bureau? Des applications qui chargent des pages Web à l'intérieur d'elles-mêmes?

Le fait est qu'une fois qu'une boîte a un code non autorisé en cours d'exécution, il est déjà compromis.

Avec du code sous votre compte utilisateur, beaucoup peut être fait. Mais compromis est un terme relatif. Vous ne pouvez pas par exemple installer un enregistreur de frappe de bas niveau. Les autorisations peuvent vous empêcher de lire l'espace mémoire d'autres applications même lorsqu'elles sont exécutées sous le même compte utilisateur. Et bien sûr, vous n'avez pas accès aux fichiers et aux processus exécutés sous d'autres comptes d'utilisateurs. Un utilisateur sur une machine d'entreprise ne pouvait pas détourner une autre session d'utilisateurs connectés.

Être capable de lire des valeurs de RAM arbitraires peut vous donner les jetons d'accès nécessaires pour vaincre tout cela.

Dans mon monde, appliquer des correctifs est une évidence. Nous allons le faire et il faut une exception pour NE PAS appliquer de patch.

Pour le moment, ce sont des exploits que nous connaissons pour Spectre et Meltdown. Cependant, comment garantir qu'il n'y en aura pas davantage? De plus, de nombreux exploits (tels que Wannacry / Petya) impliquent des systèmes qui ne sont pas corrigés pour ce problème connu.

Je terminerais avec cette pensée: êtes-vous prêt à miser votre réputation professionnelle sur non appliquer un correctif connu pour corriger une vulnérabilité connue? Cela ne me semble pas être un pari judicieux. Imaginez dans votre entreprise si un logiciel malveillant basé sur l'un de ces deux éléments pénètre dans votre réseau. L'une des premières questions de la direction est: comment est-ce arrivé? Savions-nous que c'était possible? Existait-il des mesures de prévention et si oui, les avons-nous appliquées? J'ai fait l'objet de ces questions basées sur les décisions de la direction d'accepter un risque de sécurité et ce n'était pas un endroit confortable pour être.

Pour répondre à votre question: non, ce n'est pas nécessaire. Mais ne pas le faire, l'OMI, est irresponsable.

Oui, car il peut être utilisé pour l'élévation de privilèges. Habituellement, si une attaque compromet un hôte, ils n'ont que des privilèges d'utilisateur. Grâce à cette vulnérabilité, ils peuvent augmenter les privilèges en divulguant leurs informations d'identification. L'escalade de privilèges est importante pour les attaquants pour la réalisation de nombreuses attaques, telles que l'usurpation d'arp, le relais SMB / LDAP, le détournement de jetons, le vidage d'informations d'identification, etc.

Installez les correctifs sauf si vous avez une très raison de ne pas le faire.

L'approche que vous décrivez peut se résumer comme suit:

Je connais l'exploit X. Je pourrais patcher mon système d'exploitation pour résoudre l'exploit X, ou je pourrais revoir attentivement chaque opération que je fais sur mon ordinateur (y compris les tâches de mise à jour automatisées effectuées pour moi). Si aucune de ces tâches ne présente de risque, alors je n'ai pas besoin d'installer le correctif.

Oui, en effet, votre logique est bonne. C'est la même logique qui dit "Un ordinateur qui est éteint et débranché est très résistant aux pirates." Cependant, cela vous demandera d'exister dans un état de vigilance continu. Chaque octet de code transféré sur votre ordinateur doit provenir d'une source fiable à 100%. Vous pouvez même fonctionner sur un réseau où cette logique est suffisamment solide. Mais vous ne l'êtes probablement pas, alors installez les correctifs. (Stuxnet peut être l'ultime exemple de ce qui se passe quand quelqu'un pense que son réseau n'est pas piratable)

Vous devrez rester dans cet état de vigilance continu pour toujours, ou du moins jusqu'à ce que vous vous atteliez et installiez les correctifs.

Comme Daniel Grover répond, considérez ceci comme un vecteur pour l'élévation de privilèges. La sécurité de nombreux systèmes dépend de l'hypothèse qu'un secret est, en fait, un secret. Meltdown / Spectre conteste cette hypothèse.

Sur les boîtiers Windows, est-ce que des correctifs pour Spectre et Meltdown sont nécessaires?

D'après ce que j'ai lu, Spectre et Meltdown nécessitent chacun un code non autorisé pour fonctionner sur une boîte Windows pour que les attaques aient lieu. Le fait est qu'une fois qu'une boîte a un code non autorisé en cours d'exécution, elle est déjà compromise.

Premièrement, cela ressemble beaucoup à ce que vous dites, pour éviter d'être piraté via Spectre ou Meltdown, vous devez juste éviter d'être piraté par quelque méthode que ce soit. Mais c'est une chose beaucoup plus difficile à faire!

Deuxièmement, comparez,

Dans une entreprise, est-il nécessaire de verrouiller le coffre-fort?

D'après ce que j'ai lu, voler des objets dans un coffre-fort nécessite qu'un voleur se trouve à l'intérieur du bâtiment. Le problème, c'est qu'une fois qu'un voleur est à l'intérieur du bâtiment, il est déjà compromis.

Bien sûr, mais en vous protégeant de certaines des choses que le voleur pourrait faire est toujours mieux que de lever les mains et de dire: "Eh bien, il est entré pour qu'il puisse tout prendre."

Le meilleur argument que j'ai vu pour les correctifs lorsqu'on me présente cette ligne de pensée est le suivant:

Détecter Spectre et Meltdown est très difficile et votre produit audiovisuel ne va pas arrêter ces attaques .

Ce sont des failles dans l'exécution spéculative du matériel (prédiction de branche, etc.). Votre processeur le fait toujours et la détection des utilisations malveillantes sera extrêmement difficile à faire. Toute la stratégie d'atténuation consiste donc à appliquer des correctifs, car la détection n'est pas envisageable.

Étant donné le nombre d'exploit PoC qui ont été développés et démontrés la semaine dernière (et juste à partir d'une idée de ce qu'étaient les bogues, avant la fin de l'embargo), je n'ai aucun doute sur le fait que des bogues existent.