Hacker News 의견들
  • 시연 내용만 보면 Apple 버그 바운티 플랫폼에서는 10만 달러짜리 취약점으로 보이지만, 포장을 잘하면 150만 달러짜리 취약점이 될 수도 있음
    MacOS 베타 버전에서 재현하고, 무단 접근으로 규정하며, 가능하면 잠금 모드에서도 보여주면 됨

    • 이건 로컬 권한 상승(LPE) 으로 보이고, 위에서 말한 건 무클릭 원격 코드 실행(RCE)에 가까움
  • 보안 이슈에 대한 LLM의 영향을 세상이 전혀 준비하지 못한 듯함
    사실이라면 Calif 팀에게 축하할 일이고, 세부 사항은 너무 기술적이라 다 이해하긴 어렵겠지만 55쪽짜리 보고서를 기대 중임

    • 나도 동의하지만, 걱정되는 건 사람들임
      여기저기서 개발자들이 자신이 무엇을 배포하는지도 제대로 이해하지 못한 채 LLM 생성 코드 변경을 프로덕션에 밀어 넣는다는 얘기를 듣고 있음
      변경이 누적될수록 코드베이스 이해도는 떨어지고, 행동은 더 위험해짐
      더 나쁜 건 이런 행동이 리더십에 의해 직접적으로든 간접적으로든 밀리고 있다는 점임. 비현실적인 속도 목표, 두루뭉술한 "AI 사용" 이니셔티브로 승진시키기, 해고로 남은 개발자에게 과부하를 주기, 미숙한 개발자를 시니어 역할에 앉히기 같은 식임
      업계의 큰 부분이 보안의 기본을 고생해서 다시 배우려는 듯 세상이 미쳐 돌아가고 있음
    • 블루팀과 엔지니어들이 아무것도 안 하고 손가락만 빨고 있다고 가정하는 듯함
  • LLM은 앞으로 몇 년 동안 루브 골드버그식 취약점을 엄청 만들어낼 것임
    이미 시작됐고, 이번 사례가 그런 건 아니지만 실제로 벌어지고 있음

    • 이론적으로 안전한 시스템을 만드는 것 자체가 물리적으로 불가능할지도 모름
      어떤 바이러스에도 취약하지 않은 세포가 없다고 보는 것처럼 말임
      어쩌면 지금까지는 일종의 모호성에 의한 보안으로 버텨온 것이고, 그 모호성이란 결국 아무도 코드를 실제로 분석할 시간과 집중력을 갖지 못했다는 뜻일 수 있음
    • 그런 취약점을 커널에 바이브 코딩으로 심는다는 뜻인지, 아니면 찾아낸다는 뜻인지 궁금함
  • 아쉽게도 세부 정보가 좀 부족함
    버그가 어떻게 MTE를 통과했는지 매우 궁금함

    • Memory Tagging Extension
      Arm은 2019년에 하드웨어가 메모리 손상 버그를 찾도록 돕는 도구로 Memory Tagging Extension(MTE) 명세를 공개했음
      MTE는 메모리 태깅과 태그 검사 시스템으로, 모든 메모리 할당에 비밀값을 태그로 붙임
      하드웨어는 이후 메모리 접근 요청이 올바른 비밀값을 포함할 때만 접근을 허용함
      비밀값이 맞지 않으면 앱이 크래시되고 이벤트가 기록되며, 개발자는 메모리 손상 버그가 발생하는 즉시 식별할 수 있음
      https://support.apple.com/guide/security/operating-system-in...
    • 데이터 전용 공격을 더 읽어보니 이해가 됨
      (https://www.usenix.org/publications/loginonline/data-only-at...)
      프로그램이 실제로 바뀌는 게 아니라 MTE가 개입해야 할 동작을 강제로 만들지 않으니 MTE가 트리거되지 않음
      다른 궁금증은 Apple이 왜 여기서 fbounds 검사를 쓰지 않았는지임
      다른 곳에서는 꽤 공격적으로 적용해왔기 때문임
      MTE와 전면적인 fbounds 검사를 함께 쓰면 운영체제가 극도로 단단해질 수 있음
    • GPU 메모리, 셰이더 등은 MTE나 PAC로 보호되지 않음
      "data-only"라고 했으니 GPU 명령이 여기에 들어맞을 수도 있음
    • 나도 같은 질문이 들었고, 이게 데이터 전용 공격이라면 MIE가 많은 공격 경로를 줄이긴 하지만 유용한 손상 원시 동작을 전부 없애지는 못한다는 교훈일 수 있음
    • 버그가 MTE를 통과한 게 처음은 아님
      작년에 Google Pixel에서도 비슷한 일이 있었음
      https://github.blog/security/vulnerability-research/bypassin...
  • Apple이 allegedly 안전한 언어인 Swift를 아직도 내부에서 제대로 쓰지 않는다는 게 놀라움
    Swift 6 전체가 거의 마케팅이었나 싶음

    • 확실히 쓰고 있음
      Embedded Swift가 나온 이유 중 하나도 현재 Fil-C와 비슷한 발상의 C 방언으로 작성된 iBoot 펌웨어를 더 나은 것으로 대체하려는 것임
      다만 Linux 커널과 다를 바 없음
      Rust가 허용됐다고 해서 세상이 전부 다시 작성된 건 아니고, 제정신인 사람이라면 Claude로 커널을 재작성하려 들지 않을 것임
    • Apple에서 Swift는 분명 쓰이고 있음
      최근에는 Safari의 CSS 파서로 추가됐고, Secure Enclave 일부에도 임베디드 형태로 동작함
      Strangeloop 시절부터 커널에 넣자는 논의가 있었던 것으로 알지만, 얼마나 진행됐는지는 잘 모르겠음
      그와 별개로 Apple은 clang의 fbounds 검사를 강하게 밀어왔고, 이는 메모리 안전 언어가 제공하는 것의 작지만 중요한 일부를 달성할 수 있음
      Swift나 대안 언어 채택이 더 늘어나는 것도 보고 싶고, 안전한 언어 영역에 더 많은 경쟁이 생기는 건 언제나 환영할 만함
    • Strict Memory Safety 옵션에 관심이 있을 수 있음
      https://docs.swift.org/compiler/documentation/diagnostics/st...
  • MIE 때문에 일부러 M5를 샀는데, 이제 좀 바보가 된 느낌임

    • 그럴 필요 없음
      MTE는 취약점의 큰 덩어리를 막아주고, ROP와 JOP 같은 기법을 이제 매우 어렵게 만들거나 사실상 불가능하게 만듦
    • 메모리 손상 버그보다 npm/PyPI 악성코드를 더 걱정해야 함
  • 글이 수정됐나? 현장 방문에 대한 설명이 별로 없음

  • Mythos를 위한 또 하나의 과장된 마케팅처럼 보임
    curl 보고서는 훨씬 더 차분했음
    https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-v...

    • 이 사람들은 Apple이나 Anthropic에서 일하지 않음