มีการเปิดเผย CVE ของเคอร์เนล Linux 432 รายการในช่วง 24 ชั่วโมงที่ผ่านมา

 (lore.kernel.org)
1 คะแนน โดย GN⁺ 6 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ตามหัวข้อบน Hacker News มีการเปิดเผย CVE ของเคอร์เนล Linux 432 รายการในช่วง 24 ชั่วโมงที่ผ่านมา แต่ในหน้าประกาศปัจจุบันยังไม่สามารถตรวจสอบรายละเอียดแต่ละรายการได้
  • หน้าประกาศใช้กระบวนการป้องกันบอต Anubis เพื่อป้องกัน เซิร์ฟเวอร์หยุดให้บริการและการจำกัดการเข้าถึงทรัพยากร ที่เกิดจากการเก็บรวบรวมข้อมูลเว็บขนาดใหญ่
  • ใช้ Proof-of-Work ตระกูล Hashcash เพื่อคงภาระของการเข้าถึงทั่วไปให้น้อย ขณะเดียวกันก็เพิ่มต้นทุนสะสมของการเก็บรวบรวมข้อมูลจำนวนมาก
  • วิธีนี้เป็น ทางแก้ชั่วคราว ที่ใช้จนกว่าจะมีเทคนิคสำหรับระบุเบราว์เซอร์แบบ headless
  • จำเป็นต้องใช้ฟีเจอร์ JavaScript รุ่นใหม่ และปลั๊กอินที่บล็อกฟีเจอร์เหล่านี้ เช่น JShelter ต้องถูกปิดใช้งานสำหรับโดเมนนั้นจึงจะเข้าถึงได้

สถานะปัจจุบันของหน้าประกาศ CVE

  • หัวข้อบน Hacker News ระบุว่ามีการเปิดเผย CVE ของเคอร์เนล Linux 432 รายการในช่วง 24 ชั่วโมงที่ผ่านมา แต่หน้าที่ให้มาไม่มีรายการ CVE หรือรายละเอียดใด ๆ
  • แสดงเพียง หน้าคำนวณ Proof-of-Work ที่มีระดับความยาก 4

