เชนช่องโหว่คำเชิญ Calendar แบบ Zero-Click บน macOS

 (medium.com/@mikko-kenttala)
1 คะแนน โดย GN⁺ 2024-09-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ข้อบกพร่องในการประมวลผลไฟล์แนบคำเชิญของ macOS Calendar ทำให้ผู้โจมตีสามารถ เขียนและลบไฟล์ใดๆ ภายใน sandbox ของ Calendar ได้ และปัญหานี้นำไปสู่เชนการรันโค้ดจากระยะไกลและการเข้าถึงข้อมูล Photos
  • ขั้นที่ 1 CVE-2022-46723 เกิดจากการไม่ทำความสะอาดอินพุตแบบ path traversal เช่น FILENAME=../../../PoC.txt ในส่วน ATTACH อย่างถูกต้อง ทำให้ไฟล์แนบอาจถูกบันทึกไว้นอกตำแหน่งที่ตั้งใจไว้
  • เชนการรันโค้ดจากระยะไกลใช้พฤติกรรม Open File ของ Calendar ระหว่างการอัปเกรดจาก Monterey ไปเป็น Ventura เพื่อฉีดไฟล์หลายไฟล์ และผสมผสาน DMG, การเมานต์ SMB และ custom URL scheme
  • ในขั้น Photos มีการใช้ defaults import เพื่อใช้การตั้งค่าที่เป็นอันตราย เปลี่ยน System Photo Library เป็น /var/tmp/mypictures/Syndication.photoslibrary และทำให้รูปภาพต้นฉบับจาก iCloud ถูกซิงก์ไปยังไดเรกทอรีที่ไม่ได้รับการป้องกันด้วย TCC
  • Apple แก้ไขช่องโหว่ที่เกี่ยวข้องทั้งหมดระหว่างเดือนตุลาคม 2022 ถึงกันยายน 2023 โดยช่องโหว่ Photos ถูกจัดการเป็น CVE-2023-40434 และการ bypass Gatekeeper เป็น CVE-2023-40433

Path traversal ของไฟล์แนบ Calendar

  • คำเชิญ Calendar ที่เป็นอันตรายสามารถมีไฟล์แนบได้ และเนื่องจากการตรวจสอบชื่อไฟล์แนบไม่เพียงพอ จึงสามารถทำ directory traversal ได้
  • ผู้โจมตีสามารถระบุพาธใดๆ ในส่วน ATTACH เช่น FILENAME=../../../PoC.txt
    • ตำแหน่งบันทึกปกติคือ ~/Library/Calendar/[CalendarID]/Attachments/[eventid]/
    • ในพฤติกรรมที่มีช่องโหว่ ไฟล์จะถูกบันทึกเป็น ~/Library/Calendar/PoC.txt
  • หากมีไฟล์ชื่อเดียวกันอยู่แล้ว ไฟล์ใหม่จะถูกบันทึกเป็น PoC.txt-2 แต่ต่อมาเมื่ออีเวนต์หรือไฟล์แนบที่ผู้โจมตีส่งมาถูกลบ ไฟล์ PoC.txt ชื่อเดิมอาจถูกลบออกไปด้วย
  • พฤติกรรมนี้ยังสามารถใช้เพื่อลบไฟล์ที่มีอยู่ภายใน sandbox ของ Calendar บนระบบไฟล์ได้
  • ช่องโหว่นี้มีอยู่ในอย่างน้อย macOS Monterey 12.5 เวอร์ชันล่าสุด และยืนยันแล้วว่า macOS 13.0 beta4 ไม่ได้มีช่องโหว่นี้อีกต่อไป

