การเจลเบรก 0day ครั้งสุดท้าย: Tachy0n

 (blog.siguza.net)
1 คะแนน โดย GN⁺ 2025-05-25 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • tachy0n คือกรณีการเผยแพร่ exploit สำหรับการเจลเบรกแบบ 0day รุ่นล่าสุด สำหรับ iOS 13.0~13.5
  • บั๊กนี้คือ race condition ของ system call lio_listio ที่ถูกเรียกว่า Lightspeed ซึ่งเป็นการใช้ช่องโหว่ kernel LPE (การยกระดับสิทธิ์)
  • มีหลายโปรเจ็กต์เจลเบรก เช่น Spice และ unc0ver ที่นำช่องโหว่นี้ไปใช้จริง และบทความนี้อธิบายทั้งวิธีใช้ช่องโหว่กับเทคนิคการแฮ็กประเด็นด้านการจัดการหน่วยความจำ
  • หลังจาก exploit นี้ถูกเปิดเผย Apple ได้ทั้ง ออกแพตช์และเพิ่ม regression test พร้อมเสริมความแข็งแกร่งของการแยก kernel object (เช่น Zone, kheap) และฟังก์ชันป้องกัน pointer อย่างมาก
  • ตั้งแต่ iOS 14 เป็นต้นมา สภาพแวดล้อมของการเจลเบรกและ kernel exploit เปลี่ยนไปโดยสิ้นเชิง จน ไม่มี kernel exploit ที่เปิดเผยสาธารณะอีกต่อไป

0. บทนำ

  • tachy0n เป็น exploit รุ่นเก่าที่ใช้ได้กับ iOS 13.0 ถึง 13.5
  • เมื่อวันที่ 23 พฤษภาคม 2020 มีการเผยแพร่เป็น 0day ใน unc0ver v5.0.0 และ Apple ก็ออกแพตช์ฉุกเฉินภายในเวลาเพียง 1 สัปดาห์
  • ช่องโหว่นี้เคยถูกนำไปใช้ในฐานะ 1day มาก่อนแล้ว จึงถือเป็นกรณีศึกษาที่มีความหมายในแง่เทคนิคของ exploit
  • บทความนี้อธิบายอย่างละเอียดทั้งซอร์สของช่องโหว่และที่มาของการค้นพบ

1. Lightspeed

  • ช่องโหว่นี้คือ บั๊ก Lightspeed (CVE-2020-9859 เป็นต้น) ที่ Synacktiv เผยแพร่ โดยเกิดปัญหา race condition ระหว่างการคืนหน่วยความจำของ asynchronous I/O context ใน syscall lio_listio
  • สามารถควบคุมจังหวะของ I/O operation เพื่อสร้างเงื่อนไข double free ของหน่วยความจำ และใช้การ free object สองครั้งเพื่อซ้อนหลาย object ลงบนพื้นที่หน่วยความจำเดียวกัน
    • exploit ใช้โครงสร้างการจัดสรรหน่วยความจำแบบไดนามิกในโซน kalloc.16 ของเคอร์เนล
    • โดยแก่นแท้แล้วคือการทำ race ซ้ำหลายครั้งเพื่อเพิ่มโอกาสสำเร็จ

2. Spice

  • exploit นี้เคยถูกใช้ในเจลเบรก Spice ที่ทีม Jake Blair สร้างขึ้นในอดีต
  • มีการทำ exploit คนละสายพันธุ์ใน racoon และในแอป โดยเป้าหมายหลักคือ การปลอม mach port
  • ในยุค iOS 11.x การ bypass PAN (Protection Against Null dereference) ยังทำได้ง่าย และมีการลองใช้เทคนิคแฮ็กหลากหลายแบบร่วมกับ kernel infoleak และ sandbox escape
  • สำหรับ racoon นั้น เนื่องจากมีข้อจำกัดในการเข้าถึง IOKit จึงใช้ OSUnserializeXML เพื่อสร้าง object เป้าหมายสำหรับการ spray ในโซนของเคอร์เนล
  • ยังอธิบายความแตกต่างเชิงรายละเอียดและพัฒนาการทางเทคนิคในเวลาต่อมา เช่น sysctl_procargsx, kernel uninitialized memory leak และนโยบาย sandbox

