CVE-2026-31431 (Copy Fail) - เราบรรเทาปัญหานี้อย่างไร

เมื่อสัปดาห์ที่แล้วมีการเปิดเผยช่องโหว่ยกระดับสิทธิ์ภายในเครื่องที่ร้ายแรงใน Linux kernel: CVE-2026-31431 ซึ่งมีชื่อเล่นว่า "Copy Fail" ช่องโหว่นี้กระทบ kernel หลายเวอร์ชันใน Linux distribution สมัยใหม่จำนวนมาก และมี exploit สาธารณะปรากฏขึ้นอย่างรวดเร็วหลังการเปิดเผย

ผมอยากอธิบายอย่างตรงไปตรงมาว่าเกิดอะไรขึ้น มีความหมายอย่างไรต่อ Appbox และเราได้ทำอะไรไปแล้ว สรุปสั้น ๆ คือ ด้วยวิธีที่เราออกแบบ container ของเราไว้ app ที่ทำงานด้วย user namespace remapping ได้รับการป้องกันอยู่แล้วไม่ให้เหตุการณ์นี้กลายเป็น host root แม้ก่อนที่ kernel ที่แพตช์แล้วจะถูกใช้งาน เมื่อวานนี้ (May 4, 2026) เรายังได้ดำเนินการบำรุงรักษาฉุกเฉินเพื่ออัปเกรดทุก server ไปยัง kernel ที่แพตช์แล้ว ดังนั้นตอนนี้ bug นี้จึงถูกกำจัดออกจาก fleet ของเราโดยสมบูรณ์

"Copy Fail" คืออะไร?

CVE-2026-31431 เป็นข้อบกพร่องใน API เข้ารหัส AF_ALG ของ kernel โดยการ bind กับ cipher เฉพาะ (authencesn(hmac(sha256),cbc(aes))) และใช้ประโยชน์จากวิธีที่ kernel splice page เข้าไปใน scratch buffer ผู้ใช้ local ที่ไม่มีสิทธิ์สามารถเขียน chunk ขนาด 4 byte ตามต้องการ ลงใน page cache โดยตรง ของไฟล์ที่ไม่ควรมีสิทธิ์แก้ไข รวมถึง SUID binary อย่าง /usr/bin/su

เมื่อสำเนา page cache ของ su ถูกเขียนทับด้วย ELF อันตรายขนาดเล็ก การเรียกใช้งานครั้งถัดไปจะรัน code ของผู้โจมตีในฐานะ UID 0 นั่นคือจบเกมสำหรับ host

สำหรับรายละเอียดทางเทคนิคแบบเจาะลึก (shellcode disassembly, syscall traces และอื่น ๆ ทั้งหมด) บทความของ Andrea Veri ยอดเยี่ยมมาก: CVE-2026-31431: Copy Fail vs. rootless containers เขายังได้สาธิตด้วย eBPF และหลักฐาน uid_map อย่างชัดเจนถึงสิ่งที่เราจะพูดต่อไป: user namespaces ทำให้ exploit นี้หมดฤทธิ์

ทำไม Appbox Apps จึงได้รับการบรรเทาปัญหาอยู่แล้ว

exploit นี้พึ่งพาให้ setuid(0) มอบ host root จริง ๆ แต่ใน container ที่เปิดใช้ user namespaces นั่นไม่ใช่สิ่งที่เกิดขึ้น

User namespaces map พื้นที่ UID ของ container ไปยังช่วง UID อื่นบน host ซึ่งไม่มีสิทธิ์พิเศษ ดังนั้นเมื่อ exploit สำเร็จภายใน container และ setuid(0) คืนค่าสำเร็จ shell "root" ที่ได้จะถูก map เป็น ผู้ใช้ host ปกติที่ไม่มีสิทธิ์พิเศษ ไม่ใช่ root จริง shellcode ทำงาน prompt เปลี่ยนเป็น # แต่บน host:

podman     27943  0.0  0.0   2984  2028 pts/1    S+   22:15   0:00 sleep 100

เท่านั้นเอง ไม่มีการเข้าถึงไฟล์ของ host ไม่มี /etc/shadow และไม่มี host root ขอบเขต namespace ของ container หยุดไม่ให้สิ่งนี้กลายเป็นการ escape ไปเป็น host-root

ในระดับ platform Appbox แต่ละตัวจะมี Docker daemon ของตัวเองที่เริ่มทำงานพร้อมเปิดใช้ user namespace remapping ใน pseudocode จะคล้ายแบบนี้:

start_docker_daemon(
  userns_remap = appbox_id,
  container_namespace = appbox_id
)

การ mapping นี้รองรับด้วยช่วง subordinate UID/GID เฉพาะบน host:

write "/etc/subuid" -> "<appbox-id>:<host-subuid-start>:65536"
write "/etc/subgid" -> "<appbox-id>:<host-subgid-start>:65536"

นอกจากนี้ app definition ยังสามารถ override UsernsMode อย่างชัดเจนได้เมื่อ app ต้องการการจัดการพิเศษ:

container_config = {
  userns_mode: app.userns_mode,
  network_mode: app.network_mode,
  ...
}

