Dirty Frag: ช่องโหว่ LPE (ยกระดับสิทธิ์ภายในเครื่อง) แบบทั่วไปบน Linux

 (openwall.com)
2 คะแนน โดย GN⁺ 1 시간 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Dirty Frag คือ ช่องโหว่การยกระดับสิทธิ์ภายในเครื่องแบบทั่วไปที่ทำให้สามารถได้สิทธิ์ root บนดิสโทร Linux หลัก ๆ ได้ทั่วกระดาน โดยกำหนดการเปิดเผยอย่างรับผิดชอบและระยะเวลาเอมบาร์โกถูกทำลาย ทำให้ ยังไม่มีทั้งแพตช์และ CVE
  • เป็นการขยายของบั๊กคลาสเดียวกับ Dirty Pipe และ Copy Fail และเนื่องจากเป็น บั๊กเชิงตรรกะแบบกำหนดผลได้แน่นอน จึงไม่ต้องพึ่ง race condition และมีอัตราความสำเร็จสูงมาก
  • ช่องโหว่นี้มีอายุการใช้งานที่มีผลอยู่ประมาณ 9 ปี และทดสอบแล้วบนดิสโทรหลักอย่าง Ubuntu, RHEL, Fedora, openSUSE
  • แม้ระบบจะใช้มาตรการบรรเทา Copy Fail เดิมอยู่แล้ว (การบล็อก algif_aead) ก็ยังคง เสี่ยงต่อ Dirty Frag
  • มาตรการบรรเทาชั่วคราวคือแนะนำให้ถอดโมดูล esp4, esp6, rxrpc ที่เป็นจุดเกิดช่องโหว่ออก จนกว่าดิสโทรจะออกแพตช์

ภาพรวม

  • เป็นบั๊กคลาสที่ทำให้สมาชิก frag ของโครงสร้าง sk_buff ปนเปื้อน ซึ่งเป็นการขยายจากบั๊กคลาสเดียวกับ Dirty Pipe และ Copy Fail
  • สามารถเชนช่องโหว่ xfrm-ESP Page-Cache Write และ RxRPC Page-Cache Write เพื่อยกระดับเป็นสิทธิ์ root บนดิสโทร Linux หลักได้
  • เป็นบั๊กเชิงตรรกะแบบกำหนดผลได้แน่นอน จึง ไม่พึ่งพา timing window และไม่ต้องใช้ race condition
  • แม้เอ็กซ์พลอยต์จะล้มเหลว ก็ ไม่ทำให้เกิด kernel panic และมีอัตราความสำเร็จสูงมาก

เหตุผลที่เชนสองช่องโหว่เข้าด้วยกัน

  • xfrm-ESP Page-Cache Write ให้ primitive สำหรับ STORE แบบกำหนด 4 ไบต์ตามอำเภอใจ ที่ทรงพลัง คล้าย Copy Fail และมีอยู่ในดิสโทรส่วนใหญ่ แต่ต้องมีสิทธิ์สร้าง namespace
  • Ubuntu อาจ บล็อกการสร้าง user namespace ที่ไม่มีสิทธิ์พิเศษ ด้วย นโยบาย AppArmor ทำให้ในสภาพแวดล้อมนี้ไม่สามารถทริกเกอร์ xfrm-ESP Page-Cache Write ได้
  • RxRPC Page-Cache Write ไม่ต้องใช้สิทธิ์สร้าง namespace แต่ตัวโมดูล rxrpc.ko เองไม่ได้รวมมาในดิสโทรส่วนใหญ่
    • อย่างไรก็ตาม ใน Ubuntu โมดูล rxrpc.ko จะ ถูกโหลดมาโดยค่าเริ่มต้น
  • เมื่อเชนสองช่องโหว่เข้าด้วยกัน จะช่วย อุดจุดอ่อนของกันและกัน ทำให้สามารถยกระดับเป็นสิทธิ์ root ได้บนดิสโทรหลักทั้งหมด