3. unc0ver

  • ในช่วงที่นำไปใช้กับ unc0ver โครงสร้างของ exploit ถูกออกแบบให้ทำงานได้บน SoC หลากหลายรุ่น ตั้งแต่ A8 ถึง A13
  • มีการติดตามการซ้อนและการ overlap ของ OSData object แล้ว free/allocate object ที่ต้องการในจังหวะเหมาะสมเพื่อควบคุมพื้นที่หน่วยความจำ
  • ใช้ kernel object เช่น IOMemoryDescriptor เพื่อเปิดเผยที่อยู่ของ data buffer ที่ผู้ใช้ควบคุมได้ และทำให้เคอร์เนลสามารถอ่าน/เขียนได้โดยตรง
  • มีการอาศัยจุดอ่อนของนโยบายตัวจัดสรรหน่วยความจำของเคอร์เนลใน iOS 13 อย่างเหมาะสม เช่นการ bypass zone_require
  • สามารถดูรายละเอียดการทำงานของ exploit ทั้งหมดได้จาก GitHub repository สาธารณะ (tachy0n)

4. ผลกระทบต่อเนื่อง

  • การเปิดเผย 0day exploit สร้างแรงสั่นสะเทือนอย่างมากทั้งต่อชุมชนความปลอดภัยและ Apple
    • เพียง 4 ชั่วโมงหลังมีการเผยแพร่ exploit จริง Project Zero และ Synacktiv ก็ได้วิเคราะห์รายละเอียดและตอบสนองต่อเรื่องนี้แล้ว
  • หลังการแพตช์ Apple ได้เพิ่ม regression test อย่างเป็นทางการสำหรับช่องโหว่นี้ลงใน XNU และเปลี่ยนทิศทางไปสู่ การเสริมยุทธศาสตร์ความปลอดภัยในระดับรากฐาน
  • ตั้งแต่ iOS 14 เป็นต้นมา มีการเปลี่ยนแปลงครั้งใหญ่ที่ทำให้การสร้าง exploit ยากขึ้นมาก เช่น การแยกพื้นที่ allocation, object secure guard, PAC (pointer authentication code), โครงสร้าง kheap
  • ตอนนี้กลยุทธ์ของ exploit เองกลายเป็นสิ่งสำคัญยิ่งกว่าเดิม และช่องว่างระหว่างข้อมูลสาธารณะกับงานวิจัยที่ไม่เปิดเผยก็ยิ่งกว้างขึ้น จนสำหรับ iOS 17~18 แทบไม่มี kernel exploit ที่เปิดเผยต่อสาธารณะเลย

5. บทสรุป

  • นี่เป็นกรณีศึกษาที่แสดงให้เห็นอย่างชัดเจนว่าแวดวงความปลอดภัย iOS และการเจลเบรก เปลี่ยนแปลงอย่างมากในช่วง 5 ปี
  • ให้มุมมองเชิงลึกว่าชุมชนเจลเบรก/เอ็กซ์พลอยต์ นักวิจัย และทิศทางเทคโนโลยีของ Apple เปลี่ยนไปอย่างไร
  • ยุคที่มีการแบ่งปัน IL และร่วมกันท้าทายข้อจำกัดได้กลายเป็นอดีตไปแล้ว และหลัง iOS 14 เป็นต้นมา การแบ่งปันข้อมูล exploit ก็ลดลงอย่างเห็นได้ชัด

อ้างอิงและติดต่อ

  • ซอร์สโค้ดที่เกี่ยวข้องและข้อมูลโดยละเอียดเพิ่มเติมสามารถดูได้ที่ เว็บไซต์ส่วนตัวของ Siguza และ GitHub repository สาธารณะ

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

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

 
ndrgrd 2025-05-26

ฮาร์ดแวร์ของ Apple นั้นยอดเยี่ยมก็จริง แต่ซอฟต์แวร์กลับเต็มไปด้วยเจตนาที่จะล่ามผู้ใช้ไว้
ต่อให้แค่อยากให้แอปที่ตัวเองสร้างและบิลด์ขึ้นมาทำงานได้เฉพาะบนอุปกรณ์ของตัวเอง ก็ยังต้องมีค่าสมาชิกราคา 100 ดอลลาร์

ถ้าคุณเป็นนักพัฒนาที่ใช้แอปโอเพนซอร์สขนาดเล็กถึงกลางและบิลด์ใช้เอง
บนอุปกรณ์ของ Apple แค่จะ sideload ก็ต้องเจลเบรกด้วยการอาศัยช่องโหว่ แบบนั้นใช้ Android ไปเลยยังสะดวกกว่า
 
