Aller au contenu


Photo

Meltdown et Specter


  • Veuillez vous connecter pour répondre
Aucune réponse à ce sujet

Posté 09 janvier 2018 - 16:58

#1
cedsaill

cedsaill

    Sunriseur elite

  • Members
  • PipPipPipPip
  • 1 988 messages
Vous me direz que ce n ais pas en rapport a la ps4 mais qui sait !!
Interessent quand meme

offline rip of xlab js spectre exploit
xlab.tencent.com.zip
https://cdn.discorda...tencent.com.zip


https://www.exploit-...exploits/43427/

Les chercheurs en sécurité ont récemment découvert des problèmes de sécurité connus sous le nom de Meltdown and Specter . Ces problèmes s'appliquent à tous les processeurs modernes et permettent aux pirates d'accéder en lecture à des parties de la mémoire censées être secrètes. Pour lancer une attaque basée sur Spectre ou Meltdown, l'attaquant doit pouvoir exécuter du code sur le processeur de la victime. WebKit est affecté car, pour rendre des sites Web modernes, tout moteur JavaScript doit autoriser l'exécution de code JavaScript non fiable sur le processeur de l'utilisateur. Specter a un impact direct sur WebKit. La fusion a un impact sur WebKit car les propriétés de sécurité de WebKit doivent d'abord être ignorées (via Specter) avant que WebKit puisse être utilisé pour monter une attaque Meltdown.

WebKit s'appuie sur des instructions de branche pour appliquer ce que le code JavaScript et WebAssembly non fiable peut faire. Specter signifie qu'un attaquant peut contrôler des branches, donc les branches ne suffisent plus pour appliquer les propriétés de sécurité.
La fusion signifie que le code utilisateur, tel que JavaScript exécuté dans un navigateur Web, peut lire la mémoire du noyau. Tous les processeurs ne sont pas affectés par Meltdown et Meltdown est atténué par les changements du système d'exploitation. Monter une attaque Meltdown via JavaScript en cours d'exécution dans WebKit nécessite d'abord de contourner les contrôles de sécurité basés sur les branches, comme dans le cas d'une attaque Spectre. Par conséquent, les atténuations de spectre qui corrigent le problème de branche empêchent également un attaquant d'utiliser WebKit comme point de départ de Meltdown.

Ce document explique comment Specter et Meltdown affectent les mécanismes de sécurité WebKit existants et les correctifs à court et à long terme que WebKit déploie pour fournir une protection contre cette nouvelle classe d'attaques. La première de ces mesures d'atténuation expédiées le 8 janvier 2018:

iOS 11.2.2 .
High Sierra 10.13.2 Mise à jour supplémentaire . Ceci réutilise le numéro de version 10.13.2. Vous pouvez vérifier si votre Safari et WebKit sont corrigés en vérifiant le numéro de version complet dans A propos de Safari. Le numéro de version doit être 13604.4.7.1.6 ou 13604.4.7.10.6.
Safari 11.0.2 pour El Capitan et Sierra. Cela réutilise le numéro de version 11.0.2. Les versions corrigées sont 11604.4.7.1.6 (El Capitan) et 12604.4.7.1.6 (Sierra).
Spectre et contrôles de sécurité
Spectre signifie que les branches ne sont plus suffisantes pour appliquer les propriétés de sécurité des opérations de lecture dans WebKit. Le sous-système le plus impacté est JavaScriptCore (le moteur JavaScript de WebKit). Presque toutes les vérifications de limites peuvent être contournées pour lire arbitrairement hors des limites. Cela pourrait permettre à un attaquant de lire de la mémoire arbitraire. Toutes les vérifications de type sont également vulnérables. Par exemple, si un type contient un entier à l'offset 8 alors qu'un autre type contient un pointeur à l'offset 8, un attaquant pourrait utiliser Spectre pour contourner la vérification de type qui est supposée ne pas pouvoir utiliser l'entier pour créer un arbitraire aiguille.

JavaScriptCore est conçu pour être une machine virtuelle de langue sécurisée. Il devrait être possible de charger du code JavaScript ou WebAssembly non fiable dans votre processus sans risque de fuite de la mémoire de votre processus vers le code JavaScript, sauf dans les cas où vous exportez explicitement des données vers JavaScript via notre API de liaison C ou Objective-C. Specter casse cette propriété de JavaScriptCore car JavaScript ou WebAssembly non fiable a maintenant un chemin théorique pour lire tout l'espace d'adressage du processus hôte.