เชนที่ขยายไปสู่การรันโค้ดจากระยะไกล

  • ช่องโหว่ที่พบก่อนการเปิดตัว macOS Ventura ไม่นาน ถูกขยายไปเป็นการรันโค้ดจากระยะไกลโดยใช้กระบวนการอัปเกรดเวอร์ชันและฟีเจอร์ Open File ของ Calendar
  • ผู้โจมตีฉีดไฟล์หลายไฟล์ผ่านช่องโหว่เขียนไฟล์ใดๆ ของ Calendar และจัดโครงสร้างให้เชน RCE ทำงานเมื่ออัปเกรดจาก Monterey ไปเป็น Ventura

  • โครงสร้างไฟล์ที่ฉีดเข้าไป

    • 000Hacked-$RANDOM.calendar
      • มีข้อมูล Calendar ที่ดูเหมือน Calendar “Siri Suggested”
      • รวมอีเวนต์ซ้ำและฟังก์ชันการแจ้งเตือน และทำงานโดยเปิดไฟล์อื่นที่ถูกฉีดเข้าไป
    • CalendarTruthFileMigrationInProgress
      • เป็นไฟล์ที่ทำให้ Calendar เดิมถูกอัปเกรดและรวมจากรูปแบบเก่าไปยังฐานข้อมูลใหม่
    • CalPoCInit.dmg
      • ทำให้การแจ้งเตือน Calendar ครั้งแรกเปิด ~/Library/Calendars/CalPoCInit.dmg
      • Bookmark ใน .DS_Store ภายใน DMG มีการอ้างอิงภาพพื้นหลังจากเซิร์ฟเวอร์ Samba ภายนอก
      • แม้ตัว CalPoCInit.dmg เองจะอยู่ในสถานะ quarantine แต่การเมานต์จะเกิดขึ้นโดยไม่มี quarantine flag
    • stage1.url
      • ทำให้การแจ้งเตือน Calendar ครั้งที่สองเปิด ~/Library/Calendars/stage1.url
      • ไฟล์นี้มี URL file:///Volumes/CalPoCPayload/MyMidiTest.app ที่ชี้ไปยังแอปในโวลุ่ม Samba ที่ถูกเมานต์ในขั้นก่อนหน้า
      • เมื่อ Finder เปิด /Volumes/CalPoCPayload/ การทำดัชนีจะเกิดขึ้นโดยอัตโนมัติ และ MyMidiTest.app จะถูกทำดัชนี
      • Info.plist ของ app bundle ลงทะเบียน handler สำหรับ custom URL scheme ชื่อ mymiditest
    • stage2.url
      • ทำให้การแจ้งเตือน Calendar ครั้งที่สามเปิด ~/Library/Calendar/stage2.url
      • ไฟล์นี้อ้างถึง mymiditest:// เพื่อรันแอปที่เป็นอันตรายโดยไม่ต้องมีการโต้ตอบจากผู้ใช้

การ bypass Gatekeeper และการรันแอป

  • เหตุผลที่ mymiditest:// รันได้คือแอปอยู่ภายใน Samba mount ที่ exploit สร้างขึ้น และตำแหน่งดังกล่าวไม่มี quarantine flag
  • แอป mymiditest เขียนไฟล์ที่จำเป็นสำหรับขั้นที่ 3 ลงใน /var/tmp/ และรันสคริปต์ใน Terminal ด้วย open /var/tmp/PhotosPoC.sh
  • เชนทั้งหมดถูกออกแบบให้ฉีดไฟล์หลายไฟล์เพื่อหลุดจาก sandbox ของ Calendar, bypass มาตรการลดผลกระทบของ Gatekeeper ด้วยทริก SMB แล้วจึงรันโค้ดใดๆ