ความสัมพันธ์กับ Copy Fail

  • Copy Fail เป็น แรงจูงใจ ที่ทำให้เริ่มงานวิจัยนี้
  • xfrm-ESP Page-Cache Write ใช้ sink เดียวกัน กับ Copy Fail แต่สามารถทริกเกอร์ได้โดยไม่ขึ้นกับการมีอยู่ของโมดูล algif_aead
  • แม้ระบบจะใช้มาตรการบรรเทา Copy Fail ที่มีการเปิดเผยแล้ว (การบล็อก algif_aead) ก็ยังคงเสี่ยงต่อ Dirty Frag

ขอบเขตผลกระทบ

  • xfrm-ESP Page-Cache Write: ตั้งแต่คอมมิต cac2661c53f3 (2017-01-17) จนถึง upstream ปัจจุบัน
  • RxRPC Page-Cache Write: ตั้งแต่คอมมิต 2dc334f1a63a (2023-06) จนถึง upstream ปัจจุบัน
  • ช่องโหว่นี้มี อายุการใช้งานที่มีผลอยู่ประมาณ 9 ปี
  • เวอร์ชันดิสโทรที่ทดสอบแล้ว:
    • Ubuntu 24.04.4: 6.17.0-23-generic
    • RHEL 10.1: 6.12.0-124.49.1.el10_1.x86_64
    • openSUSE Tumbleweed: 7.0.2-1-default
    • CentOS Stream 10: 6.12.0-224.el10.x86_64
    • AlmaLinux 10: 6.12.0-124.52.3.el10_1.x86_64
    • Fedora 44: 6.19.14-300.fc44.x86_64

มาตรการบรรเทา

  • เนื่องจากกำหนดการเปิดเผยอย่างรับผิดชอบและระยะเวลาเอมบาร์โกถูกทำลาย จึง ยังไม่มีแพตช์สำหรับดิสโทรใดเลย
  • มีการให้คำสั่งสำหรับบรรเทาชั่วคราว โดยลบโมดูลที่เป็นจุดเกิดช่องโหว่ออก: 
    sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
    • ลงทะเบียนโมดูล esp4, esp6, rxrpc เป็น แบล็กลิสต์ ใน /etc/modprobe.d/dirtyfrag.conf และ unload ออก
  • หลังจากแต่ละดิสโทรแบ็กพอร์ตแพตช์แล้ว ควรติดตั้งอัปเดตนั้น