Les API DOM et les API système appelées par les API DOM utilisent également des branches pour appliquer leurs propriétés de sécurité, et celles-ci peuvent être appelées à partir de JavaScript. Par conséquent, Specter n'est pas seulement une attaque sur JavaScriptCore lui-même, mais aussi tout ce qui peut être appelé depuis JavaScript.

Raisonnement sur le spectre
Pour comprendre le fonctionnement de Spectre, il est utile de réfléchir à la façon dont les opérations de langage de programmation sensibles à la sécurité (comme tout accès aux propriétés dans JavaScript) sont exécutées dans JavaScriptCore sur un processeur moderne. La plupart des discussions sur Spectre ont impliqué des contrôles de limites, donc cette section considère également ce cas.

var tmp = intArray[index];
Dans cet exemple, supposons que intArraynotre moteur JavaScript sait que c'est une référence à une Int32Arrayinstance, mais que nous n'avons pas prouvé que cela indexest dans les limites de intArray.length. Le compilateur devra émettre une vérification des limites lorsqu'il convertit cette opération JavaScript de haut niveau en un formulaire de niveau inférieur:

if (((unsigned) index) >= ((unsigned) intArray->length))
fail;
int tmp = intArray->vector[index];
Compiler ceci sur les processeurs x86 conduit aux instructions suivantes:

mov 0x10(%rsi), %rdx ; %rsi has intArray. This loads
; intArray->vector.
cmp 0x18(%rsi), %ecx ; %ecx has the index. This compares
; the index to intArray->length.
jae Lfail ; Branch to Lfail if
; index >= intArray->length according
; to unsigned comparison.
mov (%rdx,%rcx,4), %ecx ; Load intArray->vector[index].
Les processeurs modernes sont capables d'exécuter la vérification des bornes branch ( jae) et load ( mov (%rdx,%rcx,4), %ecx) en parallèle. C'est possible parce que:

Les processeurs modernes profilent les branches. Dans ce cas, ils observeront que la branche tombe toujours à travers. C'est ce qu'on appelle la prédiction de branche .
Les processeurs modernes peuvent annuler l'exécution. La charge après la branche peut s'exécuter avant que la CPU ne vérifie que la branche a effectivement survécu. Si la branche s'avère être prise à la place, le CPU peut annuler tout ce qui s'est passé entre le moment où la branche a été rencontrée et quand elle a finalement été vérifiée. C'est ce qu'on appelle l' exécution spéculative .
Spectre est une attaque qui exploite les fuites d'informations de l'exécution spéculative. Considérez ce code:

var tmp = intArray[index];
otherArray[(tmp & 1) * 128];
Le processeur a la capacité d'initier des charges de la mémoire principale dans L1 (le cache mémoire de niveau 1 de la CPU, qui est le plus rapide et le plus petit) tout en s'exécutant de manière spéculative. En tant qu'optimisation des performances, le processeur ne supprime pas les extractions dans L1 lors de l'annulation de l'exécution spéculative. Cela conduit à une fuite d'informations basée sur le timing: dans ce code, si la CPU charge otherArray[0]ou otherArray[128]dépend tmp & 1, et il est possible de déterminer plus tard quelle CPU chargée de manière spéculative en chronométrant la vitesse d'accès à otherArray[0]et otherArray[128].

L'exemple jusqu'ici impliquait le contrôle d'une branche de vérification des bornes. C'est une attaque Spectre particulièrement efficace car elle indexse comporte comme un pointeur qui peut être utilisé pour lire ~ 16Go de mémoire ci-dessus intArray->vector. Mais Specter pourrait théoriquement impliquer n'importe quelle branche qui applique les propriétés de sécurité, comme les branches utilisées pour les contrôles de type dans JavaScriptCore.

Résumer:

Specter nécessite une synchronisation haute fidélité afin que la différence entre la latence L1 et la latence de la mémoire principale puisse être observée.
Spectre permet aux attaquants de contrôler les branches. L'exécution spéculative exécute des branches en fonction de l'histoire passée, et l'attaquant peut contrôler cet historique. Par conséquent, l'attaquant contrôle ce que les branches font pendant l'exécution spéculative.
Spectre est une course entre le vérificateur de branche et l'initiation de la charge de fuite d'informations (ce que nous avons écrit comme otherArray[(tmp & 1) * 128]ci-dessus). L'attaquant sait s'il a gagné la course (l'une des deux otherArraylignes de cache sera en L1), donc l'attaque fonctionne tant que les chances de gagner de l'attaquant ne sont pas nulles.
Spectre atténuant
La réponse de WebKit à Spectre est une défense à deux niveaux:

WebKit a désactivé SharedArrayBufferet réduit la précision de la minuterie.
WebKit passe à l'utilisation de la vérification de sécurité sans branchement en plus de la vérification de sécurité par branche.
Certains de ces changements ont été expédiés dans les mises à jour du 8 janvier et d'autres changements de ce type se poursuivent dans WebKit. Le reste de ce document couvre nos atténuations en détail.

Réduction de la précision du minuteur
Nous réduisons la précision du minuteur dans WebKit. Ces changements ont atterri dans le coffre à partir du r226495 et ils ont été expédiés dans les mises à jour du 8 janvier.

La précision du minuteur provenant d' performance.nowautres sources est réduite à 1 ms ( r226495 ).
Nous avons désactivé SharedArrayBuffer, car il peut être utilisé pour créer une minuterie haute résolution ( r226386 ).
Notre plan à long terme est de rendre Spectre impossible même en présence d'un timing de haute fidélité; des travaux supplémentaires sont nécessaires pour réactiver ce chemin.

Vérifications de sécurité sans branchement
Depuis que nous avons découvert Spectre, nous avons étudié comment effectuer des contrôles de sécurité sans dépendre de succursales. Nous avons commencé à faire la transition vers ce nouveau style de contrôles de sécurité et nous avons expédié les premiers chèques sans succursale dans les mises à jour du 8 janvier.

Masquage d'index
L'exemple le plus simple d'une vérification de sécurité sans branchement masque l'index d'un accès au tableau:

int tmp = intArray->vector[index & intArray->mask];
Les processeurs modernes ne spéculent pas sur le masquage de bits. Si le masque est choisi pour correspondre à la longueur du tableau, cette atténuation garantit que même avec Spectre, un attaquant ne peut pas lire les limites du tableau.

Nous avons implémenté le masquage d'index pour:

Tableaux typés ( r226461 ),
Mémoires WebAssembly ( r226461 , principalement via un code partagé avec des tableaux typés),
Cordes ( r226068 ),
WTF::Vector( r226068 ), et
Tableaux JavaScript simples ( r225913 ).
Modifications (1-4) fournies dans les mises à jour du 8 janvier. (5) a atterri dans WebKit mais n'a pas encore été expédié.

Le masquage d'index n'est pas encore une solution complète pour l'accès hors-limites. Nos atténuations de masquage d'index utilisent un masque qui est calculé en arrondissant la longueur à la puissance suivante de deux (et en en soustrayant une). Cela permet toujours de lire hors limites, mais pas dans la mémoire arbitraire.

Nos tests actuels indiquent que le masquage de l'indice n'a pas d'impact mesurable sur les tests du compteur de vitesse et de l'ARES-6 et un impact de moins de 2,5% sur le benchmark JetStream.

Empoisonnement de pointeur
Le masquage d'index est facile à appliquer pour les accès au tableau, mais de nombreuses branches de contrôle de sécurité concernent le type d'objet, pas les limites du tableau. L'empoisonnement par pointeur est une technique qui peut être utilisée pour sécuriser n'importe quel type sous Spectre en changeant la forme de l'objet soumis à la vérification.

Empoisonner un pointeur signifie simplement effectuer des calculs mathématiques réversibles qui feront échouer les tentatives d'accès à moins que le pointeur ne soit empoisonné. Dans WebKit, l'empoisonnement implique la sélection d'une valeur qui est sûre d'avoir au moins un bit placé dans des positions élevées afin que les accès qui ne sont pas unpoison sont très susceptibles d'atteindre la mémoire non mappée. WebKit choisit des valeurs de poison en utilisant un générateur de nombres aléatoires à la compilation avec beaucoup de règles subtiles, mais pour comprendre l'approche, il suffit de considérer 1 << 40comme une valeur de poison. L'ajout d'un téraoctet à un pointeur valide est sûr d'aboutir à un pointeur non mappé dans la disposition de la mémoire de WebKit sur macOS et iOS, et probablement sur d'autres systèmes d'exploitation. Il existe de nombreuses valeurs de poison possibles qui auraient cet effet.

L'empoisonnement devient plus puissant lorsque chaque déclaration statique d'un champ de pointeur a une valeur de poison unique, et les valeurs de poison diffèrent dans les bits élevés, de sorte que l'empoisonnement avec une valeur incorrecte entraîne un pointeur non mappé.

Pour illustrer comment appliquer l'empoisonnement du pointeur en tant que vérification de type sans branches, considérez une classe Fooappartenant à une hiérarchie de classes qui participent à des downcasts dynamiques en fonction de certaines vérifications:

class Foo : public Base {
public:
...
private:
int m_x;
Bar* m_y;
};
Afin de faire sonner les contrôles de type de cette classe sous Specter, nous pouvons simplement déplacer les champs de Foo dans une structure de données pointée par un pointeur empoisonné uniquement:

class Foo : public Base {
public:
....
private:
struct Data {
int x;
Bar* y;
};
ConstExprPoisoned<FooDataKey, Data> m_data;
};
Où FooDataKeyest une clé unique Foo, basée sur laquelle ConstExprPoisoned<>va calculer une valeur poison aléatoire à la compilation. Si toutes les classes de cette hiérarchie utilisent une indirection empoisonnée par un pointeur pour protéger leurs champs, cela suffit comme vérification de type sans branchement pour tous les accès à ces types. En plus d'être un excellent outil d'atténuation du spectre, il s'agit également d'une mesure d'atténuation de l'exécution de code à distance utile, car cela rend plus difficile toute confusion de type.

L'empoisonnement du pointeur ne nécessite parfois aucune indirection supplémentaire. JavaScriptCore a des tonnes de structures de données qui correspondent à peu près à ce modèle:

struct Thingy {
Type type;
void* data; // The shape of this depends on `type`.
};
Les contrôles de type d'une telle structure de données peuvent être rendus sans branchement en empoisonnant le datapointeur en fonction d'une valeur de poison qui en dépend type.

Nous avons commencé à convertir les modèles d'objet de WebKit pour utiliser l'empoisonnement de pointeur ( r225363 , rr225437 , r225632 , r225659 , r225697 , r225857 , r226015 , r226247 , r226344 , r226485 , r226530 ), et une partie du travail d'empoisonnement de pointeur est livrée dans les mises à jour du 8 janvier (spécifiquement, r225363 - r225857 ). Jusqu'à présent, nous n'avons observé aucune régression de performance à partir de l'empoisonnement par pointeur.

Atténuation de la fusion
Meltdown permet au code utilisateur de lire la mémoire du noyau. WebKit est indirectement affecté par Meltdown car une attaque Meltdown pourrait être lancée en utilisant n'importe quel type d'exécution de code, y compris JavaScript. Cependant, les accès mémoire utilisés pour effectuer Meltdown constitueraient une violation du modèle de sécurité de WebKit. Par conséquent, les attaques Meltdown basées sur JavaScript doivent d'abord utiliser Spectre pour contourner les contrôles de sécurité de WebKit.

La fusion a déjà été atténuée par les changements apportés au système d'exploitation . Par conséquent, même si WebKit ne disposait d'aucune protection Spectre, il ne devrait plus être possible de monter une attaque Meltdown via WebKit. Toutes les futures atténuations du Spectre rendront encore moins probable que WebKit puisse être utilisé pour une attaque de Meltdown, puisque l'étape Spectre de cette attaque sera plus difficile.

Recommandations pour les développeurs d'applications
Spectre signifie que les secrets dans le même espace d'adressage que le JavaScript non sécurisé sont plus vulnérables que jamais auparavant. Sur cette base, nous recommandons:

Passez à l' API WebKit moderne si vous ne l'avez pas déjà fait. Cela protège votre application en exécutant JavaScript non fiable dans un autre processus.
Évitez d'exposer des sources de synchronisation de haute précision à des fichiers JavaScript ou WebAssembly non fiables.
Conclusion
Specter et Meltdown sont une nouvelle classe de problèmes de sécurité qui s'appliquent aux processeurs modernes et au logiciel qui les exécute. WebKit est affecté par les deux problèmes car WebKit autorise l'exécution de code non fiable sur les processeurs des utilisateurs. En réponse à ces nouveaux problèmes, nous avons implémenté des atténuations pour se défendre contre Specter (et Meltdown par proxy, puisque vous avez besoin de Spectre pour faire Meltdown via le navigateur). La première de ces mesures d'atténuation a été intégrée aux mises à jour du 8 janvier (iOS 11.2.2, mise à jour supplémentaire de High Sierra 10.13.2 et réédition de Safari 11.0.2). Restez à l'écoute pour plus de correctifs WebKit Spectre!

https://webkit.org/b...ean-for-webkit/

Modifié par cedsaill, 09 janvier 2018 - 17:18.

  • Retour en haut




1 utilisateur(s) li(sen)t ce sujet

0 invité(s) et 1 utilisateur(s) anonyme(s)