เชนเอ็กซ์พลอยต์แบบ 0-click สำหรับ Pixel 10

 (projectzero.google)
1 คะแนน โดย GN⁺ 2 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เชนของ Pixel 10 ใช้ ช่องโหว่ Dolby 0-click ที่เคยมีอยู่ทั่ว Android ก่อนแพตช์เป็นขั้นแรก และเพิ่มเส้นทางยกระดับสิทธิ์ภายในเครื่องแบบใหม่
  • ไดรเวอร์ BigWave ในเชนของ Pixel 9 ไม่มีอยู่ใน Pixel 10 จึงพอร์ตมาใช้ไม่ได้ และ /dev/vpu ของ Tensor G5 กลายเป็นพื้นผิวการโจมตีแทน
  • ไดรเวอร์ VPU เปิดเผย อินเทอร์เฟซรีจิสเตอร์ MMIO ให้ userspace โดยตรง และการตรวจสอบเพียง 2 ชั่วโมงก็พบข้อบกพร่อง mmap ร้ายแรง
  • remap_pfn_range ทำการแมปโดยอิงจาก ขนาด VMA แทนขนาดรีจิสเตอร์ ทำให้สามารถอ่านและเขียนเคอร์เนลส่วน .text และ .data ได้
  • ช่องโหว่ถูกรายงานเมื่อ 24 พฤศจิกายน 2025 และได้รับการแพตช์หลังจากนั้นเพียง 71 วัน ซึ่งชี้ว่ายังจำเป็นต้องเสริมความปลอดภัยของไดรเวอร์ Android ต่อไป

โครงสร้างเชน 0-click ของ Pixel 10

  • จาก เชนเอ็กซ์พลอยต์ ที่ใช้เอ็กซ์พลอยต์ 2 ตัวเพื่อไต่จากบริบท 0-click ไปถึง Android root บน Google Pixel 9 ก็ได้มีการประกอบเชนลักษณะคล้ายกันบน Pixel 10
  • ช่องโหว่ Dolby 0-click มีอยู่ทั่ว Android จนกระทั่งมีแพตช์ในเดือนมกราคม 2026 และถูกใช้เป็นขั้นแรกในเชนที่มุ่งโจมตี Pixel 10 เช่นกัน
  • ไดรเวอร์ BigWave ซึ่งเป็นขั้นตอนยกระดับสิทธิ์ภายในเครื่องของ Pixel 9 ไม่ได้ถูกรวมมาใน Pixel 10 จึงพอร์ตมาใช้ตรง ๆ ไม่ได้ และไดรเวอร์ /dev/vpu ของ Pixel 10 จึงกลายเป็นพื้นผิวการโจมตีใหม่

อัปเดตเอ็กซ์พลอยต์ Dolby

  • การปรับ เอ็กซ์พลอยต์เดิม สำหรับ CVE-2025-54957 ให้ใช้กับ Pixel 10 ส่วนใหญ่เป็นการอัปเดตออฟเซ็ตที่อิงกับไลบรารีของ Pixel 9 ให้เป็นออฟเซ็ตที่สอดคล้องกันในไลบรารีของ Pixel 10
  • Pixel 10 ใช้ RET PAC แทน -fstack-protector จึงไม่สามารถเขียนทับ __stack_chk_fail ได้
  • หลังจากลองหลายวิธี จึงเลือกใช้การเขียนทับโค้ดเริ่มต้น dap_cpdp_init ที่ถูกเรียกหนึ่งครั้งตอนเริ่มต้นตัวถอดรหัสและจะไม่ถูกเรียกอีก
  • เอ็กซ์พลอยต์ Dolby UDC ที่อัปเดตแล้วเผยแพร่อยู่ที่นี่ และทำงานได้เฉพาะบนอุปกรณ์ที่ยังไม่ได้แพตช์และมี SPL ไม่เกิน ธันวาคม 2025