ดังนั้นคำอธิบายที่ถูกต้องคือ: user namespace remapping เป็นส่วนหนึ่งของค่าเริ่มต้นของ platform และข้อยกเว้นราย app จะต้องระบุอย่างชัดเจน มี app จำนวนเล็กน้อยที่ต้องใช้การตั้งค่าต่างออกไปเพราะเปิดเผย functionality ที่ต้องการ capability เพิ่มเติม และกรณีเหล่านั้นถูกจัดการแยกต่างหาก

กล่าวอีกอย่างคือ: สำหรับ app ที่ทำงานด้วย setup แบบ remapped ปกติ Copy Fail ไม่สามารถเปลี่ยนการ compromise container ให้เป็น host root ได้

สิ่งที่เรายังต้องการแก้ไข

User namespaces หยุดการ escape ออกจาก host ได้ แต่ไม่ได้ทำให้ bug ภายใน container หายไป ผู้โจมตียังอาจยกระดับเป็น "container root" ภายในขอบเขตของ app ได้ ซึ่งแม้จะถูกจำกัดอยู่ภายใน แต่ก็ยังไม่ใช่สภาพที่ดี ตัว kernel เองยังมีช่องโหว่ และเราต้องการกำจัดมันออกไป

ทันทีที่เราทราบเกี่ยวกับ bug นี้ เราเริ่มประเมิน exposure ของเราทันที แม้ว่า user namespace remapping จะบล็อกส่วน host-escape ของปัญหานี้สำหรับ setup app ปกติของเราอยู่แล้ว เรายังต้องการให้ bug ระดับ kernel ที่เป็นต้นเหตุหายไปโดยเร็วที่สุด

สิ่งที่เราทำเมื่อวานนี้

ในคืนวันอาทิตย์ เรากำหนดการบำรุงรักษาฉุกเฉินสำหรับ Monday, May 4, 2026 ซึ่งเป็นช่วงเวลาที่เร็วที่สุดที่เราสามารถ rollout การอัปเกรด kernel ทั่วทั้ง fleet ได้

ระหว่างช่วงเวลาดังกล่าว:

• host ทุกเครื่องถูกอัปเกรดด้วย package kernel ทางการของ Debian ที่มี fix สำหรับ "Copy Fail"
• เป้าหมายเรียบง่าย: นำ path ของ kernel ที่มีช่องโหว่ออกไปทั้งหมด ไม่ใช่เพียงพึ่งพา namespace isolation ที่เรามีอยู่แล้ว

การบำรุงรักษาเสร็จสมบูรณ์แล้ว ตอนนี้ host ของ Appbox ทุกเครื่องกำลังรัน kernel ที่แพตช์แล้ว

สิ่งนี้หมายถึงอะไรสำหรับคุณ

• คุณไม่จำเป็นต้องทำอะไร app ของคุณยังคงทำงานต่อไป และการสะดุดสั้น ๆ ระหว่างช่วงบำรุงรักษาเป็นผลกระทบเดียวที่ลูกค้ามองเห็นได้
• แม้ก่อนแพตช์เมื่อวานนี้ user namespace remapping หมายความว่า bug นี้ไม่สามารถเปลี่ยนการ compromise app ปกติให้เป็น host root ได้ นั่นคือสถานการณ์แบบเดียวกับที่ isolation model นี้ถูกออกแบบมาเพื่อรับมือ
• ต่อจากนี้ นโยบายของเราไม่เปลี่ยนแปลง: user namespaces จะเปิดตามค่าเริ่มต้นต่อไป และข้อยกเว้นจำนวนน้อยมากจะต้องผ่านการตรวจสอบความปลอดภัยเพิ่มเติม

ภาพรวมที่ใหญ่กว่า

นี่เป็นหนึ่งใน CVE ที่พาดหัว ("local privilege escalation, public exploit, every modern kernel affected") ฟังดูหายนะ และสำหรับ environment แบบ shared-tenant จำนวนมาก มันก็เป็นเช่นนั้นจริง ๆ เหตุผลที่มันไม่เป็นหายนะสำหรับเราคือเหตุผลเดียวกับที่เราตัดสินใจด้าน architecture เมื่อหลายปีก่อนซึ่งบางครั้งแลกมาด้วย compatibility บางส่วน: เรารัน app ด้วยหลักการ least privilege ที่ฝังอยู่ในชั้น container ไม่ใช่เอามาแปะเพิ่มทีหลัง

Defence in depth ใช้ได้จริง Bug ที่ชั้น kernel? ชั้น namespace รับไว้ Bug ที่ชั้น namespace? Capability drops และ seccomp รับส่วนใหญ่ต่อ เราไม่แสร้งว่าชั้นใดชั้นหนึ่งสมบูรณ์แบบ เราเพียงทำให้แน่ใจว่ามีชั้นถัดไปรออยู่เสมอ

หากคุณมีคำถามเกี่ยวกับเรื่องนี้ หรือเกี่ยวกับการตั้งค่า app เฉพาะของคุณ โปรดติดต่อเรา

มีคำถามไหม? ติดต่อเราได้ที่ support@appbox.co หรือเปิด ticket ที่ billing.appbox.co.