iLeakage: การโจมตีแบบ speculative execution บนเบราว์เซอร์โดยไม่ใช้ตัวจับเวลา ต่ออุปกรณ์ Apple

 (ileakage.com)
1 คะแนน โดย GN⁺ 2023-10-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แม้จะมีการบรรเทา Spectre ต่อเนื่องมาราว 6 ปี แต่ iLeakage แสดงให้เห็นว่าช่องโหว่ side channel จาก speculative execution ยังถูกนำไปใช้โจมตีใน Safari บน Mac, iPad และ iPhone ได้
  • ผู้โจมตีสามารถล่อให้ผู้ใช้เข้าเว็บอันตรายและคลิก จากนั้นใช้ JavaScript และ WebAssembly ทำให้ Safari เรนเดอร์หน้าเว็บใดก็ได้ และกู้คืนข้อมูลอ่อนไหวออกมาได้
  • การสาธิตรวมถึงการกู้คืนหัวข้อข้อความล่าสุดใน Gmail, ข้อมูลรับรองที่เติมอัตโนมัติของ Instagram, ประวัติการรับชม YouTube, รหัสผ่าน Facebook และโทเค็น SMS 2FA บน MacBook Pro ที่ใช้ Apple M3
  • ขอบเขตผลกระทบคืออุปกรณ์ macOS และ iOS ที่ใช้ CPU ตระกูล A-series และ M-series ของ Apple และมีการบรรเทาแล้วใน iOS 17.2 และ macOS 14.2 ที่มาพร้อม Safari 17.2
  • แม้จะป้องกันได้ด้วย Lockdown Mode หรือการปิด JavaScript แต่มีข้อจำกัดด้านการใช้งาน และเพราะการโจมตีทำงานอยู่ภายใน Safari โดยไม่ทิ้งร่องรอยใน system log จึงตรวจจับได้ยากมาก

ความเสี่ยงของ Spectre ที่กลับมาปรากฏอีกครั้งบนอุปกรณ์ Apple

  • iLeakage คือการโจมตีแบบ speculative execution side channel ที่มุ่งเป้าไปที่เว็บเบราว์เซอร์ Safari
  • เป้าหมายคืออุปกรณ์ macOS และ iOS ที่ใช้ CPU ตระกูล A-series หรือ M-series ของ Apple
    • รวมถึง iPhone และ iPad รุ่นใหม่
    • และรวมถึงโน้ตบุ๊กกับเดสก์ท็อปของ Apple ตั้งแต่ปี 2020 เป็นต้นมา
  • ตามปกติแล้ว โค้ดในแท็บหนึ่งของเบราว์เซอร์ไม่ควรอนุมานเนื้อหาในอีกแท็บได้ แต่ iLeakage สามารถอ่านเนื้อหาของหน้าเว็บเป้าหมายของผู้ใช้ที่เข้าไปยังหน้าโจมตีและคลิกได้
  • ข้อมูลที่กู้คืนได้อาจรวมถึงข้อมูลส่วนบุคคล รหัสผ่าน และข้อมูลบัตรเครดิต
  • ทีมนักวิจัยเปิดเผยผลการวิจัยให้ Apple เมื่อวันที่ 12 กันยายน 2022 ซึ่งก่อนการเผยแพร่สาธารณะ 408 วัน

