บางทีช่วงนี้อาจยังไม่ควรติดตั้งซอฟต์แวร์ใหม่

• หลัง copy.fail ได้มีการประกาศ ช่องโหว่ของเคอร์เนล Linux เพิ่มเติม
• ขณะนี้ถูกประเมินว่าเป็นช่วงเวลาที่ การโจมตีซัพพลายเชนของ NPM สามารถสร้างความเสียหายครั้งใหญ่ได้ง่าย
• มีคำแนะนำให้ยกเว้น แพตช์เคอร์เนล Linux ที่ดิสทริบิวชันจัดให้
• นอกเหนือจากนั้น ควรหยุดติดตั้งซอฟต์แวร์ใหม่เป็นเวลาประมาณ หนึ่งสัปดาห์
• มีหมายเหตุแนบไว้ว่า หลังจากโพสต์แล้ว ข้อเท็จจริงหรือสถานการณ์ อาจเปลี่ยนแปลงไป ดังนั้นหากมีส่วนใดที่ดูผิดหรือไม่ชัดเจน ขอให้ติดต่อมาก่อนสรุปผล

[GN⁺]

ความคิดเห็นจาก Hacker News

• นี่เป็นฝันร้ายที่ระเบิดขึ้นได้อยู่แล้วเสมอ จำนวนแพ็กเกจมีมากเกินไป และด้วยเหตุนี้ พื้นผิวการโจมตีของซัพพลายเชน ก็ขยายมหาศาล จนเป็นปัญหาที่วันหนึ่งต้องระเบิดใส่ทุกคน
  แต่มันก็สะดวกมาก คนที่พยายามเตือนหรือลดความเสียหายมักถูกเมินจากคนที่ไม่เคยลองทำแบบอื่นมาก่อน และ "import antigravity" ก็ง่ายเกินกว่าจะยอมเลิก
  ดูเหมือนตอนนี้เรากำลังเข้าสู่ช่วง “ต้องจ่ายราคา” แล้ว

  • บริษัทหนึ่งที่ผมเคยอยู่ทำงานแบบอนุรักษ์นิยมมาก ทุกองค์ประกอบภายนอกถูกตรึงเวอร์ชันไว้ ไม่อัปเดตโดยไม่ตรวจทาน และโดยปกติจะปล่อยให้มีช่วงเวลาทำให้เสถียรก่อนเสมอ
    เราสร้างแทบทุกอย่างจากซอร์ส รวมถึงคอมไพเลอร์ เคอร์เนล ฯลฯ เซิร์ฟเวอร์บิลด์/อินฟราของเราไม่เข้าถึงอินเทอร์เน็ตเลย และมีขั้นตอนเฉพาะสำหรับนำการเปลี่ยนแปลงเข้ามา เราจะทบทวน CVE ที่ประกาศออกมาทุกครั้ง เพื่อดูว่าเกี่ยวข้องกับเราหรือไม่ และจะบรรเทาหรือจัดการอย่างไร
    หลังจากนั้นผมย้ายไปอีกบริษัท ที่นั่นบิลด์เข้าถึงอินเทอร์เน็ตได้ และอัปเกรดทันทีที่มีเวอร์ชันใหม่ออกมา ผู้คนมองว่านี่เป็นแนวปฏิบัติที่ดีเพราะจะได้บั๊กฟิกล่าสุด ส่วนการทบทวน CVE เป็นหน้าที่ของทีมความปลอดภัย
    สตาร์ตอัปถัดมามีการปนกันของหลายแนวปฏิบัติ บางส่วนดีมาก แต่ก็มี หนี้ CVE สูง เช่น มี secure boot และดิสก์เข้ารหัสบนเซิร์ฟเวอร์ และค่อนข้างเข้าใจเรื่องความปลอดภัยของการสื่อสารระหว่างองค์ประกอบต่าง ๆ ดี
    ทุกคนคิดว่าตัวเองทำถูกแล้ว และแทบเป็นไปไม่ได้เลยที่จะโน้มน้าวคนสาย “อัปเกรดบ่อย ๆ” ว่ามันมีความเสี่ยงในการนำปัญหาใหม่เข้ามา วงการนี้ต้องการชุดแนวปฏิบัติที่ดีกว่าเดิม และส่วนตัวผมคิดว่าวิธีจัดการ dependency ของบริษัทแรกดีกว่า โดยรวมแล้วแนวปฏิบัติด้านความปลอดภัยของเขาฝังรากแน่น และผลิตภัณฑ์ก็ปลอดภัยจริง ๆ
  • ถ้าจะเปิดกล่องแพนดอรา สมมติว่าผลสุทธิของการเปิดเผยเวกเตอร์โจมตีที่ไม่เคยรู้มาก่อนเหล่านี้ทั้งหมด คือการทำให้คลังช่องโหว่ที่หน่วยข่าวกรองทั่วโลกเก็บสะสมไว้ถูกใช้จนหมด จะเป็นอย่างไร
    ซอฟต์แวร์ที่มีประโยชน์ทั้งหมดจะถูกทำ fuzzing test, property test และ formal verification จนคนที่มองหาช่องโหว่ทุกคนต้องเริ่มต้นใหม่ตั้งแต่ศูนย์
    แน่นอนว่าสิ่งนี้ตั้งอยู่บนสมมติฐานว่าเราจะทนผ่านช่วงสุญญากาศระหว่างนั้นได้ ระหว่างที่แต่ละประเทศโยนเครื่องมือที่เหลือทั้งหมดใส่ศัตรูที่เลวร้ายที่สุดของตน หรือไม่สุดท้ายเราอาจต้องกลับไปตีหัวกันด้วยกระดูกสัตว์ก็ได้
  • ผมอยากได้ โมเดลความปลอดภัยแบบ capability มาหลายปีแล้ว และก็เคยถกเรื่องนี้ที่นี่ด้วย capability เป็นเหมือนตัวชี้ไปยังอ็อบเจ็กต์ที่มีสิทธิ์ที่เกี่ยวข้อง คล้ายกับ Unix file descriptor
    ในระดับระบบปฏิบัติการ โปรแกรมที่ถูกรันควรได้รับการส่งต่อโทเคนสิทธิ์มาจากเชลล์หรือจุดที่เรียกใช้ และทุก system call ควรต้องรับ capability เป็นอาร์กิวเมนต์ตัวแรก ดังนั้น "open path /foo" จะกลายเป็น open(cap, "/foo") capability นี้จะเป็นอะไรก็ได้ เช่น ไฟล์ซิสเต็มปลอม, กิ่งหนึ่งของไฟล์ซิสเต็มจริง, network filesystem ฯลฯ และโปรแกรมก็ไม่จำเป็นต้องรู้ว่าตัวเองอยู่ใน sandbox แบบไหน
    ในระดับไลบรารี/ภาษา เวลานำเข้าไลบรารีของบุคคลที่สามอย่าง npm module ก็ควรต้องส่งต่อ capability ทุกครั้งที่ import หรือทุกตำแหน่งที่เรียกใช้ ไลบรารีนั้นไม่ควรได้สิทธิ์อ่าน/เขียนทุกไบต์ใน address space ของโปรแกรมผม และไม่ควรทำอะไรก็ได้บนคอมพิวเตอร์ของผมราวกับเป็นตัวผมเอง คำถามสำคัญคือ “รัศมีการระเบิด ของโค้ดชิ้นนี้กว้างแค่ไหน?” ถ้าไลบรารีที่ใช้อยู่เป็นอันตรายหรือมีช่องโหว่ เราต้องมีค่าเริ่มต้นที่สมเหตุสมผลสำหรับขนาดของความเสียหาย การเรียก lib::add(1, 2) ไม่ควรนำไปสู่การยึดเครื่องทั้งเครื่องแบบถาวร
    SeL4 ให้ capability ระดับระบบปฏิบัติการที่เร็วและมีประสิทธิภาพมานานแล้ว และใช้งานได้ดีมาก ในหลายกรณีมันเร็วกว่า Linux และมีประโยชน์มากสำหรับ transparent sandboxing, ไดรเวอร์ user space, การสื่อสารระหว่างโปรเซส และการปรับปรุงความปลอดภัยต่าง ๆ คุณยังสามารถรัน Linux เป็นโปรเซสบน SeL4 ได้ด้วย ผมอยากได้ระบบปฏิบัติการที่มีความสามารถครบแบบ Linux desktop แต่ทำงานเหมือน SeL4
    น่าเสียดายที่ดูเหมือนไม่มีภาษาโปรแกรมใดที่มี capability ระดับภาษาในแบบที่ผมต้องการ Rust ใกล้เคียงมาก แต่เราจำเป็นต้องมีวิธีจำกัดไม่ให้ third-party crate เรียกใช้ unsafe code ใด ๆ ได้ รวมถึง unsafe ที่ถูกเรียกผ่าน dependency ที่เราไม่ไว้ใจ ต้องแก้ soundness bug เก่า ๆ ของ Rust ด้วย และต้องมี standard library แบบ capability ด้วย ควรเลิกมี open() / listen() แบบ global และควรเหลือแค่รูปแบบอย่าง openat() กับรูปแบบเทียบเท่าสำหรับส่วนอื่น ๆ ของระบบปฏิบัติการ
    ถ้า LLM ยังพัฒนาต่อไปเรื่อย ๆ อีกไม่กี่ปี ถ้ายังไม่มีใครทำก่อน ผมกะจะให้ LLM สร้างทั้งหมดนี้ให้เลย ความปลอดภัยของระบบปฏิบัติการเดสก์ท็อปสมัยใหม่เป็นเรื่องน่าขำ
  • คนส่วนใหญ่ไม่ได้เอาอะไรก็ได้เข้าปากโดยปริยาย พวกเขาไม่ได้รอผลเพาะเชื้อจุลินทรีย์ออกมาเป็นบวกแล้วค่อยปฏิเสธมัน
    โค้ดก็ต้องการ วัฒนธรรมด้านสุขอนามัย เช่นกัน และมันก็ไม่ได้ต่างจากบรรทัดฐานที่วัฒนธรรมส่วนใหญ่พัฒนาขึ้นมาสำหรับอาหารมากนัก มันเป็นการผสมของฮิวริสติกหยาบ ๆ แต่ความรู้สึกแบบ “อี๋” นี่แหละที่ช่วยชีวิตคนไว้เป็นพันล้าน
  • เมื่อปีก่อน ผมเคยเสนอว่าถ้าเป็นไปได้ ควรเขียนโค้ดเองแทนการดึงของ third-party เข้ามา ตอนนั้นแม้แต่การพิจารณาให้ LLM มาอุดช่องว่างก็ยังถูกมองเหมือนเป็นพวกนอกรีต
    ตอนนี้ผมลดการเปิดรับ dependency ลงมากกว่าที่เคย โดยเฉพาะสิ่งที่เขียนเองได้ในไม่กี่ร้อยบรรทัด นี่คือ การเปลี่ยนกระบวนทัศน์ แบบเต็ม ๆ

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

  • ผู้เขียนดูเหมือนจะไม่ได้หมายความว่าควรหน่วงทุกการอัปเดตต่อไปเรื่อย ๆ แต่เสนอให้ รอหนึ่งสัปดาห์แบบครั้งเดียว จนกว่าจะแก้ไขและกระจายแพตช์สำหรับช่องโหว่เฉพาะที่ถูกเปิดเผยเร็วเกินไปในครั้งนี้เสร็จสิ้น นอกนั้นผมเห็นด้วย
  • คิดว่าคุณเข้าใจบทความผิด ข้อเสนอไม่ใช่ให้รอหนึ่งสัปดาห์หลังซอฟต์แวร์ถูกปล่อยออกมาแล้วค่อยติดตั้ง แต่หมายถึงตั้งแต่ตอนนี้ไปอีก 7 วัน อย่าเพิ่งติดตั้งอะไรเลย
    เพราะมีโอกาสสูงที่แพตช์สำหรับช่องโหว่เหล่านี้ยังไม่มี และถึงมี ก็น่าจะมีช่องโหว่ที่น่ากลัวยิ่งกว่าถูกค้นพบอีกในไม่ช้า
  • ถ้าอย่างนั้นก็รอสักหนึ่งหรือสองเดือนก็ได้ ประเด็นสำคัญของช่วงรอไม่ใช่การป้องกันไม่ให้ exploit ที่ติดตั้งไปแล้วทำงาน แต่เพื่อหลีกเลี่ยง การติดตั้ง exploit ใหม่
  • แพ็กเกจยอดนิยมมีการเปิดรับมากกว่า เมื่อปล่อย artifact ออกมาแล้ว คนทั้งโลกก็มองเห็นได้ และคาดได้ว่าจะมีคนตรวจ diff ระหว่างเวอร์ชัน
    แต่ถ้าไม่มีความหน่วงเลย คุณอาจโดน exploit ที่ยังไม่มีใครเห็นมาก่อนก็ได้
  • dependency compromise ที่ผมนึกออกในช่วง “ไม่กี่เดือนที่ผ่านมา” ทั้งหมดถูกพบภายในไม่กี่นาที ไม่ใช่ไม่กี่ชั่วโมง เช่น litellm, axios, bitwarden CLI, Checkmarx Docker image, Pytorch lightning และ intercom/intercom-php
    ยิ่งไปกว่านั้น การตรวจพบการโจมตีเหล่านี้ไม่ได้ขึ้นอยู่เลยว่ามันถูกนำไปใช้ประโยชน์จริงหรือไม่ ดังนั้นผมจึงไม่เข้าใจคำพูดที่ว่า “ถ้าทุกคนรอหนึ่งสัปดาห์ ผู้โจมตีจะรอสองสัปดาห์”

