ประเด็น xz backdoor ที่เป็นภาพย่อส่วนของปฏิสัมพันธ์ในโปรเจกต์โอเพนซอร์ส

• แม้จะมีบทวิเคราะห์จำนวนมากเกี่ยวกับช่องโหว่ xz/liblzma แต่ส่วนใหญ่มักข้ามขั้นแรกของการโจมตีไป
  • ผู้ดูแลเดิมหมดไฟ และมีเพียงผู้โจมตีเท่านั้นที่เสนอความช่วยเหลือ (ดังนั้นผู้โจมตีจึงสืบทอดความไว้วางใจที่ผู้ดูแลเดิมสั่งสมไว้)
• ในอาร์ไคฟ์เธรดอีเมล มีการบันทึกสถานการณ์ในช่วงเวลาที่ขั้นตอนที่ 0 นี้เกิดขึ้น

ผู้ดูแลหมดไฟและการปรากฏตัวของผู้โจมตี

• มีการยื่นคำขอที่ดูสมเหตุสมผลต่อผู้ดูแล

  • "XZ for Java ยังมีการดูแลอยู่ไหม? ผมโพสต์คำถามไปเมื่อสัปดาห์ก่อนแต่ยังไม่ได้รับคำตอบ"

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

  • "Jia Tan (ผู้โจมตีในครั้งนี้) ได้ช่วยผม และ... อาจมีบทบาทมากขึ้นในอนาคต... ทรัพยากรของผมมีจำกัดมาก จึงชัดเจนว่าในระยะยาวต้องมีบางอย่างเปลี่ยนแปลง"

• ผู้ดูแลกล่าวถึงทรัพยากรที่มีอยู่อย่างจำกัดของตน และบอกว่าในระยะยาวจำเป็นต้องมีบางอย่างเปลี่ยนไป

การปรากฏตัวของผู้ใช้ที่ไม่ให้ความร่วมมือ

• ผู้ใช้ที่ไม่ให้ความร่วมมือกล่าววิจารณ์ผู้ดูแล

  • "คงไม่มีความคืบหน้าจนกว่าจะมีผู้ดูแลคนใหม่ ... ผู้ดูแลปัจจุบันหมดความสนใจหรือไม่ก็ไม่ใส่ใจกับการบำรุงรักษาอีกต่อไปแล้ว เป็นเรื่องน่าเศร้าที่ได้เห็นรีโพซิทอรีแบบนี้"

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

ความต้องการที่เพิ่มขึ้น

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

  • "คุณกำลังเพิกเฉยต่อแพตช์จำนวนมากที่กำลังค่อย ๆ เน่าอยู่ในเมลลิงลิสต์นี้"

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

• ผู้ร้องขอคนนั้นยังเสนอแนวคิดบางอย่าง แต่ไม่ได้เสนอว่าจะช่วยลงมือจริง

  • "จะเป็นอย่างไรถ้าโอนสิทธิ์การดูแล XZ for C เพื่อให้คุณไปโฟกัสกับ XZ for Java ได้มากขึ้น? หรือไม่ก็ยก XZ for Java ให้คนอื่นเพื่อจะได้โฟกัสกับ XZ for C? ถ้าพยายามดูแลทั้งสองอย่าง ทั้งคู่อาจได้รับการดูแลได้ไม่ดี"

• ผู้ดูแลอธิบายว่าการหาผู้ดูแลร่วมคนใหม่หรือการส่งต่อทั้งโปรเจกต์นั้นไม่ใช่เรื่องง่าย

ความเป็นจริงของโปรเจกต์โอเพนซอร์ส

• นักพัฒนาซอฟต์แวร์ไม่ใช่เฟืองที่ถอดเปลี่ยนเข้าออกได้ตามใจ
• เธรดอีเมลจบลงโดยที่ผู้ใช้ที่เอาแต่บ่นยังคงเรียกร้องต่อไปโดยไม่ยื่นมือช่วยอะไรเลย และสุดท้ายมีเพียงผู้โจมตีที่เหลืออยู่

  • "Jia Tan อาจจะรับบทบาทมากขึ้นในโปรเจกต์ต่อจากนี้ เขาช่วยอย่างมากนอกเหนือจากในลิสต์ และในทางปฏิบัติก็เป็นผู้ดูแลร่วมไปแล้ว :-)"

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

