1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Les ingénieurs de Calif ont créé un exploit de corruption mémoire du noyau macOS fonctionnant sur Apple M5 et ont remis à Apple un rapport de recherche sur la vulnérabilité
  • La chaîne d’exploitation cible du matériel M5 bare metal avec MIE activé, et l’ensemble des détails techniques sera publié après le correctif d’Apple
  • La cible est macOS 26.4.1 (25E253), et un utilisateur local non privilégié peut atteindre un shell root en n’utilisant que des appels système ordinaires
  • L’implémentation utilise deux vulnérabilités et plusieurs techniques, et Calif considère qu’il s’agit du premier exploit public du noyau macOS sur matériel MIE
  • Mythos Preview a aidé à identifier les bugs et à développer l’exploit, mais contourner de nouvelles mitigations comme MIE nécessite encore des experts humains

Exploit du noyau macOS qui a franchi le MIE du M5

  • Les ingénieurs de Calif, avec l’aide de Mythos Preview, ont créé un exploit de corruption mémoire du noyau macOS fonctionnant sur le silicium Apple M5, puis ont remis en main propre à Apple un rapport de recherche sur la vulnérabilité à Apple Park
  • Cette chaîne cible du matériel M5 bare metal avec MIE(Memory Integrity Enforcement) activé
  • La cible est macOS 26.4.1 (25E253), et il s’agit d’une chaîne d’élévation locale de privilèges au niveau du noyau, uniquement fondée sur les données, qui part d’un utilisateur local non privilégié, n’utilise que des appels système ordinaires et se termine par un shell root
  • L’implémentation comprend deux vulnérabilités et plusieurs techniques, et un rapport de 55 pages avec l’ensemble des détails techniques sera publié après qu’Apple aura corrigé les vulnérabilités et le chemin d’attaque
  • Le calendrier a progressé rapidement
    • Bruce Dang a découvert le bug le 25 avril
    • Dion Blazakis a rejoint Calif le 27 avril
    • Josh Maine a créé les outils, et un exploit fonctionnel a été finalisé le 1er mai

Signification de MIE et de Mythos Preview

  • La corruption mémoire reste le type de vulnérabilité le plus courant, y compris sur iOS et macOS, et si elle ne peut pas être totalement éliminée, des mitigations capables d’augmenter le coût d’une attaque sont nécessaires
  • Apple a intégré de nombreuses fonctions de défense dans le matériel en tenant compte à la fois des performances et de la sécurité, et a accru la difficulté des contournements en contrôlant l’ensemble de la pile
  • MIE est un système de sûreté mémoire avec support matériel basé sur le MTE (Memory Tagging Extension) d’ARM, introduit comme fonctionnalité de sécurité majeure de l’Apple M5 et de l’A19
  • Selon les recherches d’Apple, MIE perturbe toutes les chaînes d’exploitation publiques visant l’iOS moderne, y compris les kits d’exploit récemment divulgués Coruna et Darksword
  • Calif explore depuis un certain temps comment l’IA peut contribuer à construire des exploits qui fonctionnent aussi dans des environnements MTE, et comme le MIE d’Apple, centré sur iOS, s’applique aussi au M5 des MacBook récents, une voie d’attaque sur macOS devient possible
  • Mythos Preview a aidé à l’identification des bugs et à l’ensemble du développement de l’exploit, et peut déjà généraliser à des problèmes presque identiques parmi les types de problèmes qu’il a appris
  • Si Mythos a trouvé rapidement les bugs, c’est parce qu’ils appartenaient à des catégories déjà connues ; contourner de manière autonome une mitigation de tout premier plan et nouvelle comme MIE reste encore du domaine des experts humains
  • Calif a testé l’étendue de ce qui est possible lorsque des modèles de tout premier plan sont combinés à des experts, et cette combinaison a permis de finaliser en une semaine un exploit de corruption mémoire du noyau contre des protections de très haut niveau
  • MIE n’est pas un dispositif conçu pour arrêter complètement les hackers, et il peut être contourné en présence de vulnérabilités appropriées
  • Dans la série MAD Bugs, Calif estime que les systèmes d’IA découvrent de plus en plus de vulnérabilités, dont certaines pourraient devenir assez puissantes pour franchir des mitigations avancées comme MIE
  • Lorsque Apple a conçu MIE, des environnements comme Mythos Preview n’existaient pas, et ce travail constitue un premier résultat montrant la pression exercée par la découverte de bugs fondée sur l’IA sur les techniques de mitigation avancées