• อีกทางเลือกหนึ่งคือย้ายไปใช้ระบบปฏิบัติการอย่าง FreeBSD ที่ไม่เข้าหาความปลอดภัยแบบ YOLO
  security fix จะไม่ถูกโยนเข้า FreeBSD kernel แบบไร้การประสานงาน แต่มันจะผ่านทีมความปลอดภัยของ FreeBSD และหลังจากแพตช์เข้า src tree แล้ว ไม่กี่นาทีต่อมา binary update ก็ถูกปล่อยผ่าน FreeBSD Update และ pkgbase สำหรับ 15.0-RELEASE
  โดยคร่าว ๆ คือใช้เวลาไม่กี่วินาทีให้มีข้อความใน Slack ว่า “push patch แล้ว”, 10–30 วินาทีในการอัปโหลดแพตช์ และไม่เกิน 1 นาทีสำหรับการซิงก์ mirror

  • ผมค่อนข้างกังขากับเรื่องนี้อยู่บ้าง เมื่อหลายปีก่อนผมเคยรายงานช่องโหว่ให้ทีมความปลอดภัย FreeBSD และอีกหลายสัปดาห์ต่อมาก็ส่งอีเมลติดตาม แต่ไม่ได้รับคำตอบ
    เพื่อความเป็นธรรม รายงานของผมเกี่ยวกับสิ่งที่ไม่ใช่องค์ประกอบหลักและก็ไม่ได้ใช้ประโยชน์ง่าย แต่ Debian, OpenBSD, SUSE และ Gentoo ต่างก็แพตช์ภายในหนึ่งสัปดาห์ https://www.maxchernoff.ca/p/luatex-vulnerabilities#timeline
    ไม่ได้หมายความว่าเราควรตัดสินทั้งระบบปฏิบัติการจากการจัดการรายงานเล็ก ๆ เพียงครั้งเดียว เพราะทุกอย่างอื่นที่ผมเห็นชี้ไปทางว่า FreeBSD ค่อนข้างจริงจังกับรายงานด้านความปลอดภัย เพียงแต่ตรรกะแบบเดียวกันนี้ก็ใช้กับบั๊กของ Linux kernel ได้เช่นกัน การจัดการแพตช์พลาดแบบนั้นใน Linux ก็ถือว่าค่อนข้างหายาก
  • ถ้าจะย้ายไป BSD เพราะเหตุผลด้านความปลอดภัย ทำไมถึงเป็น FreeBSD? OpenBSD ไม่ใช่ตัวที่ขึ้นชื่อว่าปลอดภัยมากกว่าหรือ? ผมถามเพราะไม่ได้ตามโครงการพวกนี้มานานแล้ว
  • FreeBSD ค่อนข้างหลวมเรื่องความปลอดภัย โดยเฉพาะในแง่ค่าเริ่มต้นและการตั้งค่า
    มันเอนเอียงไปทางการใช้งานมากกว่าความปลอดภัย ตัวอย่างที่มีชื่อเสียงอยู่ที่นี่: https://vez.mrsk.me/freebsd-defaults
    ผมซาบซึ้งกับการมีส่วนร่วมในโครงการนี้ แต่ตราบใดที่ยังมีค่าเริ่มต้นที่แย่แบบนี้ ผมก็ไม่อาจแนะนำให้คนย้ายไปได้อย่างสบายใจ
  • FreeBSD ไม่มี ASLR ใน user space จนถึงปี 2019 และยังไม่มี kASLR ซึ่งเป็นอีกหนึ่งมาตรการบรรเทา สำหรับคนที่ให้ความสำคัญกับความปลอดภัย มันไม่ใช่ระบบปฏิบัติการที่จริงจัง
    ถ้าคุณต้องการ FreeBSD พร้อมความปลอดภัย ก็ควรใช้ HardenedBSD ของ Shawn Webb
  • เวลามีเรื่องแบบนี้จะต้องมีใครสักคนโผล่มาเสมอ ดีใจด้วยที่ดิสโทรที่คุณชอบ “ปลอดภัยกว่าแน่นอน” แม้สุดท้ายจะยังเหลือ exploit อยู่สักหลายพันตัว ต่อให้ลดลงไปแบบหลักหน่วยเท่าก็ตาม Ozymandias คงใช้ Gentoo

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

  • ผมจำได้ว่ามีช่วงหนึ่งในหมู่ influencer อังกฤษนิยมใช้วิธี “บันไดกับเสื้อกั๊กสะท้อนแสง” เพื่อเข้าไปในสถานที่ต่าง ๆ แล้วโชว์ให้เห็นว่าความปลอดภัยทางกายภาพหละหลวมแค่ไหน https://www.youtube.com/watch?v=LTI0SeyhAPA
    เท่าที่รู้ ยูทูบเบอร์ชื่อ Max Fosh เคยเข้า International Security Expo ได้ติด ๆ กัน ในอังกฤษเขาใช้ชื่อปลอมว่า “Rob Banks” ใน https://www.youtube.com/watch?v=qM3imMiERdU และในสหรัฐฯ ใช้ชื่อ “Nick Everything” ใน https://www.youtube.com/watch?v=NmgLwxK8TvA
    ผมเคยศึกษาวัฒนธรรมด้านความปลอดภัยมาบ้าง และส่วนใหญ่สุดท้ายจะลงเอยเป็น สเกลแบบเลื่อน ที่ด้านหนึ่งคือความปลอดภัย อีกด้านคือความสะดวก/การเข้าถึง ยิ่งปลอดภัยก็ยิ่งเข้าถึงยาก และกลับกันก็เช่นกัน