การถอด BigWave ออกและการเพิ่ม VPU

  • Pixel 10 ไม่มีไดรเวอร์ BigWave ทำให้ไม่สามารถพอร์ตขั้นตอนยกระดับสิทธิ์ภายในเครื่องจากเชนของ Pixel 9 มาใช้ได้
  • มีการพบไดรเวอร์ /dev/vpu ที่เข้าถึงได้จากบริบท SELinux ของ mediacodec ซึ่งใช้โต้ตอบกับซิลิคอน Chips&Media Wave677DV สำหรับเร่งการถอดรหัสวิดีโอบนชิป Tensor G5
  • จากคอมเมนต์ในไฟล์ C ที่เปิดเผยต่อสาธารณะ ดูเหมือนไดรเวอร์นี้ได้รับการพัฒนาและดูแลโดยกลุ่มเดียวกับผู้พัฒนาไดรเวอร์ BigWave
  • จากการ ตรวจสอบไดรเวอร์ VPU เป็นเวลา 2 ชั่วโมง ร่วมกับ Jann Horn ก็พบช่องโหว่ที่ผิดปกติอย่างมาก
  • ต่างจากไดรเวอร์ Linux แบบอัปสตรีมสำหรับชิป Chips&Media รุ่นก่อนหน้า WAVE521C ไดรเวอร์ WAVE677DV ของ Pixel ไม่ได้ผสานรวมกับ V4L2 (“Video for Linux API”)
  • ไดรเวอร์ของ Pixel เปิดเผยฮาร์ดแวร์อินเทอร์เฟซของชิปให้ userspace โดยตรง และอนุญาตให้ userspace แมป อินเทอร์เฟซรีจิสเตอร์ MMIO ของชิปได้
  • หน้าที่หลักของไดรเวอร์คือการตั้งค่าการแมปหน่วยความจำของอุปกรณ์ การจัดการพลังงาน และช่วยให้ userspace รออินเทอร์รัปต์จากชิปได้

ช่องโหว่เคอร์เนลหลัก

  • บั๊กดังกล่าว เป็นช่องโหว่ที่เอ็กซ์พลอยต์ได้ง่ายอย่างมาก
  • ตัวจัดการ mmap ที่มีปัญหาเป็นโค้ดสำหรับแมปพื้นที่รีจิสเตอร์ MMIO ของฮาร์ดแวร์ VPU เข้าไปในพื้นที่แอดเดรสเสมือนของ userland
  • การเรียก remap_pfn_range ไม่ได้ถูกจำกัดด้วยขนาดของพื้นที่รีจิสเตอร์ แต่ทำงานโดยอิง ขนาด VMA เท่านั้น
  • ผู้โจมตีสามารถระบุขนาดใน system call mmap ให้ใหญ่กว่าพื้นที่รีจิสเตอร์ เพื่อแมปหน่วยความจำกายภาพจากตำแหน่งแอดเดรสกายภาพของพื้นที่รีจิสเตอร์ VPU ต่อเนื่องออกไปได้มากเท่าที่ต้องการเข้าสู่ userland
  • เนื่องจากอิมเมจเคอร์เนลทั้งหมดอยู่ที่แอดเดรสกายภาพที่สูงกว่าพื้นที่รีจิสเตอร์ VPU บั๊กนี้จึงทำให้เข้าถึงและแก้ไขพื้นที่ .text และ .data ของเคอร์เนลได้
  • บน Pixel นั้น เคอร์เนลอยู่ที่แอดเดรสกายภาพเดิมเสมอ ทำให้ออฟเซ็ตระหว่างพื้นที่หน่วยความจำ VPU กับเคอร์เนลเป็นค่าที่ทราบแน่นอนอยู่แล้ว
  • หากระบุความยาว VMA ให้มากพอ ก็จะทราบตำแหน่งเคอร์เนลได้อย่างแม่นยำจากแอดเดรสที่ mmap ส่งกลับมา โดยไม่ต้องสแกนหาเคอร์เนลในหน่วยความจำกายภาพที่แมปไว้
  • การทำให้ช่องโหว่นี้กลายเป็น การอ่าน/เขียนเคอร์เนลโดยพลการ ต้องใช้โค้ดเพียง 5 บรรทัด และใช้เวลาพัฒนาเอ็กซ์พลอยต์ทั้งหมดไม่ถึงหนึ่งวัน
  • ผู้โจมตีสามารถเขียนทับฟังก์ชันใดก็ได้ในเคอร์เนลเพื่อให้ได้การรันโค้ดในเคอร์เนล หรือสร้าง primitive ตามต้องการ

