ความพยายามในการควบคุมโครงการโอเพ่นซอร์ส คล้ายกับกรณีของแพ็คเกจ xz

OpenSSF (Open Source Security Foundation) สร้างขึ้นภายใต้การอุปถัมภ์ของ Linux Foundation เพื่อปรับปรุงความปลอดภัยของซอฟต์แวร์โอเพ่นซอร์ส เตือนชุมชนเกี่ยวกับการระบุกิจกรรมที่เกี่ยวข้องกับความพยายามในการควบคุมโครงการโอเพ่นซอร์สยอดนิยม ซึ่งชวนให้นึกถึงสไตล์ของมัน การกระทำของผู้โจมตีในกระบวนการเตรียมติดตั้งแบ็คดอร์ในโครงการ xz เช่นเดียวกับการโจมตี xz บุคคลที่น่าสงสัยซึ่งไม่เคยมีส่วนร่วมอย่างลึกซึ้งในการพัฒนามาก่อนพยายามใช้วิธีการวิศวกรรมสังคมเพื่อให้บรรลุเป้าหมาย

ผู้โจมตีได้ติดต่อกับสมาชิกของสภาปกครองของมูลนิธิ OpenJS ซึ่งทำหน้าที่เป็นแพลตฟอร์มที่เป็นกลางสำหรับการพัฒนาโครงการ JavaScript แบบเปิดร่วมกัน เช่น Node.js, jQuery, Appium, Dojo, PEP, Mocha และ webpack จดหมายดังกล่าวซึ่งรวมถึงนักพัฒนาบุคคลที่สามหลายรายที่มีประวัติการพัฒนาโอเพ่นซอร์สที่น่าสงสัย พยายามโน้มน้าวฝ่ายบริหารถึงความจำเป็นในการอัปเดตหนึ่งในโครงการ JavaScript ยอดนิยมที่ดูแลโดยองค์กร OpenJS

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

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

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

ที่มา: opennet.ru

เพิ่มความคิดเห็น