• การโจมตีซัพพลายเชนต่อ dependency manager อย่าง npm, PyPI, Cargo นั้นมีวิธีแก้ที่ค่อนข้างดีอยู่แล้ว คือกำหนดให้ติดตั้งเฉพาะแพ็กเกจเวอร์ชันที่มีอายุเกินหลายวัน
  การโจมตีใหญ่ ๆ ล่าสุดทั้งหมดถูกพบและย้อนกลับภายในหนึ่งวัน ดังนั้นถ้าทำแบบนี้ก็จะเลี่ยงได้อย่างปลอดภัย พฤติกรรมนี้ควรเป็นค่าเริ่มต้น ปล่อยให้เบต้าเทสเตอร์ที่สมัครใจเองกับบริษัทสแกนความปลอดภัยใช้แพ็กเกจเวอร์ชันล่าสุดก่อนสักหนึ่งวันก็พอ วิธีอยู่ที่นี่: https://cooldowns.dev/

  • เครื่องมือแบบนี้ที่ขึ้นบน Show HN เมื่อ 3 เดือนก่อนดูจะเหมาะกว่า: https://github.com/artifact-keeper
    มันคือ ตัวจัดการ artifact ที่ทำให้ดึงมาได้เฉพาะสิ่งที่อนุมัติแล้ว คุณอัปเดตได้เร็วเมื่อจำเป็น และใช้เวอร์ชันเสถียรที่ตรวจสอบอย่างสม่ำเสมอได้เมื่อจำเป็น ต้อง override การตั้งค่านิดหน่อย แต่เป็นงานง่าย
    ผมเคยทำเครื่องมือห่วย ๆ เองเพื่อจุดประสงค์คล้ายกันมาก่อน อันนี้เป็นโปรเจ็กต์ที่ดี
  • วิธีที่ดีกว่าคือให้บริษัทใช้เฉพาะ repository ที่ตรวจสอบแล้ว และไม่ให้ใครติดตั้งตรงจาก repository บนอินเทอร์เน็ต
    แน่นอนว่านอกบริบทองค์กร วิธีนี้มักใช้ไม่ได้ผลตามธรรมชาติ
  • แต่นั่นจะทำให้ได้รับอัปเดตความปลอดภัยช้าลงไม่ใช่หรือ? ช่องโหว่จำนวนมากมีอยู่ในระบบจริงเป็นเวลาหลายปีก่อนจะถูกค้นพบและแพตช์
    พอถูกค้นพบแล้วมักตามมาด้วยการระเบิดของ exploit ทันที และการอัปเดตช้าก็ยิ่งให้เวลาผู้โจมตีที่กำลังฮึกเหิมมากขึ้น
  • โดยส่วนตัวผมคิดว่าแนวทางที่ยั่งยืนที่สุดคือโมเดล Linux distribution/BSD ports/Homebrew คือไม่ได้ push ไลบรารีใหม่เข้าระเบียนสาธารณะทันที แต่เขียน packaging script ที่ถูกตรวจทานทุกครั้งที่มีการเปลี่ยนแปลงใหม่
    อีกโมเดลหนึ่งคือ CPAN ของ Perl ที่แจกจ่ายเฉพาะ source file