วิธีทำงานและข้อจำกัดของ Anubis

  • Proof-of-Work ตระกูล Hashcash สร้างภาระการคำนวณที่แทบไม่กระทบต่อการเข้าถึงแต่ละครั้ง แต่ก่อให้เกิดต้นทุนสะสมสำหรับการเก็บรวบรวมข้อมูลขนาดใหญ่
  • ในอนาคตมีเป้าหมายที่จะ ทำ fingerprint เพื่อระบุเบราว์เซอร์แบบ headless ผ่านวิธีต่าง ๆ เช่น รูปแบบการเรนเดอร์ฟอนต์ เพื่อไม่แสดงหน้า Proof-of-Work ให้ผู้ใช้ปกติ
  • ฟีเจอร์ JavaScript รุ่นใหม่ที่ Anubis ต้องการอาจถูก JShelter และเครื่องมืออื่น ๆ บล็อกได้ จึงต้องปิดใช้งานปลั๊กอินดังกล่าวจึงจะเข้าถึงได้

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

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

 
GN⁺ 6 시간 전
ความเห็นจาก Lobste.rs

  • CVE ไม่ใช่ตัวช่องโหว่เอง แต่เป็นตัวระบุ และอาจถูกกำหนดเมื่อมีการค้นพบช่องโหว่จริง

    • มาเข้าใจเจตนาทีหลัง คิดว่าน่าจะหมายถึงว่าควรตั้งชื่อหัวข้อเป็น ช่องโหว่ Linux kernel 432 รายการ

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

    http://www.kroah.com/log/blog/2026/01/02/linux-kernel-security-work/

    http://www.kroah.com/log/blog/2026/02/16/linux-cve-assignment-process/

    • ทีมความปลอดภัยของเคอร์เนลไม่สามารถรู้ได้ทั้งหมดว่าเคอร์เนลถูกใช้งานที่ไหนและอย่างไร และนี่ก็เป็นผลลัพธ์ที่ค่อนข้างแปลกจากการที่ Linux kernel กลายเป็น CVE Numbering Authority (CNA) ของตัวเอง
      เดิมทีระบบ CVE ถูกสร้างมาสำหรับผลิตภัณฑ์ จึงไม่ค่อยเข้ากับเคอร์เนลระบบปฏิบัติการที่ถูกใช้เป็นส่วนประกอบของหลายผลิตภัณฑ์ ตามอุดมคติแล้ว CachyOS, ผู้ผลิตกล้องที่ฝังเคอร์เนลไว้, และ Red Hat ควรตัดสินอย่างอิสระว่าบั๊กเดียวกันเข้าข่าย CVE ในบริบทของตนหรือไม่
      แต่ถ้าทำแบบนั้น ก็อาจมี CVE แยกสำหรับกล้อง 300 รุ่น, เราเตอร์ไฟล์เซิร์ฟเวอร์ 300 รุ่นที่ทำงานแปลกเมื่อเสียบ USB, และเครื่องเล่นอีมูเลชันเกมย้อนยุคอีกหลายสิบรุ่นที่ใช้ SD card ดังนั้นแม้จะดูแปลกในเชิงโครงสร้าง แต่การจัดการในระดับส่วนประกอบก็ดีกว่าสำหรับทั้ง ecosystem
    • บั๊กความเสียหายของไฟล์ซิสเต็ม ก็อาจมองว่าเป็นผู้เข้าข่าย CVE ได้

  • สงสัยว่ามีช่องโหว่ไหนในนี้ที่น่าสนใจเป็นพิเศษไหม

  • หลายรายการเริ่มต้นด้วยข้อความว่า “ช่องโหว่ต่อไปนี้ใน Linux kernel ได้รับการแก้ไขแล้ว”

  • อดไม่ไหวเลยขอให้ LLM ช่วยตั้งชื่อที่สะดุดตาให้แต่ละ CVE
    https://git.infradead.org/~rw/cvenames-2026-07-19.html

  • ดูจากรายการแรกที่เกี่ยวกับ XFS ปัญหานี้ดูเหมือนจะเกิดขึ้นเฉพาะกับล็อกที่ถูกดัดแปลง
    สำหรับการโจมตีจริง ดูเหมือนว่าจะต้องนำไฟล์ซิสเต็มออกจากสถานะออนไลน์ก่อน แล้วเขียนลง block device ที่เก็บล็อกโดยตรง ถ้าเป็นอย่างนั้นก็ดูเหมือนว่าจะต้องมีสิทธิ์ root หรือสิทธิ์เข้าถึงทางกายภาพ รวมถึงความสามารถในการปิดระบบด้วย เลยสงสัยว่าผมเข้าใจ XFS log ผิดหรือเปล่า

    • มันอาจไม่ใช่ภัยคุกคามต่อเซิร์ฟเวอร์ที่ไม่ auto-mount USB drive หรือ SD card และมีการเฝ้าระวังทางกายภาพด้วย แต่ก็อาจกระทบกับสภาพแวดล้อม Linux แบบอื่นได้
      เช่น มีคนยื่น SD card ที่อ้างว่ามี “รูปภาพ” ให้ แต่จริง ๆ มีไฟล์ซิสเต็ม XFS อันตรายอยู่ข้างใน แล้วพอนำไปเสียบที่บ้านก็เกิดการโจมตีแบบ chain exploit ขึ้นมา การ mount ไฟล์ซิสเต็มก็ควรเป็น งานที่ปลอดภัย เหมือนกับการเปิดไฟล์ภาพ
    • แค่ความเป็นไปได้ต่ำ ไม่ได้แปลว่าไม่ใช่ช่องโหว่ที่อาจเกิดขึ้น และ สภาพแวดล้อมการใช้งาน ก็สำคัญด้วย
      อาจมีอุปกรณ์แบบ kiosk ที่ auto-mount สตอเรจทันทีเมื่อเชื่อมต่อ และปัญหาที่ปกติดูไม่สมจริงก็อาจกลายเป็นการโจมตีที่เกิดขึ้นได้จริงเมื่อรวมกับข้อบกพร่องหลายอย่างหรือสภาพแวดล้อมเฉพาะ
    • ในศูนย์โฮสติ้งแบบโคโลเคชัน การ โจมตีด้วยการเสียบ USB หรือ HDD เข้ากับเซิร์ฟเวอร์ น่าจะสำเร็จได้ราว 95%
      ถึงจะมีภาพจากกล้อง ก็อาจยืนยันได้ยากมากอย่างชัดเจนว่าไม่ได้เสียบเข้ากับเซิร์ฟเวอร์เครื่องอื่นในแร็กเดียวกัน