การจัดการแพตช์

  • ช่องโหว่นี้ถูกรายงานเมื่อ 24 พฤศจิกายน 2025 และ Android VRP ประเมินปัญหานี้เป็นระดับความรุนแรง High
  • บั๊ก BigWave ที่ใช้ในการยกระดับสิทธิ์บน Pixel 9 มีผลกระทบด้านความปลอดภัยเท่ากัน แต่ตอนแรกถูกประเมินเป็น Moderate ดังนั้นการประเมินครั้งนี้จึงถือว่าดีขึ้น
  • ช่องโหว่ได้รับการแพตช์ในประกาศความปลอดภัย Pixel ประจำเดือนกุมภาพันธ์ หลังจากรายงานครั้งแรกเพียง 71 วัน
  • นี่ถูกประเมินว่าเป็นครั้งแรกที่บั๊กในไดรเวอร์ Android ได้รับการแพตช์ภายใน 90 วันนับจากการรายงานต่อผู้จำหน่ายครั้งแรก
  • กระบวนการนี้แสดงให้เห็นว่าการตอบสนองของ Android ในการจัดประเภทและแพตช์บั๊กประเภทคล้ายกันดีขึ้นอย่างมีนัยสำคัญ

ความหมายด้านความปลอดภัย

  • การรับมือช่องโหว่ VPU แสดงให้เห็นว่ากระบวนการจัดประเภทของ Android ดีขึ้น และมีการออกการแก้ไขเบื้องต้นในเวลาที่สั้นกว่ากรณี BigWave ก่อนหน้าอย่างมาก
  • ความพยายามของ Android ในการแพตช์ช่องโหว่ร้ายแรงอย่างมีประสิทธิภาพช่วยปกป้องอุปกรณ์ Android จำนวนมาก
  • ขณะเดียวกัน ไดรเวอร์ Android ก็ยังคงต้องการโค้ดที่รอบคอบและตระหนักด้านความปลอดภัยมากกว่านี้อย่างต่อเนื่อง
  • หลังการรายงานบั๊ก BigWave เดิม มีความคาดหวังว่านักพัฒนาที่เกี่ยวข้องจะตรวจสอบปัญหาความปลอดภัยที่ชัดเจนในไดรเวอร์อื่น ๆ แต่ห้าเดือนต่อมากลับพบช่องโหว่ร้ายแรงในไดรเวอร์ VPU ที่มองเห็นได้ทันทีแม้จากการตรวจสอบแบบตื้น ๆ
  • เพื่อความปลอดภัยของระบบนิเวศ Android การ เสริมความปลอดภัยของไดรเวอร์ ยังคงเป็นลำดับความสำคัญที่สำคัญ
  • ผู้จำหน่ายควรปรับปรุงแนวปฏิบัติด้านการพัฒนาซอฟต์แวร์ล่วงหน้า เพื่อไม่ให้ช่องโหว่หลุดไปถึงผู้ใช้ปลายทาง โดยเฉพาะผลิตภัณฑ์ที่มีความสำคัญด้านความปลอดภัยควรมีช่องโหว่อยู่ในระดับต่ำอย่างสมเหตุสมผลตั้งแต่วันเปิดตัว
  • ทีมซอฟต์แวร์ควรใช้แนวทาง เชิงรุก ต่อความปลอดภัย การตรวจสอบโค้ด และการแพตช์ช่องโหว่

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

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

 
GN⁺ 2 시간 전
ความคิดเห็นจาก Hacker News

  • พอลองตามลิงก์บั๊ก/เอ็กซ์พลอยต์ของ Pixel 9 ไป ก็เจอว่าฟีเจอร์ AI ทำให้ต้องถอดรหัสสื่อก่อนที่ผู้ใช้จะเปิดข้อความ จึงเพิ่ม พื้นผิวการโจมตีแบบ 0-click
    รู้สึกว่าเป็นบทเรียนที่เราน่าจะได้เรียนกันไปแล้ว ไม่ควรอ่าน SMS แล้วเอาไปประมวลผลอะไรทั้งที่ฉันไม่ได้ขอ

    • ผมไม่แน่ใจว่าจริง ๆ แล้ว บทเรียน ที่เราควรได้เรียนคืออะไรกันแน่
      ผู้ใช้เลือกโทรศัพท์ที่มีความสามารถด้านการส่งข้อความที่หลากหลาย บน iPhone นี่เป็นจุดขายใหญ่ผ่าน iMessage และต่อมา Android ก็ไล่ตามด้วย RCS
    • แค่นั้นยังไม่พอ ลองนึกถึงอีเมลไคลเอนต์ที่ไม่พาร์สภาพจนกว่าผู้ใช้จะโต้ตอบกับข้อความ แต่พอคุณคลิกแล้วรู้สึกว่ามันน่าสงสัย ตอนนั้นอุปกรณ์ที่ซับซ้อนและมีบั๊กเยอะก็ถูกรันไปแล้ว
      ส่วนตัวเรื่องที่เหลือเชื่อที่สุดคือ ครั้งหนึ่งผมกดทำเครื่องหมายข้อความที่น่าสงสัยมากและแทบจะแน่ใจว่ามีไฟล์แนบอันตราย ในเว็บเมลของ BigTech เจ้าหนึ่งเป็นสแปม เพราะมันไม่ใช่ฟิชชิงจึงไม่มีตัวเลือกอื่น แล้วมันก็ “ใจดี” เปิด ลิงก์ยกเลิกการสมัคร บนเบราว์เซอร์เครื่องผมเองโดยไม่ขออนุญาตเลย ยากจะจินตนาการว่าต้องไร้ความสามารถและระบบองค์กรล้มเหลวขนาดไหน ถึงจะเขียน รีวิว อนุมัติ และปล่อยฟีเจอร์แบบนั้นในบริบทที่อ่อนไหวต่อความปลอดภัยและความเป็นส่วนตัวได้
    • Google เป็นเจ้าของ Android ก็จริง แต่ Google ไม่ได้สนใจผู้ใช้ ลูกค้าของพวกเขาคือ ผู้ลงโฆษณา
      แม้แต่ 0-day ก็ไม่ได้สำคัญมากนัก ทางเลือกแทบมีแค่ iPhone และ Huawei ก็ใช้ได้แค่บางภูมิภาค เลยแทบไม่มีเหตุผลให้พวกเขาต้องใส่ใจ เราต้องการ OS มือถือและชั้นฮาร์ดแวร์ใหม่อย่างเร่งด่วน
    • เมื่อเร็ว ๆ นี้ผมฟังงานนำเสนอเรื่อง “AI Security” แล้วใจความประมาณว่า “เราจะกลืนอินพุตเข้าออกของ AI แบบไม่วิจารณ์อะไรเลย มันเป็นปัญหาความปลอดภัยก็จริง แต่ทำอะไรไม่ได้หรอก งั้นไปทำ post-processing เอา”
      ยังมีประโยคว่า “ถ้าผู้ไม่หวังดีอัปเดตเอกสารภายใน ก็อาจมีผลต่อ AI ได้” ซึ่งถ้า ผู้ไม่หวังดีอัปเดตเอกสาร ได้ นั่นก็แปลว่าถูกเจาะไปแล้ว เรื่องที่พูดไม่ใช่ระดับ “ก่อกวน Wikipedia”
    • การทำให้ผู้ใช้เปิดข้อความไม่ใช่อุปสรรคที่สูงอะไร
      ในมุมผู้ใช้ การที่ต้องระวังว่าควรเปิดข้อความไหนเป็นเรื่องที่ยอมรับได้ยาก เราเคยโยนความรับผิดชอบแบบนี้ให้ผู้ใช้กับไฟล์แนบอีเมลมาแล้ว และผลลัพธ์ก็เรียกได้ว่าเลวร้าย ไฟล์แนบอันตรายน่าจะเป็นช่องทางสำคัญที่สุดของการ กระจายมัลแวร์

  • พอเห็นข้อความว่า “นี่เป็นครั้งแรกที่บั๊กไดรเวอร์ Android ถูกแพตช์ภายใน 90 วันนับจากเวลาที่ผู้ขายรับรู้ช่องโหว่ครั้งแรก จึงถือว่าเร็วเป็นพิเศษ” ก็ทำให้มอง Google ดีขึ้น แต่ในขณะเดียวกันก็ทำให้ระบบนิเวศ Android ที่เหลือดูน่ากลัวขึ้น
    สงสัยว่า Apple ใช้เวลาตอบสนองนานแค่ไหน

    • ผู้ขาย Android มีชื่อเสียงเสียมานานเรื่องการอัปเดต สาเหตุหนึ่งที่คนพูดกันคือบริษัทมือถือพยายามสร้างความแตกต่างด้วยการ fork Android UI หลัก เพื่อใส่ฟีเจอร์เฉพาะแบรนด์และวิสัยทัศน์ UI สุดเพ้อฝันของตัวเอง
      แต่พอ Android เวอร์ชันใหม่แบบ stock ออกมา งาน ย้ายระบบ ก็เลยมหาศาล
    • ผมเคยรายงานบั๊กความปลอดภัยให้ Apple มาก่อน เป็นเรื่องเมื่อหลายปีก่อน แต่จำได้ว่าใช้เวลาประมาณ 6 เดือน กว่าจะมีแพตช์
      มีการไปกลับกันหลายรอบเพื่อทำ proof of concept ที่เสถียรกว่าเดิม และหลังจากส่ง proof of concept ที่ทำซ้ำได้ 100% แล้ว ก็น่าจะอีกราว 2 เดือน
    • พอเห็นว่า 42% ของอุปกรณ์ Android ยังไม่ได้แพตช์ [1] การตัดสินใจเผยแพร่งานวิจัยจนทำให้ทุกเครื่องเสี่ยงไปด้วยจึงน่าสนใจ
      [1] https://gs.statcounter.com/android-version-market-share
      [2] https://www.cybersecurity-insiders.com/survey-reveals-over-1...
    • ถ้าเป็นอุปกรณ์ Android จากแบรนด์ดัง ก็มักคาดหวังอัปเดตความปลอดภัยของ OS ได้ เพราะผู้ขายชั้นแรกเป็นคน build และ push เอง
      แต่ อัปเดตความปลอดภัยของไดรเวอร์และเฟิร์มแวร์ นั้นรับประกันยาก อัปเดตแบบนี้มักต้องมาจากซัพพลายเออร์ต้นน้ำ ซึ่งอาจจะมีหรือไม่มีความตั้งใจจะแก้ปัญหาก็ได้ แบรนด์เล็กหลายเจ้าขายเครื่อง Android ราคาถูกแล้วไม่อัปเดตอะไรเลย

  • เกี่ยวเนื่องกันนิดหน่อย ผมสงสัยว่าอัตราเอ็กซ์พลอยต์ที่ถูกเปิดเผยต่อสาธารณะเพิ่มขึ้นจริงไหม หรือแค่เพราะ AI กลายเป็นประเด็นเด่นทั้งในเครื่องมือโจมตีและป้องกัน เลยทำให้เห็นข่าวบ่อยขึ้น
    รู้สึกเหมือนวันเว้นวันจะมีอะไรใหม่ออกมาจาก Linux, Windows, มือถือ หรือเครื่องมือสามัญที่ทุกคนใช้

    • ถ้าอ่านตอนที่ 1 แบบจับนัยระหว่างบรรทัด จะเห็นว่าโค้ดที่เป็นปัญหาถูกเพิ่มเข้ามาเพราะ ฟีเจอร์ AI และเอ็กซ์พลอยต์ก็ถูกคนค้นพบ
      https://projectzero.google/2026/01/pixel-0-click-part-1.html
      ดังนั้นการใช้ AI กำลังเพิ่มจำนวนบั๊ก และมนุษย์ก็ต้องมาคัดมันออก
    • สุดสัปดาห์ที่แล้วผมลองวิเคราะห์เอง ในปี 2024 มี CVE ที่เปิดเผยราว 100 รายการต่อวัน และในเดือนเมษายนแตะประมาณ 200 รายการ ต่อวัน
      ถ้าย้อนไปก่อนปี 2023 วงรอบการเพิ่มขึ้นเป็นสองเท่าของ CVE ที่เปิดเผยจะอยู่ราว 4-4.5 ปี แต่หลังจากนั้นเหลือประมาณ 2 ปี เพิ่มขึ้นอย่างชัดเจนมาก
    • คนที่ดูแลงานด้านบั๊กความปลอดภัยของโอเพนซอร์สบอกว่ารายงานเพิ่มขึ้นมาก ตอนแรกส่วนใหญ่แทบจะเป็น รายงานคุณภาพต่ำ ปลอม ๆ แต่ตอนนี้รายงานที่ใช้ได้จริงก็เพิ่มขึ้นมากเช่นกัน
    • เป็นแค่การเดา และผมไม่ใช่นักวิจัยด้านความปลอดภัย แต่ดูเหมือน AI จะเป็นตัวเร่งที่ทั้งเพิ่มพื้นผิวโจมตีที่เอาไปใช้ประโยชน์ได้แต่คุณภาพต่ำ และในขณะเดียวกันก็เพิ่มความเร็วการทำงานของนักวิจัยความปลอดภัย
      คือถ้าใช้ดี ๆ มันเยี่ยมมาก แต่ถ้าใช้ไม่ดีมันก็แย่มากจริง ๆ
    • ช่วงไม่กี่สัปดาห์ที่ผ่านมา ผมรายงานปัญหาค่อนข้างร้ายแรงหลายเรื่องให้ผู้ขายเครื่องมือที่มีคนใช้แพร่หลาย แต่กว่าจะได้รับการยอมรับยากกว่าปกติ
      ได้ยินมาว่าทีมตอบสนองกำลังโอเวอร์โหลดจาก รายงานที่หลั่งไหลเข้ามา

  • อยากให้ใครสักคนช่วยยืนยันว่าผมคิดถูกไหม ผมใส่พรอมป์ต์ด้านล่างนี้แบบตรงตัวเข้าไปใน gpt 5.5 xhigh

    does this look right to you? don't do any searches or check memory, just think through first principles