• คนที่เพิ่งนำ continuous integration และ containerized build มาใช้ไม่นาน ควรลองตรวจระบบดูว่าในทุกบิลด์กำลังดึง latest จากหลายแพ็กเกจอยู่หรือไม่
  เราสร้าง base container ที่รวม dependency ภายนอกทั้งหมดไว้ แล้วค่อยอัปเดตแบบ explicit เฉพาะเมื่อเห็นว่าถึงเวลาแล้ว
  เพราะงั้นแม้อาจตามหลังของใหม่สุดอยู่เล็กน้อย แต่ก็รับความเสี่ยงน้อยกว่ามากที่จะโดน ช่องโหว่ซัพพลายเชน แบบสุ่มแล้วกระจายไปทั่วโลกทันที

  • คุณจะพบว่าวิธีนี้ลดทั้งเวลาบิลด์ CI และความล้มเหลวแบบไม่เสถียรได้มากเช่นกัน
  • เพิ่มเติมคือ ควรใช้เฉพาะ repository ภายใน

• นี่เป็นบทความแสดงความคิดเห็นที่เป็นอันตรายอย่างชัดเจน เข้าใจตรรกะได้ยากมาก
  ใช้เวลาแค่ 45 วินาทีก็พอจะตรวจดูได้แล้วว่า copyfail กับ dirtyfrag มีมานานแค่ไหน ซึ่งยังนานกว่าการอ่านบทความเสียอีก Dirtyfrag อาจเกี่ยวข้องกับระบบที่ย้อนหลังไปถึงปี 2017
  สิ่งที่ได้รับผลกระทบไม่ใช่ซอฟต์แวร์ “ใหม่” และซอฟต์แวร์เก่าจริง ๆ ก็แย่กว่าเสียอีก เพราะมีเวลามากกว่ามากให้คนหาปัญหาเจอ

  • บทความต้นฉบับเสนอว่าถ้าตอนนี้เกิดการโจมตีซัพพลายเชนขึ้น มันอาจแย่มาก ดังนั้นจึงควรเลี่ยงการติดตั้ง/อัปเดตแพ็กเกจ NPM เพื่อลดความเสี่ยงนั้น