การเข้าถึงรูปภาพ iCloud ผ่านการเปลี่ยนการตั้งค่า Photos

  • ขั้นหลังจากการรันโค้ดจากระยะไกลมุ่งเน้นไปที่การเปลี่ยนการตั้งค่า Photos เพื่อเข้าถึงข้อมูลรูปภาพที่ละเอียดอ่อนของผู้ใช้ โดยเฉพาะ iCloud Photos
  • โดยทั่วไป TCC ควรจำกัดการเข้าถึงไฟล์ที่ละเอียดอ่อนอย่าง Photos แต่เมื่อเปลี่ยนการตั้งค่า Photos ได้ System Photo Library ก็สามารถชี้ไปยังพาธที่ไม่ได้รับการป้องกันด้วย TCC ได้
  • ผู้โจมตีสามารถสร้างไฟล์การตั้งค่า Photos ที่ใช้ System Photo Library อื่น และนำเข้าไฟล์นั้นด้วย defaults import
  • ในเชน PoC ขั้นที่ 2 จะเตรียมการตั้งค่าที่ใช้ /var/tmp/mypictures/Syndication.photoslibrary เป็น System Photo Library โดยอัตโนมัติ
    • ไฟล์การตั้งค่าที่เป็นอันตรายที่เกี่ยวข้องถูกสร้างใน /var/tmp/mypictures/*.plist
    • ปิดแอปพลิเคชันที่เกี่ยวข้องกับ Photos ที่กำลังทำงานอยู่
    • การตั้งค่าเดิมถูกสำรองไว้ที่ /var/tmp/mypictures/*-orig.plist
    • การตั้งค่าที่เป็นอันตรายถูกนำเข้าจาก /var/tmp/mypictures/
    • ไลบรารีรูปภาพใหม่ถูกเปิดใน Photos ด้วย open /var/tmp/mypictures/Syndication.photoslibrary
  • Syndication.photoslibrary เป็นไลบรารีเทมเพลตว่าง และเมื่อ Photos ทำงานโดยใช้เป็น System Photo Library ใหม่ การซิงก์ iCloud จะถูกเปิดใช้งานและไฟล์ต้นฉบับจะถูกดาวน์โหลดไปยังไดเรกทอรีที่ไม่มีการป้องกัน
  • ไฟล์ที่ซิงก์ลงดิสก์ถูกคัดลอกไปยังไดเรกทอรีใหม่ภายใต้ /var/tmp/PoCLoot$RANDOM/
  • PoC สามารถแก้ไขเล็กน้อยเพื่อคัดลอกข้อมูลไปยังรีซอร์สภายนอก หรือโพสต์ไปยังเว็บเซิร์ฟเวอร์ภายนอกด้วยคำสั่ง curl ได้

กำหนดการแก้ไขและประเด็น bounty ที่เหลืออยู่

  • เชนทั้งหมดต้องข้ามกำแพงความปลอดภัยของ macOS ตามลำดับ
    • ฉีดไฟล์หลายไฟล์เข้า Calendar เพื่อ bypass sandbox และเปิดใช้งานขั้นถัดไป
    • bypass มาตรการลดผลกระทบของ Gatekeeper ด้วยทริก SMB เพื่อรันโค้ดใดๆ
    • bypass การป้องกัน TCC เพื่อเข้าถึงข้อมูลละเอียดอ่อน เช่น iCloud Photos
  • ก่อนการแก้ไข สามารถส่งคำเชิญ Calendar ที่เป็นอันตรายไปยัง ผู้ใช้ Apple iCloud และขโมย iCloud Photos ได้โดยไม่ต้องมีการโต้ตอบจากผู้ใช้
  • Apple แก้ไขช่องโหว่ที่เกี่ยวข้องทั้งหมดระหว่างเดือนตุลาคม 2022 ถึงกันยายน 2023

  • ไทม์ไลน์

    • 2022-08-08: รายงานการเขียนและลบไฟล์ใดๆ ภายใน sandbox ของ Calendar
    • 2022-10-24: แก้ไขใน macOS Monterey 12.6.1 และ Ventura 13
      • รายการนี้ไม่มี CVE และ Ventura beta3 มีช่องโหว่
    • 2022-11-14: ส่ง PoC ที่ขยายช่องโหว่ Calendar ไปเป็นการรันโค้ดใดๆ และการ bypass Gatekeeper
    • 2022-12-04: ส่ง PoC การเข้าถึง iCloud Photos
    • 2023-02-20: เพิ่มเครดิตและ CVE CVE-2022-46723 ให้กับช่องโหว่ Calendar
    • 2023-03-27: การ bypass Gatekeeper ถูกแก้ไขใน macOS Ventura 13.3
      • ณ เวลานี้ยังไม่มี CVE หรือเครดิต
    • 2023-09-26: ช่องโหว่ Photos CVE-2023-40434 ถูกแก้ไขและให้เครดิต
    • 2023-10-09: ประกาศ bug bounty ที่เกี่ยวข้องกับการ bypass Gatekeeper และช่องโหว่ Photos
    • 2023-12-21: ให้เครดิต CVE-2023-40433 แก่การ bypass Gatekeeper
    • 2024-09-12: ยังคงไม่มี bounty สำหรับช่องโหว่เขียนและลบไฟล์ใดๆ ของ Calendar เดิม CVE-2022-46723
    • อัปเดต 2024-10-20: Apple ตัดสินว่าไม่เข้าเกณฑ์ bounty เนื่องจากช่องโหว่เขียนและลบไฟล์ใดๆ ของ Calendar CVE-2022-46723 กระทบเฉพาะ macOS Monterey และ Ventura ไม่มีปัญหานี้ตั้งแต่ช่วง beta แล้ว

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

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

 
GN⁺ 2024-09-14
ความคิดเห็นบน Hacker News

  • โชคดีที่ไม่ได้ใช้ iCloud Photo Library แต่ก็น่าแปลกที่ถ้าเปลี่ยนตำแหน่งคลังรูปภาพแล้วตำแหน่งใหม่กลับไม่ได้รับการป้องกันใด ๆ
    ผมคาดไว้ว่าเมื่อกำหนด /var/tmp/mypictures/Syndication.photoslibrary เป็นคลังรูปภาพของระบบแล้วเปิด Photos แอป Photos ควรจะปกป้องไดเรกทอรีนี้ ดังนั้น exploit น่าจะล้มเหลว
    ลองทดสอบอย่างเร็วบน Sonoma 14.6.1 โดยกดปุ่ม Option ค้างไว้แล้วเปิด Photos เพื่อสร้างคลังรูปภาพใหม่ใน ~/Pictures พบว่าแอปที่ไม่มีสิทธิ์ Full Disk Access หรือสิทธิ์ Photos จะถูกปฏิเสธการเข้าถึงโฟลเดอร์นั้น
    แต่ถ้าสร้างคลังรูปภาพใหม่ใน /tmp แอปเดิมกลับเข้าถึงได้ พฤติกรรมนี้ ชวนสับสนและไม่สม่ำเสมอ
    ถ้า Apple จะรองรับฟีเจอร์การย้ายคลังรูปภาพไปไว้ที่ใดก็ได้ในระบบไฟล์จริง ๆ ก็ควรใช้การป้องกันให้ถูกต้องด้วย

    • ก็พอเข้าใจได้ในระดับหนึ่ง /tmp ตามประวัติศาสตร์แล้วเป็นตำแหน่งในลำดับชั้นไดเรกทอรีที่ใคร ๆ ก็อ่านและเขียนได้ และไม่ใช่ตัวเลือกที่ดีสำหรับเก็บ ข้อมูลส่วนตัว
    • TCC ก็แปลก ๆ และมี ช่องโหว่เยอะ แบบนี้มาตั้งนานแล้ว
    • บน Linux ตอนนี้แยกทุกอย่างออกจากกันได้ง่ายกว่า macOS มาก
      แม้ไม่ใช้ AppArmor หรือ Firejail บริการส่วนใหญ่ก็จะได้รับ ไดเรกทอรีชั่วคราวเฉพาะของตัวเอง เป็นค่าเริ่มต้น

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

    • ไม่ใช่เลย เพราะ ทีม product security ที่สืบสวนและจ่าย bug bounty ของ Apple นั้นบริหารจัดการแย่และไม่มีประสิทธิภาพ
      เมื่อไม่นานมานี้ย้ายจากสำนักงานโปรแกรม SWE ไปอยู่ SEAR (security engineering & arch) และผู้จัดการก็เพิ่งถูกไล่ออกแล้วย้ายไป AirBNB
      สมาชิกทีมส่วนใหญ่เป็นระดับบัณฑิตจบใหม่อย่าง ICT2·ICT3 เป็นคนที่คงไม่ผ่านสัมภาษณ์เขียนโค้ดของที่อื่นในบริษัทด้วยซ้ำ และส่วนใหญ่ทำงานเหมือนคนคัดแยกบั๊ก
      ใช้เวลาไปคอนเฟอเรนซ์และคลุกคลีกับแฮกเกอร์มากกว่านั่งทำงานหน้าคอมพิวเตอร์
      กราฟในพอร์ทัล ‘กำลังสืบสวน’ มีแต่สูงขึ้นเรื่อย ๆ คืออีเมลมีแต่ทับถม และไม่มีแม้แต่ความพยายามจะตามงานให้ทัน
      คนที่ควรได้เงินรางวัลแต่ไม่ได้รับ หากอยากเห็นความคืบหน้า ต้องไปกดดัน Ivan หัวหน้า SEAR แบบเปิดเผยบน Twitter
    • อาจจะใช่ก็ได้ โปรแกรม bug bounty ที่ย่ำแย่ของ Apple อาจเป็นผลจากความไร้ความสามารถ ไม่ใช่เจตนาร้าย
      แต่สำหรับนักวิจัยด้านความปลอดภัยหรือสาธารณชน เรื่องนั้นสำคัญไหม? ไม่เลย ไม่ว่าจะพังเพราะอะไร Apple ก็ควรแก้ โปรแกรมรางวัล ของตัวเอง
      ท้ายที่สุด บล็อกโพสต์นี้ก็เป็นเพียงอีกหนึ่งตัวอย่างที่ถูกโยนขึ้นไปกองรวมกับตัวอย่างกองใหญ่อยู่แล้ว[1][2][3][4][5]
      1: https://arstechnica.com/information-technology/2021/09/three...
      2: https://mjtsai.com/blog/2021/07/13/more-trouble-with-the-app...
      3: https://medium.com/macoclock/apple-security-bounty-a-persona...
      4: https://theevilbit.github.io/posts/experiences_with_asb/
      5: https://shail-official.medium.com/accessing-apples-internal-...
    • ถ้าไม่ได้หมายความว่าผู้เขียนบิดเบือนสถานการณ์ ผมก็นึกไม่ออกว่าจะมี “เหตุผลที่ดีมาก” อะไรได้ ในเมื่อมีบันทึกชัดเจนว่ามีคนรายงานบั๊กนี้มาตั้งนานก่อนที่มันจะถูกแก้
      มองในแง่ดีก็คงเป็น ระบบราชการที่เชื่องช้า แบบเดิม ๆ และนั่นก็ไม่ใช่เหตุผลที่ดีนัก
      ถ้าบริษัทส่งเสริมเรื่องแบบนี้จริง ๆ ก็ไม่น่ามีเหตุผลที่การอนุมัติจะใช้เวลามากกว่าหนึ่งปี
      ตรรกะอาจถูกก็ได้ แต่เมื่อเห็นสถานการณ์แบบนี้ ยากที่จะบอกว่า “บริษัทขี้เหนียว หรือเหมือนแทบทุกสถานการณ์อื่น ๆ คือเป็นระบบราชการมากเกินไป” ฟังดูเป็นไปได้น้อยกว่า “มีเหตุผลอันชอบธรรมที่จะไม่จ่ายรางวัลที่ดูเหมือนจะเข้าเกณฑ์”
      ถ้าผู้เขียนเล่าเหตุการณ์ได้ถูกต้อง ก็ดูเป็นไปได้กว่ามากว่าแรงจูงใจที่ทำงานอยู่ในทุกส่วนอื่น ๆ ได้ซึมเข้ามาในพื้นที่นี้ด้วย
    • เคยรายงานปัญหาความปลอดภัย·ความเป็นส่วนตัวให้ Apple ไหม? ผมเคย และตอนนี้ก็ยังมีประเด็นที่เปิดค้างอยู่กับ Apple อย่างน้อยหนึ่งเรื่อง
      หนึ่งในนั้นแก้ได้ด้วย โค้ดหนึ่งบรรทัด โดยไม่มีผลข้างเคียง แต่เปิดค้างมา 2 ปีแล้ว
      ทีมความปลอดภัยของ Apple ไม่สนใจหรือไม่ก็ไร้ความสามารถ อย่างใดอย่างหนึ่ง และไม่ว่าจะอย่างไหนก็ไม่ดีทั้งนั้น
      เป็นหนึ่งในประสบการณ์ด้านคอมพิวติ้งที่ทำให้โมโหและอึดอัดที่สุดที่เคยเจอ
      ทั้งที่ชัดเจนว่าไม่อยากให้แชร์ปัญหาแบบสาธารณะ แต่ก็เอาแต่ลากยาวไปไม่มีกำหนด
      พูดตรง ๆ คือใกล้ถึงขีดจำกัดแล้ว
      เงินรางวัลไม่สนเลย แค่อยากให้บั๊กถูกแก้
      ถ้าเชื่อได้ว่าพวกเขาจัดการเรื่องนี้อย่างจริงจัง ผมก็จะให้เวลาเต็มที่ แต่เชื่อแบบนั้นได้ยาก
    • มีกรณีที่บันทึกไว้มากมายว่าบริษัทเทคโนโลยียักษ์ใหญ่ปฏิเสธการจ่ายเงินไปเลย
      เช่น เปลี่ยนกฎการเข้าร่วมย้อนหลัง แอบบล็อกนักวิจัยด้านความปลอดภัยจากโปรแกรมรางวัลที่กำลังดำเนินอยู่ ส่งต่อการเปิดเผยโดยสุจริตให้หน่วยงานสืบสวน หรือผู้ดูแลทำตัวใจแคบสุด ๆ
      เพราะ “สำหรับบริษัทแล้วเงินจำนวนนี้ไม่มีนัยสำคัญ” นั่นแหละ จึงยิ่งทำให้ การจัดการที่เละเทะ แบบนี้เข้าใจยากขึ้น

  • เป็นอีกวิธีหนึ่งในการแตะต้อง quarantine flag สินะ อีกวิธีคือลิงก์นี้: https://imlzq.com/apple/macos/2024/08/24/Unveiling-Mac-Secur...
    ดูเหมือนว่ามีระบบต่าง ๆ มากเกินไปที่สามารถแก้ไข quarantine flag นี้ได้

  • “ผู้โจมตีสามารถส่งคำเชิญ Calendar ที่เป็นอันตรายพร้อมไฟล์แนบไปยังเหยื่อได้… ก่อนการแก้ไข ผู้โจมตีสามารถส่งคำเชิญ Calendar ที่เป็นอันตรายไปยังผู้ใช้ Apple iCloud คนใดก็ได้ แล้วขโมย iCloud Photos ได้โดยไม่ต้องมีการโต้ตอบจากผู้ใช้”
    ขอบเขตนี่อยู่ระดับไหนกันแน่? หมายความว่าใครก็ตามจากที่ไหนก็ได้บน macOS สามารถส่ง คำเชิญแบบใดก็ได้ ไปให้ใครก็ตามที่ใช้ iCloud ได้งั้นเหรอ? ใครจะอยากได้แบบนั้นกัน?

    • ไม่ได้ตั้งใจจะประชดนะ แต่คำเชิญควรทำงานแบบอื่นยังไงล่ะ?
    • ไม่เข้าใจ การได้รับคำเชิญปฏิทินต่างจากการได้รับอีเมลอื่นอย่างไร? โดยการออกแบบแล้ว macOS ประมวลผลอะไรบางอย่างกับ คำเชิญปฏิทิน โดยอัตโนมัติหรือเปล่า?
    • Google Calendar ก็เหมือนกันไม่ใช่เหรอ?
    • เรื่องนี้ดูไม่ได้เฉพาะเจาะจงกับ iCloud เท่านั้น โดยทั่วไปคำเชิญจะถูกตรวจจับจากอีเมลโดยอัตโนมัติอยู่แล้ว
      คำเชิญปฏิทินเป็นแหล่งสแปมมานานแล้ว ดังนั้นจึงไม่แปลกใจที่มี ช่องโหว่ ด้วย

  • “หากไฟล์ที่ผู้โจมตีกำหนดมีอยู่แล้ว ไฟล์ที่กำหนดจะถูกบันทึกในชื่อ PoC.txt-2 แต่เมื่ออีเวนต์/ไฟล์แนบที่ผู้โจมตีส่งมาถูกลบในภายหลัง ไฟล์ชื่อเดิม (PoC.txt) จะถูกลบออก ช่องโหว่นี้สามารถใช้เพื่อลบไฟล์ที่มีอยู่ภายใน ‘sandbox’ ของระบบไฟล์ได้”
    นี่คือ วิศวกรรมที่แย่

  • ผมไม่ค่อยชอบสถานะเงินรางวัลที่นี่เท่าไร จากมุมมองของนักวิจัยด้านความปลอดภัย การต้องรอนานขนาดนี้กับ Apple หรือบริษัทระดับ FAANG อื่น ๆ เป็นเรื่องปกติไหม?

    • ปกติมาก

  • แค่ขั้นที่ 1 อย่างเดียวก็เป็นช่องโหว่ที่เหลวไหลแล้ว Apple ไม่คิดถึงเรื่องนี้ได้ยังไง?
    “ผู้โจมตีสามารถตั้งค่าพาธใด ๆ ให้กับไฟล์ในส่วน ATTACH เช่น FILENAME=../../../PoC.txt เพื่อทำ การโจมตีแบบ directory traversal ได้สำเร็จ”

    • นี่แสดงให้เห็นปัญหาใหญ่กว่าที่น่าจะมีในทุกบริษัท แน่นอนว่าต้องมีใครสักคนที่ Apple เขียนฟังก์ชันไลบรารีสำหรับจัดการเรื่องนี้อย่างปลอดภัยไว้แล้ว แต่จะบังคับให้ใช้ฟังก์ชันนั้นได้อย่างไร?
      โดยเฉพาะถ้าคนรีวิวโค้ดก็ไม่รู้จักไลบรารีนั้น ก็ยากที่จะป้องกันไม่ให้มีการนำไปทำใหม่แบบไม่ปลอดภัยตั้งแต่ต้น
      มี วิธีแก้สมัยใหม่ สำหรับปัญหาแบบนี้ไหม?

  • ทุกครั้งที่มีช่องโหว่ความปลอดภัยขนาดใหญ่ที่ไม่ใช่เรื่อง memory safety โผล่มา ผมรู้สึกตื่นเต้นอย่างประหลาด
    รู้ว่ามันออกจะใจแคบหน่อย แต่ผมชอบภาพที่เวลาและพลังงานทั้งหมดที่ทุ่มให้ Rust สุดท้ายกลับสูญเปล่าเพราะ บั๊ก path traversal แค่ตัวเดียว

  • Lockdown Mode กันสิ่งนี้ได้ไหม?

    • เดาล้วน ๆ แต่ก็หวังว่าจะได้
      ถ้านึกถึง exploit แบบ zero-click ที่เกี่ยวกับไฟล์แนบรูปภาพในอดีต Lockdown Mode ดูเหมือนถูกสร้างมาเพื่อกันอะไรแบบนั้น และไฟล์ทั้งหมดก็น่าจะถูกปฏิบัติในลักษณะนั้น

  • ว้าว เป็น exploit ที่ค่อนข้างโบราณเลยนะ
    เรื่องพาธในชื่อไฟล์อะไรทำนองนี้ จำได้ว่าเคยอ่านเมื่อ ประมาณ 10 ปีก่อน