เรื่องราวที่สะดุดเข้ากับช่องโหว่คีย์อ่อนแอของ Debian

 (hezmatt.org)
2 คะแนน โดย GN⁺ 2024-04-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

เรื่องเล่าตอนที่เผลอไปเจอช่องโหว่คีย์อ่อนแอของ Debian

  • ในเดือนมีนาคม 2008 ผู้เขียนทำงานอยู่ที่ Engine Yard (EY)
  • ในเวลานั้น EY กำลังช่วย GitHub โดยให้โครงสร้างพื้นฐานใช้งานฟรี
  • เมื่อ GitHub เติบโตขึ้น ก็เกิดปัญหาเวลาในการล็อกอินผ่าน SSH ช้าลง
  • GitHub จัดการคีย์ SSH ด้วยวิธีมาตรฐานโดยใช้ไฟล์ ~/.ssh/authorized_keys
  • เมื่อผู้ใช้เชื่อมต่อ SSH จะเปิดไฟล์นี้แล้วค้นหาแบบเชิงเส้นเพื่อหาคีย์ที่ตรงกับคีย์ที่ผู้ใช้นำเสนอ
  • โดยปกติมีคีย์เพียงไม่กี่รายการจึงไม่เป็นปัญหา แต่เมื่อมีผู้ใช้จำนวนมากแบบ GitHub ก็จะช้าลง

ตัดสินใจใช้ฐานข้อมูล MySQL แทนไฟล์ authorized_keys

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

เกิดเรื่องแปลกขึ้น

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

การหาสาเหตุ

  • เมื่อมีการเปิดเผย DSA-1571-1 ในวันที่ 13 พฤษภาคม 2008 ทุกอย่างก็ชัดเจน
  • ผู้ดูแลแพ็กเกจของ Debian ทำพลาดระหว่างจัดระเบียบโค้ดสร้างเลขสุ่มของ OpenSSL จนทำให้จำนวนคีย์ที่เป็นไปได้ลดลงเหลือราว 32,000 คีย์
  • ผู้คนจำนวนมากสมัคร GitHub และสร้างคีย์ใหม่ตามแนวปฏิบัติที่ดี จึงทำให้เกิดการชนกันของคีย์
  • หลังจากนั้น ผู้เขียนก็เข้าไปเกี่ยวข้องกับปัญหานี้มากขึ้น เช่น การใช้คีย์อ่อนแอที่ทราบกันแล้วเพื่อตรวจหาหน่วยงานออกใบรับรองที่มีปัญหา

ความเห็นของ GN⁺

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

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

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

 
GN⁺ 2024-04-10
ความคิดเห็นจาก Hacker News
  • Luciano Bello ค้นพบช่องโหว่ CVE-2008-0166 โดยบังเอิญ แต่ตามบันทึก IRC ในเวลานั้น ต้องใช้จำนวนเฉพาะหลายตัว และไม่ได้ได้ตัวเลขเดิมทุกครั้ง
  • ดูเหมือนว่าในภาพรวมทั้งอุตสาหกรรมจะโชคดีมาก เพราะมีคนที่มีทักษะ เวลา และพลังงาน ซึ่งสามารถสร้างความแตกต่างครั้งใหญ่ได้อย่างทันท่วงที นี่เป็นช่วงที่ทำให้รู้สึกได้จริงถึงสถิติของ "หลายตาช่วยกันมอง" และ "แสงแดดคือยาฆ่าเชื้อ" ไม่ว่าความน่าจะเป็นที่ใครสักคนจะพบบั๊กโดยบังเอิญจะต่ำแค่ไหน ผู้คนก็ยังค้นพบมันได้เพราะพวกเขาทำได้ ตรงกันข้าม ในโค้ดกรรมสิทธิ์/ปิด ความน่าจะเป็นนั้นคือ 0
  • การเปลี่ยนแปลงที่ก่อให้เกิดช่องโหว่นี้ไม่ได้เกิดขึ้นอย่างเร่งรีบ ผู้ดูแลได้ยกประเด็นปัญหาขึ้นในเมลลิงลิสต์ของ OpenSSL ขอความคิดเห็น และเสนอวิธีแก้ไข โดยได้รับข้อเสนอแนะบางส่วนรวมถึงจาก upstream ด้วย ผลลัพธ์คือช่องโหว่ที่เลวร้ายมาก แต่ดูเป็นกรณีที่โชคร้ายอย่างยิ่งที่ทุกคนต่างมองไม่เห็นปัญหา
  • GitHub สรุปว่าทางเลือกที่ดีที่สุดคือแพตช์ OpenSSH เพื่อให้ดึงคีย์ที่จัดทำดัชนีด้วยลายนิ้วมือคีย์จากฐานข้อมูล MySQL ซึ่งดูเหมือนว่าเลือกแทน SQLite เพราะเป็นสถานการณ์ที่ MySQL สามารถแสดงศักยภาพได้จริง เมื่อพวกเขาพยายามเพิ่มความเร็วการเข้าถึง ~/.ssh/authorized_keys
  • เรื่องนี้ทำให้นึกถึงความเป็นไปได้และผลกระทบ หากสิ่งแบบนี้เกิดขึ้นกับฟังก์ชันสร้าง seed ของฮาร์ดแวร์วอลเล็ตบิตคอยน์ยอดนิยม
  • เหตุการณ์การตรวจจับคีย์ RSA ที่มีตัวประกอบร่วม p หรือ q ด้วยการใช้ GCD ก็น่าสนใจเช่นกัน
  • จะเห็นได้ว่าเวลาในการล็อกอิน SSH ที่ช้า เป็นเบาะแสที่คุ้มค่าจะลองดึงต่อไม่ว่าจะด้วยเหตุผลใดก็ตาม
  • OpenSSL RNG ถูก seed ด้วยหน่วยความจำสแตกที่ยังไม่ได้ initialize และ PID ซึ่งดูเหมือนว่าแม้ไม่มีแพตช์ของ Debian การ seed ด้วย PID เพียงอย่างเดียวก็ถือว่าเสี่ยงมากอยู่แล้ว
  • สงสัยว่า GitHub ยังรัน OpenSSH เวอร์ชันที่แพตช์อยู่หรือไม่
  • ประโยคที่บอกว่า Ezra Zygmuntowicz แนะนำ GitHub ให้ผู้เขียนรู้จัก และให้เวลาเขาไปขุดปัญหาร่วมกับทีม GitHub นั้นชวนขำ อาจเป็นเพราะอ่านแล้วเหมือนทีม GitHub เองกำลังมีปัญหาใหญ่
  • ถ้า Luciano ไม่ได้ค้นพบมัน ก็สงสัยว่าจะถูกค้นพบช้ากว่านั้นอีกนานแค่ไหน คิดว่าน่าจะมีเพียงไม่กี่แห่ง เช่น GitHub หรือผู้ให้บริการคลาวด์รายใหญ่ ที่เก็บคีย์จากผู้ใช้นับพัน จึงจะมีโอกาสเจอมันโดยบังเอิญ