static int vpu_mmap(struct file fp, struct vm_area_struct vm) { unsigned long pfn; struct vpu_core core = container_of(fp->f_inode->i_cdev, struct vpu_core, cdev); vm_flags_set(vm, VM_IO | VM_DONTEXPAND | VM_DONTDUMP); / This is a CSRs mapping, use pgprot_device */ vm->vm_page_prot = pgprot_device(vm->vm_page_prot); pfn = core->paddr >> PAGE_SHIFT; return remap_pfn_range(vm, vm->vm_start, pfn, vm->vm_end-vm->vm_start, vm->vm_page_prot) ? -EAGAIN : 0; }

    มันชี้ปัญหาได้ตรงเป๊ะโดยไม่ต้องค้นเว็บด้วยซ้ำ ผมอยากลองให้ครอบคลุมกว่านี้ เช่นใส่ทั้งก้อนของโค้ดเบสแทนที่จะเป็นแค่ฟังก์ชันเดียว ดูเหมือนมันจะมี ศักยภาพในการจับเอ็กซ์พลอยต์ความปลอดภัย ได้จริง ถ้าอย่างนั้นก็ยิ่งสงสัยว่าของแบบนี้ถูกปล่อยออกมาได้อย่างไรตั้งแต่แรก รู้ว่าเป็นตัวอย่างเล่น ๆ แต่อยากเรียนรู้เพิ่ม

    • นั่นไม่ใช่การทดสอบที่ยุติธรรม ถึงพรอมป์ต์จะไม่ได้สั่งให้หาบั๊กตรง ๆ แต่ก็ชี้นำโมเดลค่อนข้างแรง
      โดยพื้นฐานแล้วมันเหมือนข้อโต้แย้งที่โผล่มาในเธรดที่อ้างว่าโมเดลปัจจุบันเก่งพอ ๆ กับ mythos
    • ในเชิงเกร็ด ผมลองใส่ fragnesia.c กับแพตช์ที่ตามมาเพื่อแก้ปัญหา แล้วแม้จะไม่เจอช่องโหว่ใหม่เอี่ยม แต่มันเหมือนจะหา วิธีใหม่ 2 แบบ ที่ใช้ประโยชน์จากบั๊กรากเดียวกันได้
      เมื่อคิดว่าคนโง่ ๆ อย่างผมที่มีแค่ subscription ของ Claude ลองเล่นเอง ก็ถือว่าน่าประทับใจทีเดียว
    • แค่นี้ยังตัดสินไม่ได้ว่ามันใช้หาช่องโหว่ได้จริงหรือไม่ เพราะเราไม่รู้ว่าถ้าเอาไปรันกับโค้ดทั้งหมดแล้วจะมี false positive มากแค่ไหน
      พูดอีกแบบก็คืออาจเป็น https://en.wikipedia.org/wiki/Base_rate_fallacy
    • ผมสงสัยว่าคุณรู้ได้อย่างไรว่ามันไม่ได้ค้นเว็บ
    • ผมเอาโค้ดไปวางใน claude Opus 4.7 ที่ไม่มีการเข้าถึงอินเทอร์เน็ต แล้วขอให้มันอธิบายแค่ว่าฟังก์ชันนี้ทำอะไร มันก็อธิบายพร้อมชี้บั๊กด้วย โดยผมไม่ได้บอกให้หาบั๊ก

      Observations & Potential Issues
      A few things worth flagging:

      1. No bounds checking on the mapping size. Userspace controls vm_end - vm_start and vm->vm_pgoff. Here vm_pgoff is ignored entirely and the size is trusted blindly. If the VPU's register block is, say, 64KB but userspace requests a 1MB mapping, the driver will happily map 1MB of physical address space starting at core->paddr — potentially exposing whatever hardware happens to live at adjacent physical addresses. A defensive check would be:
        ถ้ายุคที่บอตสามารถสแกน PR ของทุกโปรเจกต์โอเพนซอร์สได้ทันทีที่ออกมาถึงจริง วงจรการออกรุ่น 70 วัน ก็คงไม่เร็วพอที่จะหยุดการใช้งานเอ็กซ์พลอยต์ในวงกว้างอีกต่อไป

  • เป็นรายงานบั๊กที่ยอดเยี่ยมมาก ผมไม่ใช่ผู้เชี่ยวชาญเคอร์เนลเลย แค่อ่านผ่าน ๆ มาบ้างเมื่อสิบกว่าปีก่อน แต่ก็ยังตามทันและเข้าใจว่าเกิดอะไรขึ้น
    ที่น่ากลัวคือมันเป็นบั๊กที่ร้ายแรงมากจริง ๆ และดูเหมือนไม่ต้องใช้ความพยายามมากนักในการหา เลยทำให้นึกไม่ออกว่ามีความเสี่ยงอะไรอีกซ่อนอยู่บ้าง อีกอย่างคือช่วงนี้ปัญหาความปลอดภัยหลายเรื่องถูกหาเจอด้วย AI และรายงานนี้ทำให้ผมคิดอยู่สองอย่าง ความเชี่ยวชาญยังมีมูลค่าสูงมาก และยิ่งเฉพาะทางก็ยิ่งมีค่า อีกทั้งยังมีพื้นที่เฉพาะทางอีกมากที่ AI ยังครอบงำไม่ได้

  • ไม่รู้ว่าการเจลเบรก iPhone หายไปไหน ผมไม่ได้เห็นอะไรเลยมานานมาก เกิดอะไรขึ้นกันแน่? สงสัยว่าผมพลาดข่าวไปเอง หรือว่ามันไม่มีอะไรที่ทำได้จริงแล้ว
    ไม่ว่า Apple จะทำอะไรอยู่ก็น่าทึ่งดี แต่อยากรู้ว่าจากแนวโน้มตอนนี้เป็นแค่เรื่องของเวลาหรือมีการเปลี่ยนแปลงอะไรจริง ๆ

    • ท่าทีด้านความปลอดภัยของ Apple ดีกว่า Android มากพอสมควร เพราะมี Lockdown Mode, memory tagging และ secure allocator
      อ่านบางส่วนได้ที่นี่: https://security.apple.com/blog/memory-integrity-enforcement...
    • ทุกวันนี้เอ็กซ์พลอยต์ที่อยู่รอดหลังรีบูตแทบเป็นไปไม่ได้แล้ว และเอ็กซ์พลอยต์ที่ทำให้เจลเบรกได้ตอนนี้ต้องการ เอ็กซ์พลอยต์เชน ครบชุด ซึ่งมีมูลค่าสูงมากและจะถูกแพตช์ทันทีที่เปิดเผย
      เพราะงั้นภาพการเจลเบรก iPhone แบบสมัยก่อนจึงแทบเป็นไปไม่ได้แล้ว
    • ผมหงุดหงิดมาตลอดที่ “การเจลเบรก” ไม่ถูกตรวจสอบยืนยันในระดับเดียวกับช่องโหว่ซอฟต์แวร์บนแพลตฟอร์มอื่น

  • มีหลักฐานไหมว่า AI ส่งผลต่อธุรกิจของบริษัทอย่าง NSO ยังไงบ้าง? สงสัยว่ามันทำให้พวกเขาไร้ประโยชน์ไปเลย หรือยิ่ง เพิ่มพลังแบบสุดขั้ว ให้พวกเขา

    • ไม่รู้รายละเอียด แต่คิดว่า AI กำลังเปลี่ยนเกมอย่างมาก และ “ทุน” จำนวนมากในรูปของ 0-day น่าจะหายไปแล้ว
      ถ้าเป็นอย่างนั้นก็น่าจะเป็นข่าวดีสำหรับทุกคน ยกเว้น NSO และบริษัททำนองเดียวกัน

  • ผมเคยเจอปัญหาคล้าย ๆ กันมาก่อน วิธีแก้ดูสมเหตุสมผล แต่ผมยังสงสัยเรื่อง ประสิทธิภาพที่อ้างว่าดีขึ้น

  • การปรับปรุง V4L2 เพื่อรองรับการถอดรหัสวิดีโอด้วยฮาร์ดแวร์ค้างรอการ merge มานานมาก และตอนนี้เหมือนจะเข้า mainline kernel แล้ว
    ดูเหมือนคนไม่อยากรอกันนานขนาดนั้น

  • น่าแปลกใจที่แม้แต่ Project Zero ก็ยังต้องรายงานบั๊กให้ Android ผ่านช่องทางปกติ และต้องรับมือกับการจัดระดับความร้ายแรงของ Android VRP
    ผมเคยคิดมาตลอดว่าพวกเขาคงเดินเข้าออฟฟิศ Android แล้วคุยต่อหน้าเพื่อโน้มน้าวเรื่องความสำคัญของบั๊กได้เลย

    • ถ้าพวกเขารู้สึกว่าวิธี “ปกติ” มันทรมานเกินไป บางทีสิ่งที่ Project Zero ลองทำต่อไปก็คงเป็นการแก้วิธีนั้นเอง
    • นั่นตั้งอยู่บนสมมติฐานว่า Android จะยอมฟัง Project Zero