[GN⁺]

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

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

• ขั้นแรกของปัญหานี้คือการโจมตีด้วยวิศวกรรมสังคมที่กดดันให้นักพัฒนาโครงการโอเพนซอร์สมอบอำนาจควบคุมรีโพสิตอรีให้ผู้โจมตีมากขึ้น

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

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

• มีคำถามว่าเซิร์ฟเวอร์ SSH ที่ตั้งค่า port knocking ไว้จะปลอดภัยจากแบ็กดอร์นี้หรือไม่ เนื่องจาก RCE จะทำได้ก็ต่อเมื่อเชื่อมต่อกับเซิร์ฟเวอร์ SSH แล้วเท่านั้น จึงดูเหมือนว่าหากพอร์ตถูกซ่อนไว้หลังลำดับการเคาะ TCP/UDP ที่สมเหตุสมผล ก็น่าจะไม่เกิดปัญหา Port knocking ไม่ได้ทดแทนการตั้งค่า SSH ที่เหมาะสม แต่มีประโยชน์ในฐานะชั้นป้องกันเพิ่มเติมที่ช่วยป้องกันล่วงหน้าหรือถ่วงเวลาให้ตอบสนองได้เมื่อมีช่องโหว่ของ SSH ปรากฏขึ้น

• มีลิงก์เกี่ยวกับปัญหาที่เกี่ยวข้องกับแพตช์เฉพาะลินุกซ์ของ OpenSSH หากไม่มีแพตช์นี้ ปัญหาก็คงไม่เกิดขึ้น นี่ไม่ใช่ปัญหาของ OpenSSH แต่เป็นปัญหาของลินุกซ์

• มีความเห็นว่าผู้คนก็ยังจัดการกับ hard dependency และความซับซ้อนอย่างไม่ใส่ใจ แม้หลังเหตุการณ์ left-pad แล้ว OpenSSH เป็นกำแพงโค้ดขนาดมหึมา ระบบที่ซับซ้อนไม่ว่าจะเขียนด้วยภาษาใดก็ยากจะเชื่อถือโดยเนื้อแท้

• ถ้าแฮ็กเกอร์ชาวจีนต้องการทำสิ่งไม่หวังดี ทำไมถึงจะใช้ชื่อ/แฮนด์เดิลแบบจีนล่ะ? การใช้ชื่อภาษาอังกฤษหรือยุโรปน่าจะดีกว่าเพื่อให้ได้รับความไว้วางใจจากผู้ดูแลโอเพนซอร์สมากขึ้น ในทางกลับกัน ถ้าเป็นแฮ็กเกอร์ที่ไม่ใช่ชาวจีนและต้องการทำสิ่งไม่หวังดี การใช้ชื่อแบบจีนกลับมีเหตุผลมากกว่า (จีนคือผู้ร้าย อะไรทำนองนั้น)

• บัญชี Jigar Kumar ดูเหมือนจะเป็นส่วนหนึ่งของการโจมตีแบบวิศวกรรมสังคม และควรถูกมองว่าน่าสงสัยอย่างมาก

• นักพัฒนาซอฟต์แวร์ไม่ใช่ชิ้นส่วนที่ถอดเปลี่ยนแทนกันได้ และมีการคิดถึงการจำกัดสิทธิ์ในการคอมเมนต์หรือมีส่วนร่วมในคอมมูนิตี้ ตัวอย่างเช่น ถ้า GitHub นำ "ด่าน" มาใช้ ด่านแรกอาจเป็นการเพิ่มการทดสอบใน test suite ที่สร้างหมายเลขเวอร์ชันและแฮชของผลลัพธ์การทดสอบ หากเพิ่มหมายเลขนี้ลงในโปรไฟล์ GitHub ก็อาจเชื่อได้ว่าผู้ใช้อย่างน้อยได้ดาวน์โหลดและรัน make test แล้ว ซึ่งแสดงให้เห็นถึงความทุ่มเทในระดับหนึ่ง