ข้อมูลอ่อนไหวที่กู้คืนได้จริง

  • ทีมนักวิจัยสาธิตกรณีการกู้คืน ข้อมูลมูลค่าสูง จากบริการยอดนิยม

  • ข้อมูลรับรอง Instagram

    • ใช้สถานการณ์ที่ผู้ใช้ล็อกอิน Instagram บน Safari ของ macOS โดยมี LastPass เป็นตัวจัดการข้อมูลรับรองแบบเติมอัตโนมัติ

  • กล่องจดหมาย Gmail

    • บน Safari ของ iOS สมมติว่าผู้ใช้ล็อกอิน Google อยู่ แล้วกู้คืนหัวข้ออีเมลล่าสุดของบัญชี Gmail บน iPad

  • ประวัติการรับชม YouTube

    • กู้คืนประวัติการรับชม YouTube บน Chrome สำหรับ iOS
    • Chrome บน iOS ทำงานเป็นเชลล์ที่ครอบอยู่บนเอนจินการท่องเว็บของ Safari เนื่องจากนโยบายของ Apple App Store

  • รหัสผ่าน Facebook และโทเค็น 2FA

    • กู้คืนรหัสผ่าน Facebook ก่อน บน MacBook Pro ที่ใช้ชิป Apple M3, macOS 14.1.1 และ Safari 17.1
    • จากนั้นกู้คืนโทเค็น SMS 2FA ที่ส่งไปยังโทรศัพท์ Android ผ่าน Google Messages

วิธีการทำงานของ Spectre และ side channel

  • CPU สมัยใหม่ส่วนใหญ่ใช้ speculative execution โดยจะคาดเดาเส้นทางการประมวลผลและดำเนินคำสั่งบนเส้นทางนั้นล่วงหน้า เมื่อผลของ branch ยังไม่ออกมาทันที
  • หากคาดเดาผิด CPU จะย้อนการเปลี่ยนแปลงของสถานะกลับ แต่ร่องรอยอาจยังคงอยู่ในสถานะระดับ microarchitecture เช่น cache
  • Spectre คือช่องโหว่ฮาร์ดแวร์ที่ใช้ร่องรอยเหล่านี้เพื่ออ่านข้อมูลที่ตามความหมายของโปรแกรมเดิมไม่ควรเข้าถึงได้
  • side channel สามารถอาศัยลักษณะการติดตั้งระบบเพื่อโจมตีได้ แม้โปรแกรมจะรันอัลกอริทึมที่ปลอดภัยก็ตาม
    • ตัวอย่างเช่น เสียง การแผ่รังสีแม่เหล็กไฟฟ้า การ throttling จากความร้อน และการแชร์ทรัพยากร microarchitecture ของ CPU
  • เมื่อผู้โจมตีกับเป้าหมายรันอยู่บน CPU เดียวกัน ก็จะใช้ทรัพยากรร่วมกัน เช่น core, cache และ buffer ภายใน และการแข่งขันใช้ทรัพยากรนี้สามารถวัดทางอ้อมได้ผ่านตัวแปรอย่างเวลาแฝงหรือการใช้พลังงาน

โครงสร้างการโจมตีแบบไม่ใช้ตัวจับเวลาที่หลบเลี่ยงการป้องกันของ Safari

  • ผู้พัฒนาเบราว์เซอร์ได้เสริมมาตรการป้องกันต่อการโจมตี speculative execution และ transient execution มาตั้งแต่หลัง Spectre
  • การป้องกันของ Safari รวมถึง 35-bit addressing, value poisoning, นโยบายแยกโปรเซสต่อแท็บ และตัวจับเวลาความละเอียดต่ำ
  • iLeakage เป็นการสาธิตการโจมตี speculative execution ครั้งแรกต่อ CPU Apple Silicon และ Safari
  • การโจมตีเริ่มจากการกู้คืน โครงสร้าง cache ที่ไม่เปิดเผยของ CPU Apple ด้วยการทดลองเชิงประจักษ์
    • จากนั้นสร้าง gadget ที่อาศัย speculation เพื่อแยกแยะ cache hit กับ miss โดยใช้เพียงตัวจับเวลาความละเอียดต่ำ
    • และยังสาธิตตัวแปรที่ใช้ race condition โดยไม่ต้องมีตัวจับเวลาด้วย
  • gadget นี้ถูกใช้ทั้งในการทดสอบสร้าง eviction set และใน covert channel
  • หลังจากย้ายเทคนิคมาใช้กับ Safari ก็ทำให้ Safari ระหว่างที่ CPU กำลัง speculative execution รันโค้ดสำหรับชนิดข้อมูลหนึ่งกับอ็อบเจ็กต์ชนิดผิดที่ผู้โจมตีสร้างขึ้น
  • ท้ายที่สุดจึงสามารถทำ out-of-bounds read ได้จากทุกตำแหน่งใน address space ของโปรเซสเรนเดอร์ของ Safari
  • เมื่อนำไปรวมกับวิธีใหม่ในการรวมเว็บไซต์ต่างโดเมนให้อยู่ใน address space เดียวกัน จึงสามารถทำการโจมตี speculative type confusion เพื่อรั่วไหลข้อมูลอ่อนไหวได้