GN⁺ 2025-05-25
ความคิดเห็นบน Hacker News
  • ผมคิดว่าจุดสำคัญที่เขาเอาชนะบริษัทยักษ์ใหญ่อย่าง Apple ได้คือการเน้นงานที่เรียบง่ายแต่น่าเบื่อและต้องทำซ้ำ นั่นคือ regression testing
    มีการกล่าวถึงว่า SockPuppet เคยถูกใช้กับการเจลเบรกในยุค iOS 12 มาก่อน และแม้หลังจากที่ Ned Williamson แห่ง Project Zero รายงานให้ Apple จนถูกแพตช์ใน iOS 12.3 แล้ว มันก็กลับมาโผล่อีกครั้งใน iOS 12.4
    น่าจะเป็นเพราะ Apple แยก fork ของ XNU ออกเป็นอีก branch แล้วทำให้แพตช์นั้นตกหล่นไป และปัญหาใหญ่จริง ๆ คือแทบไม่มี regression test สำหรับช่องโหว่ทั้งใหม่และเก่าเลย
    ผมลองเอาช่องโหว่ 1-day ที่รู้จักอยู่ไม่กี่ตัวมาทำ automation สำหรับ regression test แล้วรันดู ก็พบช่องโหว่กลับมาได้สำเร็จทันที
    เลยสงสัยว่าในโครงการโอเพนซอร์สต่าง ๆ อย่าง Linux, FreeBSD, OpenWRT, OpenSSH ฯลฯ มีการเอา regression test ของช่องโหว่เก่าไปรันกับเวอร์ชันใหม่ด้วยหรือเปล่า
    ถ้าสามารถเขียนแต่ละช่องโหว่ให้อยู่ในรูปแบบอัตโนมัติ และมีทรัพยากรพอจะรันใน CI ได้ ก็น่าจะคุ้มมาก
  • ย้ำว่า regression test หรือการตรวจไม่ให้บั๊กที่แก้ไปแล้วกลับมาอีก เป็นขั้นตอนมาตรฐานของ QA
    เล่าประสบการณ์สมัยเรียนมหาวิทยาลัยเมื่อ 20 ปีก่อนที่เคยเป็นอาสาสมัครทำ QA ให้ Mozilla และมีกรณีทดสอบ regression อยู่หลายร้อยแบบ
    ส่วนใหญ่เป็นบั๊กด้าน rendering/layout และ JS engine และถ้าทำ test case แบบย่อส่วนได้ ก็เอาเข้า CI pipeline ได้ทันที
    บั๊กใหม่อาจหลีกเลี่ยงไม่ได้ แต่ถ้าบั๊กที่เคยแก้แล้วกลับมาอีก นั่นคือการเสียเวลาและต้นทุนโดยเปล่าประโยชน์ และองค์กรที่ใส่ใจคุณภาพต้องลงทุนกับ regression test อย่างมาก
    น่าเสียดายที่ยังมีหลายองค์กรที่มองข้าม QA หรือแก้ด้วยการจ้างภายนอกอย่างเดียวโดยไม่ใส่ใจจริงจัง
    จึงไม่เข้าใจว่า Apple ไม่มี regression test เกี่ยวกับการเจลเบรกได้อย่างไร
    แต่ก่อนที่ Mozilla และที่อื่น ๆ มีการสร้างสภาพแวดล้อม QA และ CI/CD ที่ยอดเยี่ยมด้วยเครื่องมืออย่าง Tinderbox และ Bugzilla และเคยคิดว่าวิธีแบบนี้เป็นเรื่องปกติมาตั้งแต่ก่อนคำว่า DevOps จะดังเสียอีก แต่ภายหลังก็เพิ่งรู้ว่าไม่ใช่แบบนั้นจริง ๆ
  • มีการยกตัวอย่างโครงการโอเพนซอร์สแห่งหนึ่ง แม้จำชื่อไม่ได้ แต่มี test case สำหรับทุก issue
    มี test case นับพันรายการ และน่าจะเป็น Sqlite
    เสริมว่าถ้าไม่ backport แพตช์ ก็มักมีโอกาสสูงที่จะไม่ backport test นั้นไปด้วย
  • ต้นตอของปัญหาคือหลายองค์กรแยกประเด็นความปลอดภัยออกไปเป็น workflow คนละชุดและมองเป็นบั๊กคนละประเภท
    สุดท้ายก็คือ Conway's law ยังใช้ได้ตรง ๆ ระหว่างงานด้าน security กับการพัฒนาฟีเจอร์
    ดังนั้นแม้องค์กรจะมี regression test ในขั้นตอน build/release ดีแค่ไหน แต่ด้วยโครงสร้างภายในก็ยังมีโอกาสที่ issue ด้าน security จะหลุดออกไป
  • สำหรับคำถามที่ว่า “มีโครงการอื่นทำ regression test แบบนี้ไหม”
    มีความเห็นว่าหน่วยข่าวกรองของรัฐ (G10, รัสเซีย, จีน, เกาหลีเหนือ ฯลฯ) และกลุ่มเอกชนจำนวนมาก คงทำ regression test ของช่องโหว่ด้วยวิธีนี้กันตามปกติอยู่แล้ว
  • ผมไม่ใช่นักวิจัยด้าน security แต่กรณีนี้ทำให้รู้สึกอินมากในระดับส่วนตัว
  • ต่อประเด็น “ลืมความรู้เรื่อง heap separation และ mitigation เทคนิคต่าง ๆ ไปให้หมด”
    มีการเปรียบเหมือนตอนคุยภาษาต่างประเทศกับเพื่อนอยู่ดี ๆ แล้วอีกวินาทีถัดไปบทสนทนากระโดดไปเรื่องเฉพาะทางอย่างศัลยกรรมสมองหรือฟิสิกส์นิวเคลียร์ จนสมองว่างเปล่า
    ทำให้นึกถึงตอนเคยพยายามล่ามบทสนทนาเกี่ยวกับการซ่อมโรงถลุงเหล็ก
    รู้สึกเสียดายที่โลกยุคนี้แทบไม่มีการเจลเบรกแล้ว แม้ตัวเองจะไม่ได้ใช้ iPad ที่เจลเบรกให้เกิดประโยชน์อะไรมาก แต่ก็สนุกกับมันในตัวเอง
    ถ้าเป็นตอนนี้ก็อยากติดตั้งแอป tethering หรือ UTM และโซลูชัน JIT
    SideStore ดูมีอนาคตดีจึงอยากลองใช้ แต่บัญชี Apple ของผมเคยเป็นบัญชีนักพัฒนาแบบเสียเงิน และยังมี app ID 10 ตัวที่ยังไม่หมดอายุ เลยติดข้อจำกัดในการติดตั้งแอปแบบนั้น
    ต้องสร้างบัญชีใหม่หรือไม่ก็จ่ายเงินอีกครั้งถึงจะทำได้
  • ผมเคยเจลเบรก iPhone 4 เครื่องเก่าของตัวเองแล้วใช้งานอยู่พักหนึ่ง
    ถ้าไม่มีการเจลเบรก ก็ไม่มีเหตุผลเลยที่จะใช้ iPhone เป็นเครื่องหลัก สุดท้ายจึงย้ายไป Android
    ตอนนั้น Android ก็เริ่มตามฟีเจอร์พื้นฐานทันมากแล้ว
  • ได้ยินมาว่าตอนนี้ Apple จ่ายรางวัลถึงหนึ่งล้านดอลลาร์สำหรับการเจลเบรก และอธิบายว่านี่คือราคาขั้นต่ำที่ตลาดตั้งไว้
  • จริง ๆ แล้วเพดานราคานี้ถูกทำลายไปตั้งแต่ปี 2015 แล้ว และมีการแชร์บทความกรณี 1 ล้านดอลลาร์
  • สงสัยว่าถ้าเจลเบรกสำเร็จแล้วอยากติดต่อ Apple เพื่อรับเงินรางวัลหลายล้านดอลลาร์ ต้องติดต่ออย่างไร
    ต้องผ่านนายหน้าคนกลางหรือไม่ มีอีเมลหรือช่องทางอย่างเป็นทางการหรือเปล่า และจะมีความเสี่ยงที่เรื่องจะไปจบอยู่แค่ฝ่ายซัพพอร์ตด่านแรกไหม
  • นี่ก็คือราคาตลาดในทางปฏิบัติ และมีการแชร์ลิงก์บทความที่เกี่ยวข้อง เงินรางวัลซีโรเดย์ของ Zerodium
  • ถ้ากลยุทธ์ของ Apple ถูกต้อง ก็แปลว่า Apple ปิดทุกวิธีในการได้สิทธิ์ root ทำให้นักพัฒนาเจลเบรกยังคงหาช่องโหว่ให้ Apple ฟรี ๆ อยู่ดี
  • แต่ในความเป็นจริงไม่ใช่แบบนั้น
    อย่างที่บทความบอกไว้ ทุกวันนี้ในคอมมูนิตี้ส่วนตัวยังคงมีการครอบครองช่องโหว่อยู่ และ Apple ก็ยังคงแพตช์ต่อไป
    มีเพียงการเจลเบรกที่เผยแพร่สู่สาธารณะเท่านั้นที่ลดลง
  • มีความเห็นว่าต่อให้ความหมายของคำในบริบทนี้ต่างออกไป อย่างน้อยก็น่าจะพอเข้าใจได้ว่าสแลงนั้นหมายถึงอะไร
  • อาจคิดว่าตัวเองเป็นคนบัญญัติคำนี้ขึ้นมา แต่จริง ๆ แล้วมีตัวอย่างที่ ถูกใช้เป็นสแลงมาก่อนแล้ว