แพ็กเกจ AUR ติดมัลแวร์ขโมยข้อมูลและรูทคิต

 (discourse.ifin.network)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • คลังแพ็กเกจ AUR เป็นโครงสร้างที่เปิดให้ใครก็ได้เข้ามารับช่วงแพ็กเกจที่ไม่มีผู้ดูแลและส่งการเปลี่ยนแปลง PKGBUILD กับไฟล์ที่เกี่ยวข้องได้ โดยในเหตุการณ์นี้มีสัญญาณว่ามีแพ็กเกจมากกว่า 408 รายการถูกฝังมัลแวร์
  • ผู้ดูแลแพ็กเกจ AUR รายใหม่แอบอ้างเป็นผู้ดูแลที่น่าเชื่อถือเพื่อรับช่วงแพ็กเกจ และผู้ดูแล AUR รายอื่นกำลังดำเนินการลบแพ็กเกจที่ติดมัลแวร์
  • แพ็กเกจที่ติดเชื้อระยะแรกถูกแก้ให้รัน npm ผ่านสคริปต์ preinstall เพื่อติดตั้ง atomic-lockfile ซึ่งเป็นเพย์โหลดอันตราย
  • การติดเชื้อในระยะถัดมาใช้ Bun เพื่อติดตั้ง js-digest ที่เป็นอันตราย และ NPM ได้ลบแพ็กเกจดังกล่าวแล้ว
  • แพ็กเกจส่วนใหญ่แทบไม่ค่อยถูกใช้งาน แต่ประเด็นสำคัญคือขอบเขตการโจมตีที่กว้าง และเป็นการโจมตีซัพพลายเชนที่นอกจากขโมยข้อมูลแล้วยังมี eBPF rootkit รวมอยู่ด้วย

สถานการณ์เหตุการณ์

  • เกิดอะไรขึ้น

    • มีสัญญาณว่าผู้ดูแลแพ็กเกจ AUR รายใหม่แอบอ้างเป็นผู้ดูแลที่น่าเชื่อถือ แล้วเข้ารับช่วงและฝังมัลแวร์ในแพ็กเกจมากกว่า 408 รายการ
    • หลังมีการรายงานการเจาะระบบ ผู้ดูแล AUR รายอื่นได้เริ่มดำเนินการลบแพ็กเกจที่ติดมัลแวร์
    • ณ เวลา 2026-06-12T17:30:00Z ผู้ดูแล AUR รายงานว่าได้ลบคอมมิตอันตรายทั้งหมดแล้ว
    • ผู้ดูแล AUR ตัดสินใจจะเพิ่มการควบคุมและข้อจำกัดกับบางฟีเจอร์ รวมถึงฟีเจอร์การรับช่วงแพ็กเกจ
    • Arch Linux ออกประกาศ Active AUR malicious packages incident

  • Dependency อันตราย

    • การโจมตีนี้มี dependency อันตรายแยกกันอย่างน้อยสองตัว
    • แพ็กเกจที่ได้รับผลกระทบในช่วงแรกถูกแก้ไขให้ใช้ npm ในสคริปต์ preinstall เพื่อติดตั้งแพ็กเกจ atomic-lockfile ซึ่งเป็นเพย์โหลดอันตราย
    • แพ็กเกจ premake-git มี คอมมิตตัวอย่าง ของการเปลี่ยนแปลงนี้
    • การติดเชื้อในภายหลังใช้ Bun เพื่อติดตั้ง js-digest ที่เป็นอันตราย และ NPM ได้ลบ js-digest แล้ว
    • การวิเคราะห์การโจมตีมีรายละเอียดอยู่ใน Preliminary analysis of AUR malware