มาตรการบรรเทา ความยากในการตรวจจับ และผลกระทบตามเบราว์เซอร์

  • iLeakage ถูกบรรเทาแล้วใน Safari 17.2 ซึ่ง Safari 17.2 มาพร้อมกับ iOS 17.2 และ macOS 14.2
    • วิธีรับมือคืออัปเดตอุปกรณ์ Apple ให้เป็นเวอร์ชัน OS ล่าสุด
  • Lockdown Mode ช่วยบรรเทา iLeakage โดยปิดการทำงานของ JIT compilation ใน Safari
    • JIT compilation เป็นฟีเจอร์ด้านประสิทธิภาพที่ iLeakage ใช้สร้าง attack primitive
    • Lockdown Mode อาจเปลี่ยนพฤติกรรมของอุปกรณ์ เช่น บล็อกไฟล์แนบบางชนิดในข้อความและสาย FaceTime จากผู้ไม่รู้จัก
    • รายการทั้งหมดอยู่ใน เอกสาร Lockdown Mode ของ Apple
  • การปิด JavaScript ก็ป้องกัน iLeakage ได้เช่นกัน แต่ Safari อาจเรนเดอร์บางเว็บไซต์ผิดพลาดหรือไม่ครบถ้วน และฟีเจอร์เว็บขั้นสูงอย่างการชำระเงินออนไลน์อาจใช้งานไม่ได้
  • iLeakage ทำงานอยู่ภายใน Safari และไม่ทิ้งร่องรอยในไฟล์ system log ทำให้ตรวจจับได้ยากมาก
    • อย่างไรก็ตาม ร่องรอยการเข้าเว็บโจมตีอาจยังคงอยู่ใน browser cache ของหน้าที่เพิ่งเข้าชมล่าสุด
  • ยังไม่มีหลักฐานการถูกนำไปใช้โจมตีจริง
    • การประกอบการโจมตีแบบครบวงจรทำได้ยากมาก และต้องใช้ความรู้ระดับสูงเกี่ยวกับการโจมตี side channel บนเบราว์เซอร์และการทำงานภายในของ Safari
  • ยังคงแนะนำให้ใช้ตัวจัดการข้อมูลรับรองต่อไป
    • iLeakage สามารถกู้คืนข้อมูลรับรองที่ถูกเติมอัตโนมัติลงในหน้าเว็บได้
    • หลายแพลตฟอร์มกำหนดให้ต้องมีปฏิสัมพันธ์จากผู้ใช้ก่อนจึงจะเกิดการเติมอัตโนมัติ
  • Chrome, Firefox และ Microsoft Edge บน macOS ใช้เอนจิน JavaScript คนละตัว จึงไม่ได้รับผลจาก iLeakage ที่อาศัยลักษณะเฉพาะของเอนจิน JavaScript ใน Safari
  • บน iOS เนื่องจากนโยบาย App Store และ sandboxing ของ Apple แอปเบราว์เซอร์อื่นก็ต้องใช้เอนจิน JavaScript ของ Safari ด้วย
    • Chrome, Firefox และ Edge บน iOS เป็นตัวห่อ Safari ที่เพิ่มฟีเจอร์เสริม เช่น การซิงก์บุ๊กมาร์กและการตั้งค่า
    • แอปเบราว์เซอร์เกือบทั้งหมดใน App Store มีความเสี่ยงต่อ iLeakage
  • บทความวิชาการมีให้ที่ iLeakage paper และได้รับการตีพิมพ์ในงาน 2023 ACM Conference on Computer and Communications Security

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-10-26
ความคิดเห็นจาก Hacker News

  • ดูเหมือนว่า FAQ นี้ยังขาดบางอย่างไป: อยากรู้ว่านี่เป็น ช่องโหว่ของ WebKit หรือช่องโหว่ของ Safari, Safari บนมือถือไม่มีการตั้งค่าสำหรับนักพัฒนาดังกล่าว แล้วถ้าเปิด Lockdown Mode จะช่วยบรรเทาได้ไหม, และเปิดเผยให้ Apple ทราบเมื่อไร
    ต่อมาหน้านี้ได้รับการอัปเดตและมีคำตอบสำหรับคำถามสุดท้ายแล้ว โดยนักวิจัยระบุว่าได้เปิดเผยผลการวิจัยให้ Apple ทราบเมื่อวันที่ 12 กันยายน 2022 ซึ่งเป็นเวลา 408 วันก่อนการเผยแพร่สู่สาธารณะ

    • ในเชิงเทคนิคอาจมองได้ว่าเป็น Hacker News Favorite Processor หรือก็คือ ช่องโหว่ของ M1/M2 แต่ CPU ที่เกี่ยวข้องในตลาดปัจจุบันทั้งหมดมีจุดอ่อนแบบเดียวกัน จนกลายเป็นเหมือนฟีเจอร์ที่ซอฟต์แวร์ต้องออกแบบมาเพื่อบรรเทาผลกระทบ
      การลบ Spectre gadget ทั้งหมดที่เป็นไปได้ออกจาก WebKit นั้นไม่สมจริง ดังนั้นเบราว์เซอร์ควรใช้มาตรการบรรเทา Spectre ของระบบปฏิบัติการ โดยแยกเว็บไซต์ต่าง ๆ ออกจากกันไว้คนละโปรเซส
      ใน FAQ ระบุว่า “ท้ายที่สุดสามารถทำ out-of-bounds read ได้จากทุกที่ในพื้นที่แอดเดรสของโปรเซสเรนเดอร์ของ Safari” ดังนั้นโดยส่วนตัวจึงมองว่าเป็นช่องโหว่จากการใช้งาน site isolation ของ Safari ที่ผิดพลาด
    • คำถามสุดท้ายมีคำตอบอยู่ใน FAQ: นักวิจัยเปิดเผยผลการวิจัยให้ Apple ทราบเมื่อวันที่ 12 กันยายน 2022 และระบุว่าเป็นเวลา 408 วันก่อนการเผยแพร่สู่สาธารณะ
    • สิ่งนี้ดูเหมือนช่องโหว่เชิงสถาปัตยกรรมที่สามารถใช้ side channel จาก speculative execution ที่คล้าย Spectre ภายใน Safari หรือเบราว์เซอร์อื่น ๆ ได้
      จะโจมตีได้ในสภาพแวดล้อมใดนั้นขึ้นอยู่กับรายละเอียดการใช้งานของ gadget ที่ใช้ JavaScript เพื่อกระตุ้นและวัด side channel นี้ ซึ่งอาจอยู่ใน论文ที่ยังไม่ได้อ่าน
    • ตอนนี้มีคำตอบขึ้นใน FAQ แล้ว: นี่คือ ช่องโหว่ของ Safari และระบุว่า “iLeakage ใช้ประโยชน์จากคุณลักษณะของเอนจิน JavaScript ของ Safari”
      Lockdown Mode ช่วยบรรเทาได้เพราะปิดการคอมไพล์แบบ JIT ใน Safari และบอกว่าจะปิดกั้นฟีเจอร์ด้านประสิทธิภาพที่ iLeakage ใช้สร้าง primitive สำหรับการโจมตี

  • สำหรับคำถาม “การใช้ตัวจัดการข้อมูลรับรองทำให้เสี่ยงหรือไม่?” ส่วนใหญ่ตอบว่าไม่ แต่ถ้าเป็นการรั่วไหลของบางอย่างจากหน่วยความจำ ก็น่าจะกระทบหน่วยความจำทั้งหมดใน พื้นที่โปรเซสของ Safari ไม่ใช่หรือ
    ไม่ค่อยคุ้นกับด้านนี้ เลยยังไม่ค่อยเข้าใจว่าทำไมการใช้หรือไม่ใช้ตัวจัดการข้อมูลรับรองถึงเป็นเงื่อนไขยกเว้น

    • โดยพื้นฐานเหมือนจะบอกว่า: มันไม่ได้เพิ่มความปลอดภัยพิเศษสำหรับการโจมตีเฉพาะนี้ แต่โดยทั่วไปการใช้ password manager ปลอดภัยกว่า และไม่ได้ทำให้เสี่ยงต่อการโจมตีนี้มากขึ้น
      ดูเหมือนพยายามหลีกเลี่ยงไม่ให้คนกลับไปใช้วิธีอย่าง “newpassword2” และถ้าปิดการกรอกอัตโนมัติแล้วใช้คีย์ลัดหรือการโต้ตอบอื่นจากผู้ใช้เพื่อกรอก ก็จะปลอดภัยกว่า
    • หนึ่งในเดโมคือการกู้คืน คู่ชื่อผู้ใช้/รหัสผ่าน ของไซต์บุคคลที่สามอย่าง Instagram ได้ เพราะ password manager กรอกฟิลด์อัตโนมัติจนข้อมูลขึ้นมาอยู่ในหน่วยความจำ
      อาจอ่านได้ว่า หากไม่ใช้ password manager ไม่บันทึกไว้ในเบราว์เซอร์ และพิมพ์เองทุกครั้งก็จะปลอดภัยจากเรื่องนี้ แต่ข้อโต้แย้งนั้นไม่ดีด้วยหลายเหตุผล
      password manager มีประโยชน์ด้วยเหตุผลอื่นอีกมาก และถึงรหัสผ่านจะถูกขโมย อย่างน้อยก็เสียหายแค่เว็บไซต์เดียว
      เทคนิคนี้น่าจะขโมย session token ได้ด้วย ซึ่งแม้จะไม่ร้ายแรงเท่าการขโมยรหัสผ่าน แต่ก็ยังแย่อยู่ดี
      ถ้าตั้งค่า password manager ให้ต้องคลิกก่อนจึงจะกรอก ก็สามารถกันการโจมตีนี้ได้เช่นกัน
    • ดูเหมือนหมายความว่าการใช้ password manager ไม่ได้ทำให้เปราะบางมากขึ้น
      รหัสผ่านที่ถูกกรอกอัตโนมัติลงในหน้าเว็บสามารถกู้คืนได้เหมือนรหัสผ่านที่พิมพ์เอง แต่ไม่ได้หมายความว่าสามารถอ่าน รหัสผ่านทั้งหมดที่เก็บอยู่ใน password manager ได้โดยตรง
    • เข้าใจว่าช่องโหว่นี้อนุญาตให้เข้าถึงเฉพาะหน่วยความจำของ โปรเซส Safari/WebKit ที่เกี่ยวข้อง โดยเฉพาะไซต์ที่ถูกเปิดผ่านการเรียก window.open เท่านั้น
      รหัสผ่านที่เก็บอยู่ในแอป password manager แยกต่างหากจะเข้าถึงไม่ได้ เว้นแต่ว่าแอปนั้นจะกรอกอัตโนมัติลงในหน้าต่างหรือโปรเซส Safari ที่ถูกโจมตี
    • เข้าใจว่าโดยทั่วไป Safari วาง origin และส่วนขยายที่ต่างกันไว้คนละพื้นที่แอดเดรส จึงไม่เปราะบางต่อการโจมตีแบบ speculative execution
      การโจมตีครั้งนี้คือการหาวิธีทำให้ origin สองแห่งที่ต่างกันแชร์พื้นที่แอดเดรสเดียวกัน และคิดว่าใช้กับส่วนขยายไม่ได้
      ใน论文ระบุว่า “เราแสดงเทคนิคใหม่ที่ใช้ประโยชน์จากนโยบาย site isolation ของ Safari โดยเพียงแค่หน้าเว็บของผู้โจมตีเปิดหน้าของเหยื่อใด ๆ ด้วย JavaScript window.open API ก็ทำให้แชร์พื้นที่แอดเดรสกันได้”

  • สับสนว่าการวางกรอบว่าเป็นเฉพาะ WebKit นั้นถูกต้องจริงไหม การใช้แคชในทางที่ผิดเองดูเป็นเรื่องทั่วไป และในข้อความอ้างอิงก็ระบุว่าทำได้แม่นยำเกือบสมบูรณ์ใน Safari, Firefox และ Tor
    นอกจากนี้ยังสงสัยว่าการโจมตีผ่าน window.open() เป็น เฉพาะ WebKit จริง ๆ หรือแค่งานวิจัยนี้เจาะลึกเฉพาะ WebKit
    window.open() บ่งชี้บริบทร่วมกันที่หน้าต่างผู้เรียกได้รับ reference ไปยังหน้าต่างใหม่ และหน้าต่างใหม่มี reference ย้อนกลับผ่าน window.opener จึงสงสัยว่าเอนจินเบราว์เซอร์อื่น ๆ แยกขาดได้สมบูรณ์หรือไม่

    • Chromium และ Firefox ได้ใช้งาน site isolation ในเบราว์เซอร์เดสก์ท็อปแล้ว ดังนั้นหน้าเว็บที่ไม่ใช่ไซต์เดียวกันไม่ควรถูกโหลดในโปรเซสเดียวกัน
      ในเบราว์เซอร์มือถือ site isolation ของ Chromium ยังมีข้อจำกัด และ Firefox ยังทำไม่เสร็จ
      https://www.chromium.org/Home/chromium-security/site-isolati...

  • งงมาก เรื่องนี้ดูเหมือนเป็นปัญหาความร้ายแรงสูง แต่การแก้ไขกลับอยู่หลัง เมนูดีบัก ไม่รู้ว่าทำไมถึงถูกเปิดเผยก่อนจะถูกปล่อยใช้งานอย่างถูกต้องครบทุกที่
    นอกจากนี้ยังแสดงให้เห็นว่ามาตรการบรรเทา side channel แทบไม่มีประโยชน์ และเราไม่ควรทำเหมือนว่าการโจมตีแบบนี้ถูกแก้แล้ว
    ถ้าเป็นโฮสต์ที่รันหลายแอปพลิเคชันบน CPU สมัยใหม่ การรันโค้ดที่ไม่น่าเชื่อถือก็ไม่ปลอดภัย ไม่ว่าจะทำ sandbox ดีแค่ไหนก็ตาม

    • ดูเหมือน Apple มีเวลา มากกว่า 400 วัน ในการแก้เรื่องนี้ และนั่นก็นานกว่าที่ผมจะให้ไปแล้ว
      ผมคิดว่าการแจ้งให้ผู้ใช้ Apple รู้ถึงความเสี่ยงย่อมดีกว่าปล่อยให้พวกเขาถูกทิ้งไว้อีกกว่าหนึ่งปีโดยไม่รู้ถึงอันตราย
      ผมเห็นด้วยกับการให้เวลาบริษัทแก้บั๊ก แต่พอถึงจุดหนึ่ง การไม่แจ้งผู้ที่ได้รับผลกระทบกลับกลายเป็นสิ่งที่ไร้ความรับผิดชอบกว่า
    • สถานะของการบรรเทาผลกระทบทำให้ผมสับสนเหมือนกัน แต่论文ชัดเจนกว่าเว็บไซต์
      ใน论文อธิบายว่า speculative JavaScript sandbox escape ยังทำได้อยู่ แต่ผู้โจมตีจะถูกจำกัดให้อ่านได้แค่ address space และข้อมูลของตัวเอง
      ระบุว่า ณ เวลาที่เขียน แพตช์ของ Apple เปิดเผยต่อสาธารณะแล้วและถูกนำไปใช้ใน Safari Technology Preview 173 ขึ้นไป และ [57] คือ https://github.com/WebKit/WebKit/pull/10169
      ถัดลงมาจากนั้น วิศวกรยังคงลิงก์แพตช์เสริมความแข็งแกร่งเพิ่มเติมเกี่ยวกับ window.open() และการแยกโปรเซส
    • ผมคิดว่าใน Safari 17.0 มาตรฐานบน Ventura นั้น Swap Processes on Cross-Site Window Open เปิดอยู่แล้วและถูกระบุว่า Stable
      ผมไม่ได้เปิดเอง เลยคิดว่า Apple อาจเปิดใช้งานไปแล้วและคำอธิบายอาจเก่า แต่ภายหลังพบว่าผมกำลังดู Swap Processes on Cross-Site Navigation ซึ่งชื่อคล้ายกัน และดูเหมือนตอนนี้ยังไม่ได้เปิดเป็นค่าเริ่มต้น
    • เพราะ Apple ที่เรียกตัวเองว่า “ปราการด่านสุดท้ายของความเป็นส่วนตัวและความปลอดภัย” ถือเรื่องนี้ไว้ มากกว่า 400 วัน แล้วยังไม่แก้
      ควรโทษ Apple ที่ปล่อยไว้นานขนาดนี้ มากกว่านักวิจัยที่เปิดเผยก่อนปล่อยแพตช์
    • การแก้ไขนี้ต้องเปลี่ยน โมเดลโปรเซส ของ WebKit จึงมีความเป็นไปได้สูงว่ายังอยู่ระหว่างการทดสอบก่อนปล่อยเต็มรูปแบบ เลยถูกซ่อนไว้หลังเมนูดีบัก
      ไม่ใช่ว่าการโจมตี side channel ทั้งหมดถูกแก้แล้ว แต่การบอกว่ามาตรการบรรเทา side channel ไม่มีประโยชน์ก็ไม่เหมาะสม
      เหมือนคาดเข็มขัดนิรภัยแล้วคนยังเสียชีวิตจากอุบัติเหตุรถยนต์ได้ แต่ไม่ได้แปลว่าเข็มขัดนิรภัยไร้ประโยชน์ มาตรการบรรเทาช่วยเพิ่มความยากในการใช้ประโยชน์จากช่องโหว่อย่างมาก

  • เขาบอกว่า “นักวิจัยเปิดเผยผลการค้นพบให้ Apple เมื่อวันที่ 12 กันยายน 2022” ผมสงสัยจริง ๆ ว่าทำไม Apple ถึงแทบปล่อยทิ้งไว้ นานกว่าหนึ่งปี

    • เพราะทำได้ไง
      Apple เป็นหนึ่งใน ผู้มีอำนาจด้าน CVE จึงสามารถปฏิเสธการออก CVE สำหรับผลิตภัณฑ์ของตนเองได้ และเมื่อมีอำนาจแบบนั้น ก็สามารถเดินเรื่องช้าเท่าไรก็ได้ตามต้องการ

  • ผมเหมือนเคยเห็นข้อความเกี่ยวกับการแก้ไขบนเว็บไซต์ iLeakage แต่ตอนนี้หายไปแล้ว คิดว่าตัวเองจำผิด แต่จริง ๆ แล้วเว็บไซต์มีการเปลี่ยนแปลงในช่วงหนึ่งชั่วโมงที่ผ่านมา
    เคยมีข้อความว่า “Apple เพิ่งปล่อย iOS 17.1, iPadOS 17.1, macOS Sonoma 14.1 แล้ว ให้อัปเดตอุปกรณ์ของคุณ” และตอนนี้ถูกย้อนกลับแล้ว
    https://github.com/ileakage-authors/ileakage-authors.github....

    • ดูเหมือนผู้เขียน论文คนหนึ่งกำลังอ่านเธรดนี้อยู่
      หลังจากผมชี้ว่าในไซต์ไม่มีไทม์ไลน์การเปิดเผย ก็มีการเพิ่มส่วนสั้น ๆ ใน FAQ และดูเหมือนนักวิจัยเองก็สับสนไปด้วย เพราะสถานการณ์ว่ามีการปล่อยแพตช์แล้วหรือยังนั้นชวนสับสน
    • แปลกดี ผมอัปเดตเป็น iOS 17.1 แล้ว ใน Settings -> Safari -> Advanced -> Feature Flags มี Swap Processes on Cross-Site Navigation และเปิดเป็นค่าเริ่มต้น
      สงสัยว่ามันต่างจาก Swap Processes on Cross-Site Window Open บน macOS หรือเปล่า

  • ข้อความที่ว่า “iLeakage เป็นการโจมตีที่ทำให้สำเร็จตั้งแต่ต้นจนจบได้ค่อนข้างยาก และต้องมีความรู้ขั้นสูงเกี่ยวกับการโจมตี side channel บนเบราว์เซอร์และการใช้งานจริงของ Safari” อาจเป็นเหตุผลที่ Apple ไม่ได้ใส่ใจมากนัก

    • ดูเหมือนหมายความว่ามันยากเกินกว่าจะทำได้จริงในทางปฏิบัติ และความเสี่ยงแทบใกล้ 0%
      การตั้งฉายาน่ากลัว ๆ พร้อมชื่อโดเมนให้อีกหนึ่งกรณีแบบนี้ ดูไม่เป็นมืออาชีพและไม่น่าเชื่อถือเท่าไร

  • ถ้าอุปกรณ์ macOS หรือ iOS ที่มี CPU Apple A series หรือ M series ได้รับผลกระทบ ซึ่งก็คือ iPhone/iPad รุ่นหลัง ๆ และโน้ตบุ๊ก/เดสก์ท็อป Apple ตั้งแต่ปี 2020 เป็นต้นมา ในฐานะผู้ใช้ Intel Mac ที่หาได้ยาก ผมน่าจะไม่ได้รับผลกระทบ

    • น่าจะมีโอกาสได้รับผลกระทบสูง
      แค่โครงสร้างลำดับชั้นของแคชต่างกันเล็กน้อย และ proof of concept คงต้องปรับเล็กน้อย
    • ถ้าเป็น macOS ก็แค่ไม่ใช้ Safari
      ถ้าเป็น iOS ต้องใช้ Lockdown Mode และนั่นคือวิธีเดียวในการใช้ iPhone อย่างปลอดภัย
      benchmark ที่ทำโดยไม่มี Lockdown Mode ควรถูกมองว่าไร้ประโยชน์พอ ๆ กับการรัน benchmark CPU ด้วย mitigations=off

  • นี่เป็นอีกเหตุผลที่ดีที่ควรอนุญาตให้ใช้ เบราว์เซอร์เอนจิน อื่นบนอุปกรณ์ iOS

    • กฎระเบียบของ EU อาจลงเอยด้วยการบังคับ Apple ก็ได้

  • หากเกิดข้อผิดพลาดเมื่อรันคำสั่งด้านล่าง ให้ให้สิทธิ์ Full Disk Access แก่ Terminal แล้วลองอีกครั้ง
    defaults write com.apple.SafariTechnologyPreview IncludeInternalDebugMenu 1