1 commentaires

 
GN⁺ 4 시간 전
Avis Hacker News
  • À voir uniquement la démo, cela ressemble à une vulnérabilité à 100 000 dollars sur la plateforme de bug bounty d’Apple, mais avec un bon emballage, cela pourrait peut-être devenir une vulnérabilité à 1,5 million de dollars
    Il suffirait de la reproduire sur une version bêta de macOS, de la qualifier d’accès non autorisé et, si possible, de la montrer aussi en mode verrouillage

    • Cela ressemble à une élévation locale de privilèges (LPE), alors que ce qui est décrit plus haut se rapproche d’une exécution de code à distance sans clic (RCE)
  • On a l’impression que le monde n’était absolument pas préparé à l’impact des LLM sur les questions de sécurité
    Si c’est réel, bravo à l’équipe de Calif, et même si les détails sont trop techniques pour que je comprenne tout, j’attends avec impatience le rapport de 55 pages

    • Je suis d’accord aussi, mais ce qui m’inquiète, ce sont les gens
      J’entends partout que des développeurs poussent en production des modifications de code générées par des LLM sans vraiment comprendre ce qu’ils déploient
      Plus ces changements s’accumulent, plus la compréhension de la base de code baisse, et plus les comportements deviennent risqués
      Le pire, c’est que ce comportement est encouragé par le management, directement ou indirectement : objectifs de vitesse irréalistes, promotions liées à des initiatives floues autour de « l’usage de l’IA », surcharge des développeurs restants après des licenciements, ou mise de développeurs peu expérimentés dans des rôles seniors
      On dirait qu’une grande partie du secteur est en train de réapprendre dans la douleur les bases de la sécurité, comme si le monde était devenu fou
    • On dirait que cela part du principe que les blue teams et les ingénieurs ne font rien du tout
  • Les LLM vont générer un nombre énorme de vulnérabilités façon usine à gaz de Rube Goldberg dans les années à venir
    Cela a déjà commencé, et même si ce n’est pas le cas ici, cela se produit réellement

    • Il est peut-être physiquement impossible, en théorie, de construire un système totalement sûr
      Un peu comme il n’existe pas de cellule invulnérable à tous les virus
      Peut-être que jusqu’ici, nous avons surtout tenu grâce à une forme de sécurité par l’obscurité, et que cette obscurité signifiait simplement que personne n’avait réellement le temps ni la concentration pour analyser le code en profondeur
    • Je me demande si cela veut dire qu’on va injecter ce genre de vulnérabilités dans le kernel via du vibe coding, ou bien les découvrir ainsi
  • C’est dommage qu’il manque un peu de détails
    Je suis très curieux de savoir comment le bug a contourné MTE

    • Memory Tagging Extension
      Arm a publié en 2019 la spécification de la Memory Tagging Extension (MTE), un outil matériel destiné à aider à détecter les bugs de corruption mémoire
      MTE est un système de marquage mémoire et de vérification des tags, qui associe une valeur secrète à chaque allocation mémoire
      Le matériel n’autorise ensuite un accès mémoire que si la requête contient la bonne valeur secrète
      Si la valeur ne correspond pas, l’application plante et l’événement est enregistré, ce qui permet aux développeurs d’identifier un bug de corruption mémoire dès qu’il survient
      https://support.apple.com/guide/security/operating-system-in...
    • Après avoir davantage lu sur les attaques data-only, je comprends mieux
      (https://www.usenix.org/publications/loginonline/data-only-at...)
      Le programme lui-même n’est pas réellement modifié, donc on ne force pas un comportement qui ferait intervenir MTE, et MTE ne se déclenche pas
      Mon autre question, c’est pourquoi Apple n’a pas utilisé ici des vérifications fbounds
      Ils les ont pourtant appliquées de manière assez agressive ailleurs
      MTE combiné à des vérifications fbounds généralisées pourrait rendre le système d’exploitation extrêmement robuste
    • La mémoire GPU, les shaders, etc. ne sont pas protégés par MTE ni PAC
      Puisqu’ils parlent de « data-only », il est possible que des commandes GPU entrent dans ce cadre
    • Je me suis posé la même question, et si c’est bien une attaque data-only, cela pourrait rappeler que MIE, même s’il réduit beaucoup de chemins d’attaque, n’élimine pas pour autant tous les primitives de corruption exploitables
    • Ce n’est pas la première fois qu’un bug contourne MTE
      L’an dernier, quelque chose de similaire s’est produit sur le Google Pixel
      https://github.blog/security/vulnerability-research/bypassin...
  • Il est surprenant qu’Apple n’utilise toujours pas correctement en interne Swift, pourtant présenté comme un langage sûr
    On se demande si tout Swift 6 n’était pas presque uniquement du marketing

    • Ils l’utilisent clairement
      L’une des raisons d’être d’Embedded Swift est justement de remplacer à terme le firmware iBoot, actuellement écrit dans un dialecte de C proche dans l’esprit de Fil-C, par quelque chose de meilleur
      Mais ce n’est pas différent du kernel Linux
      Ce n’est pas parce que Rust a été autorisé que tout a été réécrit, et personne de raisonnable n’essaierait de réécrire un kernel avec Claude
    • Swift est manifestement utilisé chez Apple
      Il a récemment été ajouté au parseur CSS de Safari, et il tourne aussi sous forme embarquée dans certaines parties du Secure Enclave
      Il me semble que depuis l’époque de Strangeloop, il y avait des discussions sur son intégration dans le kernel, mais je ne sais pas jusqu’où cela a avancé
      Indépendamment de cela, Apple a fortement poussé les vérifications fbounds de clang, ce qui permet d’atteindre une petite mais importante partie de ce qu’apportent les langages sûrs en mémoire
      J’aimerais aussi voir une adoption plus large de Swift ou d’autres langages alternatifs, et davantage de concurrence dans l’espace des langages sûrs est toujours une bonne chose
    • L’option Strict Memory Safety pourrait vous intéresser
      https://docs.swift.org/compiler/documentation/diagnostics/st...
  • J’ai acheté un M5 exprès à cause de MIE, et maintenant je me sens un peu idiot

    • Pas besoin
      MTE bloque une grande catégorie de vulnérabilités et rend désormais des techniques comme ROP et JOP très difficiles, voire pratiquement impossibles
    • Il faut davantage s’inquiéter des malwares npm/PyPI que des bugs de corruption mémoire
  • L’article a été modifié ? Il n’y a pas beaucoup d’explications sur la visite sur site

  • On dirait encore du marketing exagéré pour Mythos
    Le rapport sur curl était bien plus posé
    https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-v...

    • Ces gens ne travaillent ni chez Apple ni chez Anthropic