การตอบสนองและตัวบ่งชี้การเจาะระบบ

  • มาตรการที่แนะนำ

    • หากไม่ได้ใช้ Arch คุณไม่ใช่เป้าหมายที่ได้รับผลกระทบโดยตรงจากการเจาะแพ็กเกจ AUR ครั้งนี้
    • ผู้ใช้ Arch ควรตรวจสอบรายชื่อแพ็กเกจที่ได้รับผลกระทบ และใช้สคริปต์ตรวจสอบการเปิดเผยความเสี่ยงเพื่อตรวจระบบของตน
    • aur_check.sh ที่ลิงก์ไว้ในต้นฉบับเป็นเวอร์ชันเก่า และการตรวจสอบล่าสุดควรอ้างอิงตามคำแนะนำใน Gist นั้น
    • หากพบตัวบ่งชี้การเจาะระบบ ควรเก็บรักษาระบบไว้เพื่อการตรวจพิสูจน์หลักฐานที่เหมาะสม
    • หากพบแพ็กเกจที่ติดมัลแวร์ ควรปฏิบัติตามกระบวนการรับมือเหตุเจาะระบบตามปกติ เปลี่ยนข้อมูลรับรองทั้งหมด และพิจารณาติดตั้ง Arch ใหม่
    • เนื่องจากมีความเป็นไปได้ของรูทคิต จึงไม่อาจรับรองความน่าเชื่อถือของระบบได้อีกต่อไป
    • ผู้ใช้ทุกคนควรดำเนินมาตรการบล็อกทราฟฟิก Tor ขาออกจากเครือข่าย

  • ตัวบ่งชี้การเจาะระบบ

    • ค่า SHA256 ของไฟล์ปฏิบัติการ Linux อันตรายที่ฝังอยู่ใน js-digest คือ 7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316
    • สามารถใช้ bpftool map list เพื่อตรวจหา eBPF Maps ที่น่าสงสัยได้
    • ชื่อ map ที่น่าสงสัย ได้แก่ hidden_pids, hidden_names, hidden_inodes

  • ข้อสังเกตเพิ่มเติม

    • ไม่ใช่ว่าบัญชีผู้ดูแลเดิมเป็นผู้ทำคอมมิตอันตราย แต่เป็นการแอบอ้างบัญชีผู้ดูแลที่เป็นที่รู้จัก
    • แพ็กเกจส่วนใหญ่แทบไม่ค่อยถูกใช้งาน แต่ขอบเขตการติดเชื้อที่มากกว่า 408 รายการถือว่ากว้างมาก
    • การโจมตีซัพพลายเชนที่นอกจากขโมยข้อมูลแล้วยังมี eBPF rootkit รวมอยู่ด้วย เป็นกรณีที่พบได้ไม่บ่อย
    • หน้า atomic-lockfile บน Socket.dev แสดงจำนวนดาวน์โหลดของแพ็กเกจ NPM อันตรายนี้ไว้ที่ 134 ครั้ง
    • แพ็กเกจ NPM นี้ดูแลโดยผู้ใช้ herbsobering
    • เมื่อค้นหาชื่อผู้ใช้ herbsobering บน GitHub จะพบคอนเทนเนอร์อิมเมจเดี่ยวที่ดูเหมือนเป็นเครื่องมือ reverse shell/proxy คือ herbsobering430
    • คลังแพ็กเกจ AUR เปิดให้ใครก็ได้เข้ามารับช่วงแพ็กเกจ หากแพ็กเกจนั้นถูกระบุว่าไม่มีผู้ดูแล และสามารถส่งการเปลี่ยนแปลง PKGBUILD กับไฟล์ที่เกี่ยวข้องได้
    • การค้นหาและรับช่วงแพ็กเกจที่ถูกทิ้งร้างแบบอัตโนมัติไม่ใช่เรื่องแปลก และมีข้อมูลพื้นหลังที่เกี่ยวข้องใน เธรด Mastodon

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

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

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Hacker News

  • ต้องยอมรับว่า AUR เป็นเพียงชุดรวม PKGBUILD ที่ผู้ใช้สร้างขึ้น
    ควรตรวจสอบซอร์สของ PKGBUILD ทุกตัวที่ติดตั้งจาก AUR เสมอ และการอัปเดตก็ไม่ใช่ข้อยกเว้น นี่เป็นหลักการที่ถกเถียงกันต่อเนื่องมานานกว่าสิบปีแล้ว และนี่ก็เป็นเหตุผลว่าทำไมจึงไม่มี AUR helper อย่างเป็นทางการเช่น yay
    มีคนบ่นกันมากว่า Arch Linux เป็นพวกชนชั้นสูง แต่ในความเป็นจริงมันคือดิสทริบิวชันสำหรับคนที่รู้ว่าตัวเองกำลังทำอะไร และไม่ต้องการให้มีคนจูงมือทุกขั้นตอน ซึ่งก็หมายความด้วยว่าถ้าคุณติดตั้งแพ็กเกจ AUR แบบสุ่มแล้วทำให้ระบบพังหรือถูกเจาะ ก็เป็นความรับผิดชอบของคุณเอง
    อย่างไรก็ตาม ยุคที่ปล่อยให้ใครก็รับช่วงแพ็กเกจ AUR ได้อาจใกล้จบลงแล้ว แค่ดูต้นทุนในการย้อนกลับแพ็กเกจที่ได้รับผลกระทบในแต่ละครั้งก็สูงเกินไป ส่วนทางเลือกอย่างการตรวจสอบคำขอรับช่วงทั้งหมดก็ภาระมากเกินไป และไม่ได้รับประกันด้วยว่าจะช่วยได้ทุกครั้ง

    • ถ้าต้องตรวจสอบซอร์สของ PKGBUILD ทุกตัวที่ติดตั้งจาก AUR ผมก็คิดว่าหลักการเดียวกันนี้ก็ควรใช้กับ ส่วนขยายเบราว์เซอร์, ส่วนขยาย VSCode, แพ็กเกจ NuGet, Cargo crate, แพ็กเกจ Python, แพ็กเกจ npm และอื่น ๆ ด้วยไม่ใช่หรือ
      ผมคิดว่าใช่ เว้นแต่คุณจะไม่รันมันในที่ที่เข้าถึงอินเทอร์เน็ตไม่ได้ หรือเข้าถึงได้แค่ข้อมูลที่เปิดเผยต่อสาธารณะอยู่แล้ว
      AUR อาจไม่ใช่ แต่ระบบนิเวศอื่น ๆ พอจะปรับปรุงได้ในทางทฤษฎีด้วยโมเดลสิทธิ์หรือ sandbox ส่วนส่วนขยายเบราว์เซอร์มีตัวเลือกนั้นอยู่แล้ว แต่ผู้ใช้ “ทั่วไป” แทบไม่ใช้กัน
      น่าเสียดายที่คน 99.99% ไม่สามารถตรวจสอบทุกอย่างได้ หรือไม่มีเวลาทำ ดูแล้วสิ่งที่ปลอดภัยที่สุดน่าจะเป็นแพ็กเกจของดิสทริบิวชันที่มีผู้ดูแลที่เชื่อถือได้ หรือร้านอย่าง iOS App Store ที่มีสิทธิ์และมีการกลั่นกรองอยู่บ้าง
    • ผมไม่คิดว่านี่จะเป็นทางออกที่แท้จริง เพราะรูปแบบทั่วไปของการโจมตีแบบนี้คือ ซ่อนเพย์โหลดไว้ที่ไหนสักแห่งใน dependency
      เคสนี้ค่อนข้างแปลกตรงที่ไป npm install แบบไม่เนียนเอามาก ๆ ใน PKGBUILD ตอนนี้คลังแพ็กเกจแทบทุกแห่งนอก AUR ก็มีปัญหาเดียวกัน และการตรวจสอบห่วงโซ่ dependency ทั้งหมดด้วยมือก็ไม่สมจริง
      แน่นอนว่าผมเองก็ไม่มีทางออกเหมือนกัน
    • การเชื่อว่ามีผู้ใช้แม้เพียงส่วนน้อยที่ทำแบบนี้จริง ๆ เป็นความคิดที่ ห่างไกลจากความเป็นจริงอย่างมาก
    • ผมสงสัยว่า การที่ AUR เป็นชุดรวม PKGBUILD ที่ผู้ใช้สร้างขึ้นนั้น ต่างจากระบบนิเวศ PyPI, npm หรือ Docker Hub ทั้งหมดมากแค่ไหน
      ผู้คนปิด SELinux, ใช้ --privileged เพื่อปิด seccomp และ AppArmor และก็ยังมี CVE สำหรับการหนี sandbox อยู่ด้วย
    • เดิมทีไม่ควรมีทางให้ใครก็ได้มารับช่วงแพ็กเกจ AUR อยู่แล้ว
      สุดท้ายผมอยากให้มันกลายเป็นโครงสร้างแบบ username/packagename-bin|git อย่างน้อยแบบนั้นคนจะเห็นชัดขึ้นมากว่าจริง ๆ แล้วกำลังติดตั้งอะไรจากใคร

  • แคมเปญนี้ยังดำเนินอยู่ ผมเพิ่งได้รับอีเมลว่าแพ็กเกจเก่าอันหนึ่งของผมถูกมีคนรับช่วงไป ทั้งที่มันใช้งานไม่ได้มาหลายปีแล้วและเป็นแพ็กเกจกำพร้ามาระยะหนึ่ง จากนั้นก็มี คอมมิตอันตราย ถูกอัปขึ้นมาทันทีหลังรับช่วง
    ตอนนี้ดูเหมือนว่าจะใช้ bun แทน npm แล้ว ดังนั้นวิธีเลี่ยงที่อิง npm อาจใช้ไม่ได้ผล
    https://aur.archlinux.org/cgit/aur.git/commit/?h=toggldeskto...

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

  • การต้องระวังเวลาไปติดตั้งอะไรจาก AUR เป็นเรื่องปกติ และก่อนหน้านี้ก็มีแพ็กเกจน่าสงสัยอยู่เสมอ เช่น สร้างผิดหรือแพ็กเกจผิด แต่การได้เห็น การฝังโค้ดอันตรายแบบเชิงรุก ก็น่ากังวล
    ผมคิดว่า AUR มีปัญหาใหญ่สองอย่าง อย่างแรกคือมันเป็นเศษตกค้างจากยุคโอเพนซอร์สที่ค่อนข้างเท่าเทียมมากกว่าและยังพอเชื่อใจโค้ดของบุคคลที่สามได้ อย่างที่สองคือใครก็รับช่วงแพ็กเกจกำพร้าได้พร้อมประวัติเดิมและประวัติการตรวจสอบเดิมทั้งหมด
    ยุคแรกจบไปแล้ว ส่วนอย่างหลังบรรเทาได้ด้วยการควบคุมบัญชี AUR ให้เข้มงวดขึ้น หรือเพิ่มกลไกป้องกันในฝั่ง AUR helper เช่น ถ้าเป็นแพ็กเกจที่เพิ่งเปลี่ยนเจ้าของ ก็ควรขึ้นคำเตือนใหญ่ ๆ ให้น่ากลัวเข้าไว้ แน่นอนว่าบางคนก็ยังคงกด y แล้วผ่านไปอยู่ดี แต่ก็ยังดีกว่าไม่มีอะไรเลย
    หรือไม่ก็เลี่ยง AUR helper ไปเลย แล้วตรวจสอบ PKGBUILD และ build แพ็กเกจที่ต้องการด้วยตัวเอง

    • นโยบายการรับช่วงแพ็กเกจ ไม่เคยสมเหตุสมผลเลยแม้แต่ครั้งเดียว
    • ผมกลับมองว่า AUR helper ทำให้รวมขั้นตอนการตรวจสอบเข้ากับ workflow ได้ง่ายขึ้น
      มันคอยถามอย่างจริงจังให้ตรวจสอบ และยังบอกด้วยว่ามีการเปลี่ยนแปลงหลังจากที่คุณยอมรับความเสี่ยงครั้งล่าสุดหรือไม่
      แต่ถึงอย่างนั้น มุมมองว่า “AUR เป็นอันตราย” ก็ไม่ใช่เรื่องใหม่ คนที่ใช้ AUR ควรเข้าใจความเสี่ยงตรงนี้ และในทางปฏิบัติมันก็แค่ดีกว่าการเอาของที่เจอบน StackOverflow มาทำ curl | bash อยู่ขั้นหนึ่งเท่านั้น

  • แม้จะผ่านไปเกิน 7 ชั่วโมงแล้ว ก็ยังไม่มีการกล่าวถึงเรื่องนี้บน archlinux.org หรือ aur.archlinux.org เลย ไม่รู้ว่าทำไม น่าจะ ปิด AUR ไปก่อน จนกว่าจะมีมาตรการที่พิสูจน์ได้ว่าผู้ใช้รับรู้เรื่องนี้แล้ว
    ตัวอย่างเช่น อาจเปลี่ยน URL ของ AUR API เล็กน้อยเพื่อให้ผู้ใช้ yay/yaourt ต้องไปค้นหาว่าเกิดอะไรขึ้น API ใหม่ควรมีโครงสร้างพื้นฐานสำหรับแจ้งผู้ใช้ และยืนยันว่าได้อ่านข้อความแล้วก่อนดำเนินการ โดยเฉพาะในสถานการณ์ที่ยังไม่แน่ใจด้วยซ้ำว่าหามัลแวร์เจอครบทั้งหมดหรือยัง
    นอกจากนี้ควรมีฐานข้อมูลของ AUR commit ที่ถูกถอนหรือถูกเจาะ และมีกลไกเตือนหากผู้ใช้เคยติดตั้งแพ็กเกจนั้น

    • จะดีหรือร้าย คำเตือนนี้ก็ มีอยู่ตลอดเวลา ใน AUR
      มันอยู่ในชื่อนั้นเอง และในเอกสารวิกิก็อธิบายชัดเจนว่า AUR เป็นคลังของผู้ใช้และไม่ควรเชื่อถือแบบไม่ลืมหูลืมตา
      มันเขียนไว้ตรงกรอบสีแดงใหญ่ด้านบนชัด ๆ: https://wiki.archlinux.org/title/Arch_User_Repository
      มีหลายอย่างใน AUR ที่ฉันจะไม่ติดตั้งเด็ดขาด และฉันก็ไม่คิดว่าการกระจายทุกอย่างออกไปทาง mailing list จะเป็นทางออกที่ดีที่สุด
      ฉันไม่ได้เกลียดไอเดียการเตือนผู้ใช้ที่ติดตั้งแพ็กเกจอันตราย แต่โอกาสที่จะทำได้จริงค่อนข้างต่ำ เพราะ AUR ไม่มีการติดตามการติดตั้งแบบที่เครื่องมือเชิงพาณิชย์มี จะไปรู้ได้อย่างไรว่าใครติดตั้งแพ็กเกจอะไร? โดยพื้นฐานแล้ว AUR คล้ายสมุดรายชื่อที่อยู่ของแพ็กเกจ และไม่ได้บังคับให้ต้องใช้ข้อมูลล็อกอินหรือข้อมูลยืนยันตัวตนด้วยซ้ำ
      เพราะงั้นคำเตือนควรมาจากเครื่องมือที่ผู้ใช้สามารถเรียกใช้ได้เมื่อใส่ใจ และต้องอาศัยให้ผู้ใช้ใส่ใจจริง ๆ เช่น: https://gist.github.com/Kidev/59bf9f5fb53ab5eee99f19a6a2fc39...
    • ไม่ควรทำแบบนั้น แค่เพราะบางคนไม่จริงจังกับ คำแนะนำด้านความปลอดภัย ขั้นพื้นฐาน ก็ไม่ได้แปลว่าควรทำลาย workflow ของทุกคน
      แล้ว API ใหม่ที่ต้องแจ้งผู้ใช้และให้ยืนยันว่าอ่านแล้ว มันจะทำงานยังไงกันแน่? แพ็กเกจ AUR ก็เป็นแค่ git repository และสิ่งที่ AUR helper จะทำหรือไม่ทำก็ไม่ใช่สิ่งที่ผู้ดูแล Arch ควบคุมได้
    • ฉันเห็นด้วยว่าควรมีประกาศบนหน้าแรกของ AUR ส่วนตัวคิดว่าถ้ามีข้อความสั้น ๆ บนหน้าแรกของ Arch พร้อมลิงก์ไปยังประกาศในหน้า AUR ก็น่าจะช่วยได้
      ถ้าไม่อยากไล่รายชื่อแพ็กเกจที่ได้รับผลกระทบทั้งหมด อย่างน้อยก็ควรแนะนำเป็นจุดยืนอย่างเป็นทางการว่าใครก็ตามที่ใช้แพ็กเกจ AUR ต้องอ่านทุกไฟล์ของทุกแพ็กเกจที่ใช้งาน
    • ตอนนี้มีประกาศแล้ว: https://archlinux.org/news/active-aur-malicious-packages-inc...
    • ถ้าเชื่อตัวเลขของ Socket.dev ได้ ผลกระทบก็ดูเหมือนจะค่อนข้างเล็ก โชคดีไป
      ก็สมเหตุสมผลอยู่ ฉันรู้จักบางแพ็กเกจในรายการที่ได้รับผลกระทบ มันเก่ามากแล้วและ upstream project ก็ไม่ได้มีการดูแลต่อแล้ว
      ฉันไม่รู้ว่ามีผู้เสียหายทั้งหมดเท่าไร แต่ทีม AUR มีโอกาสสูงที่จะมีตัวเลขที่แม่นยำ และก็น่าจะพยายามจัดการให้ดีที่สุดตามระดับผลกระทบ

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

  • มีสคริปต์ง่าย ๆ สำหรับสแกนหาแพ็กเกจที่ถูกเจาะ
    https://cscs.pastes.sh/aurvulntest20260611.sh
    ไม่ใช่สคริปต์ของฉัน แต่ก็อ่านและทำความเข้าใจได้ง่าย อย่าเอาสคริปต์ไป pipe เข้า bash ตรง ๆ เด็ดขาด

    • มีทางเลือกที่เร็วกว่าด้วย
      comm -1 -2 <(pacman -Qq | sort) <(curl -s https://gist.githubusercontent.com/quantenProjects/… | sort)
      ไม่มีเวลาไหนที่แย่สำหรับการเรียนรู้ comm(1)
    • อันนี้เช็กแค่ว่าแพ็กเกจถูกติดตั้งหรือไม่ ไม่ได้เช็กว่าเวอร์ชันที่ติดตั้งอยู่เป็นเวอร์ชันที่ติดเชื้อหรือเปล่า
      ถ้าแบบฉันที่ไม่ได้รัน yay -Syu มาสักพัก หลายเดือนเลย ก็น่าจะปลอดภัยสินะ? …ใช่ไหม?
      ให้ตายสิ อย่าทำให้ฉันต้องติดตั้ง Arch ใหม่เลย ครั้งก่อนกินเวลาไปเป็นสัปดาห์
      อัปเดต: archinstall ดีมาก กู้กลับมาได้ในประมาณ 15 นาที
    • ไม่มีอะไรรับประกันได้ว่ารายการนั้นครบถ้วน
      ควรตรวจ PKGBUILD และซอร์สเสมอ โดยทั่วไปแล้ว AUR ไม่ใช่สิ่งที่ควรเชื่อถืออยู่แล้ว อันที่จริงฉันแปลกใจกว่าที่การเจาะลักษณะนี้ไม่ได้เกิดขึ้นเร็วกว่านี้
    • pacman รองรับ date locale ดังนั้นวิธีค้นหา 9 Jun จะใช้ได้เฉพาะกับ locale ภาษาอังกฤษ หรือ locale ที่ใช้รูปแบบคล้ายกันเท่านั้น
      หลังจากฉันแก้ให้เข้ากับ environment ของตัวเอง มันดันไปจับ jd-gui แต่จริง ๆ แล้วฉันติดตั้ง jd-gui-bin ก่อนเกิดการเจาะประมาณสองชั่วโมง ดูเหมือนฉันจะโชคดีเพราะคืนนั้นขี้เกียจรอคอมไพล์จากซอร์สเลยเลือกแพ็กเกจ -bin แทน

  • ชุมชน Arch กำลังออกสคริปต์และเครื่องมือต่าง ๆ มาอย่างรวดเร็ว
    ตอนนี้ยูทิลิตีแบบรวมล่าสุดสำหรับตรวจสอบว่าติดเชื้อหรือไม่คือตัวนี้:
    https://github.com/lenucksi/aur-malware-check
    นอกจากนี้ในเมลลิงลิสต์ aur-request ก็มีคำขอให้ลบและทำให้เป็น orphan เพื่อย้อนกลับคอมมิตอันตรายถูกส่งเข้ามาเป็นจำนวนมาก:
    https://lists.archlinux.org/archives/list/aur-requests@lists...

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

  • จำได้ว่าเมื่อราว 10 ปีก่อนเคยติดตั้ง Mednafen ซึ่งเป็นอีมูเลเตอร์บน Arch Linux โปรแกรมรันไม่ขึ้น เพราะมันลิงก์กับไลบรารีที่ไม่มีอยู่ในระบบของผม
    พอไปดูจึงรู้ว่าเมนเทนเนอร์คอมไพล์ซอฟต์แวร์บนเครื่องของตัวเอง และมีการใช้ไลบรารีที่มีอยู่บนเครื่องนั้น แต่ไม่ได้ระบุไว้ใน dependency
    มันเป็นแพ็กเกจที่ดูแลอย่างเป็นทางการ และผมคิดมาตลอดว่าสิ่งแบบนี้ต้องถูกสร้างบน build server เฉพาะทาง ไม่ใช่คอมไพล์โดยอาสาสมัครคนไหนก็ได้หรือบนคอมพิวเตอร์ที่บ้าน ไม่รู้ว่า Arch ยังสร้างแพ็กเกจแบบนั้นอยู่หรือเปล่า แต่เรื่องนั้นน่ากลัวพอที่จะทำให้ผมเปลี่ยนดิสโทร

    • ต่อให้ใช้ pkgctl build ก็ยังเกิดเรื่องแบบนี้ได้ เป็นกรณีที่ makedepends= ดึง shared library เข้ามาในสภาพแวดล้อมการ build แบบทางอ้อม แต่ depends= กลับไม่ได้ระบุไว้
      ถ้าตรวจพบการพึ่งพา .so จะมีคำเตือน แต่การเห็นแล้วลงมือแก้เป็นหน้าที่ของเมนเทนเนอร์
      ในด้านความปลอดภัยและความมั่นคง Arch Linux เป็นหนึ่งในแกนหลักที่ผลักดันโครงการ reproducible builds และส่วนใหญ่ของระบบปฏิบัติการสามารถตรวจสอบอย่างอิสระได้ว่าไบนารีนั้นถูก build มาจากซอร์สโค้ดจริงหรือไม่ ระบบตรวจสอบแพ็กเกจทางการเข้มแข็งกว่า NixOS และอยู่ในระดับใกล้เคียงกับ Debian:
      https://reproducible.archlinux.org/
      แต่ทั้งหมดนี้ไม่เกี่ยวอะไรกับเหตุการณ์ AUR ครั้งนี้เลย
    • มีเครื่องมือสำหรับจับปัญหาแบบนี้ โดยลอง build และติดตั้งแพ็กเกจจากอิมเมจที่สะอาด เช่น pkgctl
      ถ้าเป็นเมนเทนเนอร์ ก็ควรใช้เครื่องมือแบบนี้ก่อนเผยแพร่เสมอ
    • จนถึงช่วงไม่นานมานี้ วิธีแบบนี้ถือเป็นเรื่องปกติ Debian เองก็ทำแบบนั้นอยู่นาน และเพิ่งสั่งห้ามทั้งหมดในปี 2019

  • แล้วทางแก้ของปัญหานี้คืออะไร? ควรติดตั้งแพ็กเกจพวกนี้ใน Docker container ที่ไม่มีการเข้าถึงเครือข่ายหรือเปล่า? ผมไม่คิดว่าควรสมมติว่าปัญหานี้จำกัดอยู่แค่ AUR
    ในปี 2026 เราควรสงสัยแหล่งที่มาของซอฟต์แวร์ทุกแห่ง โดยเฉพาะเมื่อ vibe coding กำลังแพร่หลาย และซอฟต์แวร์ปิดก็เป็นกล่องดำที่ยิ่งเละเทะกว่าโอเพนซอร์สอีก

    • “แอปสโตร์” ที่ไม่น่าเชื่อถือ ไม่ว่าจะเป็น AUR, Flatpak ฯลฯ ควรอยู่ใน sandbox อย่างน้อยก็ควรมี VM ให้เป็นค่าเริ่มต้นหรือเป็นตัวเลือก
    • ไม่อยากพูด แต่คนของ Qubes OS พูดถูก ทางออกคือแยกแอปไปไว้ใน virtual machine อย่างจริงจัง
      มีใครรู้ไหมว่าถ้าตัดสินใจย้ายไปใช้จริง ๆ อายุแบตเตอรี่จะแย่ลงแค่ไหน?
    • ต้องมี การนำ SLSA มาใช้
    • Flatpak

  • มีข่าวที่เกี่ยวข้องออกมาเพิ่มเติม
    https://www.phoronix.com/news/Arch-Linux-AUR-400-Compromised
    เคยคิดไอเดียว่าจะทำ canary binary ที่เมื่อถูกรันแล้วจะส่งอีเมลหรือแสดงการแจ้งเตือน แล้วตั้งชื่อมันว่า npm
    ณ จุดนี้ การไม่เปลี่ยนชื่อไบนารี npm ถือว่าเสี่ยงมาก