• สักวันหนึ่งคงมีใครสักคนสร้างใหม่ทั้ง สแตกทั้งหมด ตั้งแต่ระบบปฏิบัติการไปจนถึงแอปพลิเคชัน ด้วยการอัปเกรดแบบ proof-carrying code
  วิธีเดียวที่จะรันโค้ดที่เชื่อถือได้ คือการออกแบบและสร้าง proof กับ code ไปด้วยกัน

• เรื่องนี้ไม่ได้ใช้ได้กับซอฟต์แวร์เท่านั้น แต่จริง ๆ ใช้ได้กับแทบทุกอย่าง
  จำไม่ได้ว่าอ่านมาจากไหน แต่สุดท้ายมันลงเอยที่ความต่างระหว่าง ความจำเป็นกับความอยาก
  ผมใช้กฎนี้เวลาตัดสินใจว่าจะซื้อรถใหม่หรือรถมือสอง จะซื้อเครื่องดูดฝุ่นแพงหรือรุ่นพื้นฐาน รวมถึงกับการซื้อแก็ดเจ็ตใหม่ ๆ การนำอะไรใหม่เข้ามาในเทคสแตก และการเลือกเทคสแตกใหม่ด้วย

• อยากได้ความช่วยเหลือในการเข้าใจว่า copyfail คืออะไร และมันเชื่อมกับแพ็กเกจ NPM อย่างไร
  เท่าที่ผมสรุป copyfail ดูจะเป็น บั๊กของเคอร์เนล ที่ทำให้แพ็กเกจ npm อันตรายสามารถยกระดับสิทธิ์เป็น root บนเซิร์ฟเวอร์ Linux ได้
  ดังนั้นช่วงเวลานี้ที่ยังมีเซิร์ฟเวอร์ที่ไม่ถูกแพตช์อยู่มาก จึงเป็นจังหวะสมบูรณ์แบบที่ผู้โจมตีจะเล็งแพ็กเกจ NPM
  เหตุผลที่คำแนะนำไม่ใช่แค่ “อัปเดตเคอร์เนล” เป็นเพราะยังมีการค้นพบปัญหาใหม่ที่เกี่ยวข้องอย่างต่อเนื่องอยู่ใช่ไหม?

  • แพตช์สำหรับช่องโหว่ล่าสุดยังไม่ออกมาเลย ดังนั้นถ้าตอนนี้เกิด การโจมตีซัพพลายเชน ใหม่ขึ้น มันจะเป็นช่วงเวลาที่เลวร้ายมาก เพราะแทบทุกระบบจะถูกยึดสิทธิ์ root ได้
  • การโจมตีซัพพลายเชนของ NPM แพร่เร็วมาก
    ถ้าแพ็กเกจ NPM ยอดนิยมถูกเจาะและฝัง copy.fail exploit ไว้ หลายระบบก็จะเสี่ยงต่อการยกระดับสิทธิ์เป็น root
  • เหตุผลที่คำแนะนำไม่ใช่ “อัปเดตเคอร์เนล” ก็เพราะยังไม่มีอัปเดต ช่องโหว่ล่าสุดที่ถูกพบหลัง copy.fail ยังไม่ได้รับการแก้ไข