ที่มาของการเปิดเผย

  • มีการเผยแพร่เอกสาร Dirty Frag ตามคำขอของผู้ดูแล linux-distros@vs.openwall.org หลังหารือร่วมกันแล้ว
  • ระยะเวลาเอมบาร์โก ถูกทำลายจากปัจจัยภายนอก และขณะนี้ยังไม่มีทั้งแพตช์หรือ CVE
  • PoC ถูกเผยแพร่หลังหารือกับ linux-distros โดยมีวัตถุประสงค์เพื่อ ให้ข้อมูลที่ถูกต้อง และห้ามนำไปใช้กับระบบที่ไม่ได้รับอนุญาต

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

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

 
GN⁺ 27 분 전
ความคิดเห็นจาก Hacker News

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

    • ถ้าผมไม่ได้อ่านผิด มันไม่ใช่แค่คล้ายกัน แต่เป็น สาเหตุรากเหง้าเดียวกัน เลย คือปัญหาบิตบน 32 บิตของ Extended ESN ใน IPsec == ปัญหาของโมดูล/โหมดเข้ารหัส authencesn
      ใน copy.fail สิ่งที่ถูกแก้กลับเป็นคนละจุด และผู้คนก็รีบโทษ AF_ALG กันเร็วเกินไป
      [แก้ไข: ใช่ เป็นปัญหา authencesn เดียวกัน https://github.com/V4bel/dirtyfrag/blob/892d9a31d391b7f0fccb... ในโค้ดมี authencesn แค่ในคอมเมนต์ แต่ก็ยังเป็นปัญหาเดียวกัน]
      [แก้ไข 2: ปัญหา RxRPC เป็นอีกเรื่องหนึ่ง ตรงนี้กำลังพูดถึงฝั่ง ESP]
    • อาจจะใช้พรอมป์ต์ต่อว่า “ช่วยหาบั๊กประเภทคล้าย ๆ กันให้หน่อย” ก็ได้ หลังจากมีการสรุปเคสจริงแล้ว การหาบั๊กคล้ายกันก็ไม่ได้ยากมาก
      ผมเข้าใจประเด็นเรื่องความคิดสร้างสรรค์ ไม่ว่าเป็นเครื่องมือไหน AI ก็อาจ ทำให้มุมมองแคบลง ได้ การใช้มันเป็นแค่ตัวช่วยโดยไม่ยก workflow ทั้งหมดให้มันทำเป็นเรื่องยาก
    • ผมไม่เข้าใจ ตั้งแต่แรกก็เป็น LLM ที่ค้นพบบั๊กเหล่านี้ไม่ใช่หรือ แต่ดูเหมือนคุณกำลังบอกว่าการค้นพบนั้นเป็นสัญญาณว่า LLM ไม่ดีกับการค้นหาช่องโหว่
    • อยากรู้ว่านี่เป็นข้อสังเกตที่มีหลักฐานรองรับ หรือเป็นแค่การคิดสด ๆ ออกมา
    • มันยากมากที่จะมองว่านี่เป็นบทเรียนว่า AI สำรวจค้นหาไม่เก่ง ทั้งที่มันพบช่องโหว่รากฐานที่คล้ายกัน แม้จะไม่เหมือนกันทั้งหมด
      นอกจากกรณีที่ทั้งสองช่องโหว่ถูกเปิดเผยพร้อมกัน ผมสงสัยว่าต้องอยู่ในสถานการณ์สมมติแบบไหนถึงจะนับว่า “สำรวจค้นหาได้ดีพอ”

  • “เพราะเอมบาร์โกถูกทำลาย จึงยังไม่มีแพตช์หรือ CVE สำหรับช่องโหว่เหล่านี้”
    ลิงก์: https://github.com/V4bel/dirtyfrag
    การวิเคราะห์แบบละเอียด: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-...
    ส่วนสำคัญคือข้อความนี้: “Copy Fail เป็นแรงจูงใจที่ทำให้เริ่มงานวิจัยนี้ โดยเฉพาะอย่างยิ่ง xfrm-ESP Page-Cache Write ในชุดช่องโหว่ Dirty Frag ใช้ sink เดียวกับ Copy Fail แต่ถูก trigger ได้โดยไม่ขึ้นกับว่ามีโมดูล algif_aead ใช้งานได้หรือไม่ กล่าวอีกนัยหนึ่ง แม้ระบบจะใช้มาตรการบรรเทา Copy Fail ที่เผยแพร่แล้วซึ่งเป็นการ blacklist algif_aead อยู่ Linux ก็ยังคงมีความเสี่ยงต่อ Dirty Frag”
    มาตรการบรรเทามีดังนี้ แต่ผมยังไม่ได้ทดสอบหรือยืนยันเอง: “เนื่องจากตารางเวลาเปิดเผยอย่างรับผิดชอบและเอมบาร์โกถูกทำลาย จึงยังไม่มีแพตช์ในดิสโทรใด ๆ ให้ลบโมดูลที่ทำให้เกิดช่องโหว่ออกด้วยคำสั่งด้านล่าง”
    sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
    ในบทสนทนาเรื่องมาตรการบรรเทามีการบอกว่าอาจต้องรีบูต หรือถ้าเครื่องถูกโจมตีไปแล้ว หลังคำสั่งด้านบนให้รันคำสั่งนี้ต่อ: sudo echo 3 > /prox/sys/vm/drop_caches

    • ใน sudo echo 3 > /prox/sys/vm/drop_caches นั้น sudo ไม่มีผล เพราะ sudo รันแค่ echo แต่การเขียนจริงไม่ได้อยู่ภายใต้สิทธิ์ sudo
      และถ้าเครื่องถูกใช้ประโยชน์ไปแล้ว ก็สายเกินไปสำหรับแค่นั้น อะไรก็ตามบนดิสก์อาจถูกทำให้เสียหายได้ จึงควรสร้างอิมเมจดิสก์ใหม่ทั้งหมด
    • ใช้ sudo echo กับ redirection แบบนั้นจากเชลล์ที่ไม่ใช่ sudo ไม่ได้
      echo 3 | sudo tee /proc/sys/vm/drop_caches
      หรือ
      sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
      และผมแก้คำพิมพ์ผิดจาก /proc ด้วย
    • เผื่อไว้ด้วยว่า echo 1 > ... ก็ช่วยบรรเทาได้ ไม่จำเป็นต้องล้างทั้งหมด แค่ล้าง page cache ด้วย 1 ก็พอ
      ผมทดสอบบน Ubuntu 26.04 ในเครื่องตัวเอง: รัน exploit แล้วได้ root จากนั้นตั้งค่ามาตรการบรรเทา แล้วรัน su แบบไม่มีอาร์กิวเมนต์อีกครั้ง ก็ได้ root ทันทีโดยไม่ต้องใส่รหัสผ่าน หลังจากนั้นเมื่อล้าง page cache แล้ว su ก็กลับมาขอรหัสผ่าน

  • เราต้องการวิธีง่าย ๆ ที่จะรับประกันว่าโหลดได้เฉพาะ kernel module ที่อยู่ใน whitelist เท่านั้น เบื่อที่จะต้อง blacklist โมดูลที่ไม่จำเป็นเพิ่มอยู่เรื่อย ๆ

  • ขอย้ำอีกที ทำไมใน copy.fail ถึงไปโทษ algif_aead กันหมด? ตัวที่โง่คือ authencesn ต่างหาก
    authencesn ไม่เคยถูกแก้ และตอนนี้ก็เห็นผลของมันแล้ว
    ตอนนี้พบว่าสามารถเข้าถึง การเขียนออกนอกขอบเขต แบบเดียวกัน หรืออาจจะเป็นแบบเดียวกันจริง ๆ ผ่าน network socket ธรรมดาได้
    น่าเสียดายที่ผมนึกถึงจุดนี้ไม่ออกตั้งแต่แรก
    [แก้ไข: ผมกำลังพูดถึงปัญหาผ่าน ESP ส่วนปัญหา RxRPC เท่าที่ผมเข้าใจเป็นคนละเรื่องกันโดยสิ้นเชิง]

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

    • การให้ผู้ดูแลดิสโทรตัดสินแทนผู้ใช้ว่า “คุณคงไม่ต้องใช้หรอก (YAGNI)” แล้ว blacklist ฟีเจอร์บางอย่าง ถือเป็นข้อเรียกร้องที่ค่อนข้างหนัก เพราะพวกเขาไม่มีทางรู้ว่าใครใช้สิ่งไหนอยู่บ้าง ผู้ใช้สามารถกลับไปปรับแต่งบิลด์ให้ตรงกับสิ่งที่ตัวเองต้องการจริง ๆ ได้เสมอ
      ผมจำยุคแรก ๆ ของ Linux ได้ที่ต้องรัน make menuconfig แล้วเลือกฟีเจอร์ที่จะใส่ใน kernel เองอย่างละเอียด เอาจริง ๆ ก็ไม่ได้อยากกลับไปยุคนั้น
      อย่างไรก็ตาม จุดที่น่าจะปรับปรุงได้ง่ายในที่นี้คือ RHEL เพราะ RHEL มักไม่ได้ปล่อยหลายโมดูลเป็นโมดูลที่โหลดได้ แต่คอมไพล์รวมเข้า kernel ไปเลย ทำให้มาตรการบรรเทาแบบ copy fail ใช้ไม่ได้ บางทีอาจลดแบบนั้นลงได้บ้างไหม
    • ไม่มีวิธีปิดองค์ประกอบที่ผู้ใช้น่าจะไม่ใช้โดยไม่ทำให้การใช้งานระบบยากขึ้นมาก แม้แต่ผมที่ใช้ OS งี่เง่านี้มา 25 ปี ก็ยังไม่รู้ว่าจะต้องเปิดหรือปิดอะไรเพื่อให้ทำสิ่งที่อยากทำได้
      ผู้ดูแลดิสโทร Linux คือผู้ดูแลซอฟต์แวร์ที่มีความรับผิดชอบมากที่สุดบนโลก แนวปฏิบัติด้านความปลอดภัยของพวกเขาดีกว่าพวกตัวจัดการแพ็กเกจของภาษาการเขียนโปรแกรมงี่เง่าต่าง ๆ มาก พวกเขาดูแลรายการแพ็กเกจที่คัดสรรแล้ว ตรวจสอบการเปลี่ยนแปลง แพตช์บั๊ก แก้ปัญหาการแพ็กเกจที่ซับซ้อน backport การแก้ไข ใช้การปล่อยเวอร์ชันแบบค่อยเป็นค่อยไป แจกจ่ายไฟล์ผ่าน mirror ทั่วโลก และตรวจสอบไฟล์ทุกชิ้นด้วยวิธีเข้ารหัสลับ และอย่าลืมด้วยว่าพวกเขาทำทั้งหมดนี้ให้ฟรี
    • มันไม่ได้ถูกเปิดใช้งานโดยค่าเริ่มต้น แต่เป็น โมดูลเสริม ที่จะถูกโหลดเมื่อจำเป็น โครงสร้างโดยรวมของ kernel คือใส่เฉพาะฟังก์ชันหลักที่ผู้ใช้ต้องใช้ไว้ในตัว และให้เกือบทุกอย่างที่เหลือเป็นโมดูลที่โหลดเมื่อจำเป็น
    • ในหลายแง่มุม คอมพิวเตอร์ที่ไม่ใช่มือถือก็ยังคงอยู่ในปี 1999 จริง ๆ Android ปลอดภัยกว่าระบบ Linux อื่น ๆ มาก เพราะมันใหม่กว่าเยอะและมีโอกาสรวมการควบคุมการเข้าถึงแบบบังคับไว้ทั้งสแตกตั้งแต่ต้น
    • การใช้ประโยชน์ช่องโหว่นี้ต้องเข้าถึงคอมพิวเตอร์ได้โดยตรง ไม่ว่าจะผ่านอุปกรณ์ USB อันตราย การโจมตีซัพพลายเชน หรือการใช้ซอฟต์แวร์ที่รู้กันว่าใช้ได้และผู้ใช้จะติดตั้งเองโดยสมัครใจหรืออัตโนมัติ ยิ่งไปกว่านั้น ในทางปฏิบัติต้องสามารถรันคำสั่งเทอร์มินัลแทบจะตามใจได้อยู่แล้ว ซึ่งนั่นก็เป็นการเจาะระบบอย่างหนักภายใน sandbox ของซอฟต์แวร์นั้นตั้งแต่แรก
      ถ้าผู้โจมตีทำทั้งหมดนั้นได้แล้ว สถานการณ์ก็แย่อยู่แล้ว การยกระดับเป็น root ด้วยช่องโหว่นี้จึงเป็นแค่เรื่องเล็กเมื่อเทียบกับปัญหาอื่นในจุดนั้น
      ตามที่มีคนอื่นโพสต์ไว้ด้านล่าง https://xkcd.com/1200/
      ก่อนจะตื่นตระหนก ผู้คนควรเข้าใจก่อนว่าช่องโหว่นี้คืออะไรจริง ๆ

  • หลังจากผ่านมานาน ในที่สุดเราก็มาถึงจุดที่ “ถ้ามีคนดูมากพอ ทุกบั๊กก็จะตื้น” แต่ก็ดูไม่ค่อยดีเท่าไร จากนี้เราต้องอัปเดต kernel กันสัปดาห์ละหลายครั้งเลยหรือเปล่า?

    • คุณกำลังมองว่าอาจมีใครบุกเข้าบ้านแล้วหาทางรู้ข้อมูลรับรองพื้นฐานจนได้ root access ใช่ไหม?

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

    • ตั้งแต่แรก เอมบาร์โก ก็ไม่มีอยู่แล้ว และก็ไม่มีทางมีได้
      Linux เป็นโอเพนซอร์ส ดังนั้นแพตช์ทุกตัวที่แก้บั๊กความปลอดภัยย่อมมองเห็นได้ทันทีโดยทุกคน และด้วยวิธีพัฒนา kernel ก็ไม่มีทางเลี่ยงเรื่องนี้ได้ สิ่งที่ผู้คนเรียกว่า “เอมบาร์โก” คือแนวคิดที่ค่อนข้างงี่เง่าว่า ถ้าไม่เขียนอธิบายแพตช์ตรง ๆ ว่า “THIS IS A LPE” และทุกคนเงียบปากกันไว้ ก็จะพอแสร้งทำเป็นว่าช่องโหว่ยังไม่รั่วจนกว่าจะมีข้อความ “อย่างเป็นทางการ” ออกไปใน mailing list
      เมื่อก่อนวิธีนี้อาจพอปกป้องได้ระดับหนึ่ง แต่ในยุค LLM มันไม่ใช่แค่งี่เง่าแต่ยังอันตราย เพราะเราสามารถเอา diff จาก mailing list เข้า pipeline อัตโนมัติให้โมเดลล่าสุดช่วยระบุได้ว่าแพตช์ไหนกำลังแก้ปัญหาด้านความปลอดภัย
    • มีคนโพสต์ลิงก์แพตช์บนบัญชี X ของตัวเอง แล้วอีกคนเห็นและโพสต์ exploit ที่ใช้งานได้ภายในไม่ถึงชั่วโมง อาจเป็นไปได้ว่ามีการใช้ LLM เพื่อช่วยทำ exploit แต่ยังไม่มีอะไรพิสูจน์ได้ นอกจากเวลาที่เปลี่ยนจากแพตช์ไปเป็น exploit เร็วมาก
      https://x.com/encrypted_past/status/2052409822998392962
    • บุคคลที่สามที่ไม่เกี่ยวข้องเป็นผู้โพสต์ต่อสาธารณะ

  • มีใครรู้ไหมว่า Debian ได้รับผลกระทบหรือเปล่า? ผมลอง exploit บนเครื่อง Debian 12 และ Debian 13 แต่ยังทำซ้ำเองไม่ได้

    • ผมทำซ้ำได้บน kernel 6.12.57+deb13-amd64 ของ Debian 13 หรือ Trixie แต่ทำซ้ำไม่ได้บน kernel 6.1.0-42-amd64 ของ Debian 12 Bookworm
      สำหรับคนที่ไม่ได้ใช้ security stream ของแพ็กเกจ Debian บน Bookworm แล้ว kernel 6.1.0-42-amd64 กลับมีภูมิคุ้มกันต่อ copy.fail อยู่จริง การที่มันดูเหมือนมีภูมิคุ้มกันต่อ dirtyfrag ด้วยก็เป็นเรื่องน่าประหลาดใจ ถ้าใน security stream ยังไม่ได้แพตช์ คุณอาจเลือกใช้เวอร์ชัน kernel ที่ยังมี commit 2b8bbc64b5c2 อยู่ได้ ผมสงสัยว่า commit เดียวกันนี้อาจทำให้ kernel Debian 12 บางเวอร์ชันปลอดภัยจาก dirtyfrag โดยบังเอิญด้วย
    • ผมเพิ่งลอง exploit บน droplet Debian 13 ใหม่ของ DigitalOcean แล้วมันทำงาน
    • ผมทดสอบบน Debian 13 ที่อัปเดตล่าสุดทั้งหมด และ exploit ทำงานได้ ผมยืนยันแล้วว่ามาตรการบรรเทาก็ใช้ได้เช่นกัน

  • รันในคอนเทนเนอร์ ubuntu:latest ด้วยผู้ใช้เริ่มต้นตัวใหม่
    git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp
    ผลลัพธ์: dirtyfrag: failed (rc=3)
    ข่าวดี!

    • ตอนรันในคอนเทนเนอร์ผมก็ได้ผลเหมือนกัน แต่พอรันบนโฮสต์โดยตรงกลับได้เชลล์ นี่แสดงแค่ว่า exploit นี้ใช้ไม่ได้ในคอนเทนเนอร์ ดังนั้นอาจหมายถึงคอนเทนเนอร์ไม่เปราะบาง หรือไม่ก็สคริปต์ต้องปรับเล็กน้อยถึงจะทำงานในคอนเทนเนอร์ได้
      copy fail สามารถใช้เพื่อหนีออกจากคอนเทนเนอร์ได้ (https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...) จึงเดาได้ว่า exploit นี้ก็น่าจะต้องเปลี่ยนแค่เล็กน้อย
    • ผมไม่คิดว่าคอนเทนเนอร์เป็นแพลตฟอร์มที่เชื่อถือได้สำหรับการทดสอบแบบนี้ ไม่ว่าจะเป็นพฤติกรรมที่ปกติหรือไม่ก็ตาม มีหลายอย่างที่ล้มเหลวเมื่อรันในคอนเทนเนอร์
 
GN⁺ 1 시간 전
ความคิดเห็นจาก Lobste.rs

  • เป็นสัปดาห์ที่หนักมากจริง ๆ สำหรับการดูแล Linux server แบบแชร์ร่วมกัน แต่ก็ชอบที่การเปิดเผยครั้งนี้พูดประเด็นสำคัญตรง ๆ
    แต่ไม่เข้าใจว่าทำไมในแนวทางบรรเทาผลกระทบทุกคนถึงซ่อน stderr
    แก้ไข: มีการบอกว่านี่ถูกรายงานเมื่อวันที่ 30 เมษายน โดยได้ “แรงบันดาลใจ” มาจาก copy.fail งั้นแปลว่าถูกค้นพบภายในเวลาไม่ถึงหนึ่งวันเหรอ? น่าประทับใจมาก
    ในฐานะคนที่มีสิทธิ์ sudo บนเซิร์ฟเวอร์แชร์ขนาดค่อนข้างใหญ่ ก็เลยสงสัยว่าการ คอมไพล์ kernel เอง โดยใส่เฉพาะโมดูลให้น้อยที่สุดเท่าที่ทำได้จะเป็นความคิดที่ดีไหม ยังไม่ได้ชั่งน้ำหนักข้อดีข้อเสียแบบลึก ๆ แต่ดูเหมือนว่าน่าจะหลีกเลี่ยงช่องโหว่ยกระดับสิทธิ์แบบ local ทั้งสองตัวของสัปดาห์นี้ได้
    แก้ไข 2:

     * 2. rxrpc path  (Ubuntu fallback): if AF_ALG is sandboxed and the ESP
 *    path can't reach the page cache, fall back to the rxrpc/rxkad
 *    nullok primitive that patches /etc/passwd's root entry empty.
 *    PAM nullok then accepts the empty password during `su -`.

    โอ้ อันนี้ไม่ต้องใช้ setuid แฮะ ดีใจที่ใส่มาด้วย

    • ฉันทำแบบนั้นอยู่กับ ระบบหลายผู้ใช้ ที่ดูแลอยู่ และก็หลีกเลี่ยง local root exploit สองตัวในสัปดาห์นี้ได้จริง

  • จะเป็นไปได้และสมเหตุสมผลไหม ถ้าจะดึง รายการ kernel module ที่ถูกโหลดอยู่จากระบบที่กำลังรัน แล้วตั้งให้เป็น allowlist ของ modprobe สำหรับระบบนั้น?
    ทั้ง CopyFail และ DirtyFrag ดูเหมือนจะอาศัย kernel module ที่ไม่ได้ถูกโหลดอยู่บนระบบใด ๆ ที่ฉันตรวจสอบ ถ้าอย่างนั้นการบล็อกโมดูลที่เห็นได้ชัดว่าไม่จำเป็นก็น่าจะช่วยบรรเทาการโจมตีบางส่วนล่วงหน้าได้ไหม?

  • 2026-05-07: Detailed information and the exploit for this vulnerability were published publicly by an unrelated third party, breaking the embargo.
    ไม่เข้าใจเลยว่าเรื่องแบบนี้ปล่อยให้เกิดขึ้นได้อย่างไร การที่ข้อมูลขนาดนี้อยู่ใน สภาพแวดล้อมที่ไม่น่าไว้ใจขนาดนั้น มันฟังดูเหลือเชื่อจริง ๆ

    • ไม่แน่ใจว่าที่บอกว่า “บุคคลที่สามที่ไม่เกี่ยวข้องเผยแพร่” หมายถึงกรณีนี้หรือเปล่า แต่เพื่อเป็นข้อมูล Brad Spengler เห็นว่ามีการ push commit สำหรับแพตช์ขึ้นไปก่อน แล้วก็สังเกตเห็นช่องโหว่ด้านความปลอดภัยที่ข้อความ commit สื่อเป็นนัย จากนั้นมีคนในเธรดตอบกลับใช้ vibe coding ทำ exploit ขึ้นมา
      ถ้าเป็นบุคคลที่สามที่คอยดู Linux commit อยู่ ก็เป็นไปได้ว่าใครก็ตามจะจับเบาะแสเดียวกันและสร้าง exploit ขึ้นมาได้
    • คำว่า “บุคคลที่สามที่ไม่เกี่ยวข้อง” ฟังดูเหมือนหมายความว่า คนคนนั้นไม่รู้ว่าบั๊กนี้ยังอยู่ภายใต้ embargo
      ในที่นี้ “สภาพแวดล้อมที่ไม่น่าไว้ใจ” ก็คืออินเทอร์เน็ตทั้งหมด และเอาจริง ๆ ก็แทบไม่มีอะไรที่เรียกได้ว่าแยกขาดอย่างแท้จริง เดิมทีมันก็เป็นแบบนั้นอยู่แล้ว เพียงแต่ตอนนี้ชัดเจนขึ้นเท่านั้นเอง ลองดูโพสต์ล่าสุดของ Stefan Eissingเกี่ยวกับกรณีที่บั๊กของ Apache httpd ถูกค้นพบซ้ำสองครั้งก่อนจะมีการแก้ไขก็น่าสนใจ

  • มีวิธีทดสอบไหมว่าโมดูลที่ได้รับผลกระทบ “โหลดไม่ได้จริง” หรือเปล่า?
    ตอนเกิด CopyFail ฉันพลาดตอนใช้มาตรการบรรเทาครั้งแรก ไฟล์ใน /etc/modprobe.d/ ลงท้ายไม่ใช่ .conf และกว่าจะรู้ก็ตอนรันคำสั่งทดสอบจาก https://news.ycombinator.com/item?id=47954159 มีคำสั่งคล้าย ๆ กันสำหรับโมดูล esp4/esp6/rxrpc ไหม?

    • ฉันลองโหลดทั้งสามโมดูลด้วย modprobe แล้ว และก็เจอ error แบบเดียวกับครั้งก่อน
      มีโค้ด proof of concept แนบมาด้วยเหมือนกัน แต่ยังไม่ได้ลองรัน