Gpg.fail

 (gpg.fail)
4 คะแนน โดย GN⁺ 2025-12-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เว็บไซต์ที่เปิดเผยช่องโหว่ด้านความปลอดภัยหลายรายการที่เกี่ยวข้องกับ GnuPG พร้อมลิงก์ไปยังหน้าคำอธิบายรายละเอียดของแต่ละช่องโหว่
  • ในเว็บไซต์มีการรวบรวมกรณีปัญหาหลากหลายที่เกิดขึ้นในกระบวนการลายเซ็น PGP, การเข้ารหัส, การตรวจสอบความน่าเชื่อถือ
  • รายการสำคัญประกอบด้วย plaintext attack, path traversal, ข้อผิดพลาดในการคำนวณแฮช, memory corruption, การปลอมแปลงลายเซ็น เป็นต้น
  • ผู้ดูแลระบุว่ากำลังเร่งเขียนเว็บไซต์ใหม่ และจะเผยแพร่ สไลด์·PoC·แพตช์ ในเร็ว ๆ นี้
  • เป็นกรณีที่สะท้อนให้เห็นถึงความจำเป็นในการตรวจสอบอย่างจริงจังต่อความถูกต้องสมบูรณ์ของลายเซ็นและระบบความเชื่อถือของเครื่องมือความปลอดภัยโอเพนซอร์ส

ภาพรวมของเว็บไซต์

  • gpg.fail เป็นเว็บไซต์ที่รวบรวมและเปิดเผยช่องโหว่ของ GnuPG (อิมพลีเมนเทชัน OpenPGP)
    • แต่ละรายการเชื่อมไปยังหน้าวิเคราะห์ทางเทคนิคแบบละเอียดผ่านลิงก์แยก
    • ผู้ดูแลกล่าวว่า “ลืมซอร์สโค้ดของเว็บไซต์ไว้ที่บ้านเลยกำลังเขียนใหม่อยู่ คาดหวังเวอร์ชันที่ดีกว่าได้ในวันพรุ่งนี้”
  • ด้านบนของเว็บไซต์มีข้อความ “Slides, pocs and patches soon!” เพื่อบอกล่วงหน้าว่าจะมีการเผยแพร่ข้อมูลเพิ่มเติมในภายหลัง

รายการช่องโหว่สำคัญที่เปิดเผย

  • Multiple Plaintext Attack on Detached PGP Signatures
    • ชี้ให้เห็นว่าสามารถทำ การโจมตีแบบ multiple plaintext กับลายเซ็น PGP แบบแยกไฟล์ได้
  • GnuPG Accepts Path Separators and Path Traversals in Literal Data "Filename" Field
    • GnuPG ยอมรับตัวคั่นพาธและ path traversal ในฟิลด์ชื่อไฟล์ของ literal data
  • Cleartext Signature Plaintext Truncated for Hash Calculation
    • เกิดปัญหา plaintext ถูกตัดทอนระหว่างการคำนวณแฮช
  • Encrypted message malleability checks are incorrectly enforced causing plaintext recovery attacks
    • การตรวจสอบ malleability ของข้อความเข้ารหัสถูกบังคับใช้อย่างไม่ถูกต้อง ทำให้เกิดการโจมตีเพื่อกู้คืน plaintext ได้
  • Memory Corruption in ASCII-Armor Parsing
    • อาจเกิด memory corruption ระหว่างการพาร์ส ASCII-Armor
  • Trusted comment injection (minisign)
    • มีความเป็นไปได้ของ การฉีด trusted comment ใน minisign
  • Cleartext Signature Forgery in the NotDashEscaped header implementation in GnuPG
    • มีความเป็นไปได้ของ การปลอมแปลงลายเซ็น cleartext ในการอิมพลีเมนต์เฮดเดอร์ NotDashEscaped
  • OpenPGP Cleartext Signature Framework Susceptible to Format Confusion
    • มีความเสี่ยงต่อ format confusion ในเฟรมเวิร์กลายเซ็น cleartext ของ OpenPGP
  • GnuPG Output Fails To Distinguish Signature Verification Success From Message Content
    • มีปัญหาเอาต์พุตที่ ไม่สามารถแยกความแตกต่างระหว่างความสำเร็จของการตรวจสอบลายเซ็นกับเนื้อหาข้อความได้
  • Cleartext Signature Forgery in GnuPG
    • มีความเป็นไปได้ของ การปลอมแปลงลายเซ็น cleartext จากข้อผิดพลาดในการจัดการ NULL byte
  • Radix64 Line-Truncation Enabling Polyglot Attacks
    • การตัดบรรทัดของ Radix64 ทำให้เกิดการโจมตีแบบ polyglot ได้
  • GnuPG may downgrade digest algorithm to SHA1 during key signature checking
    • อัลกอริทึม digest อาจถูกลดระดับเป็น SHA1 ระหว่างการตรวจสอบลายเซ็นคีย์
  • GnuPG Trust Packet Parsing Enables Adding Arbitrary Subkeys
    • การพาร์ส trust packet ทำให้สามารถเพิ่ม subkey ตามอำเภอใจได้
  • Trusted comment Injection (minisign)
    • มีการกล่าวถึง ช่องโหว่การฉีด trusted comment ที่เกี่ยวข้องกับ minisign ซ้ำอีกครั้ง

แผนในอนาคต

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

ความหมาย

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

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

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

 
GN⁺ 2025-12-28
ความเห็นจาก Hacker News
  • หลังการประกาศช่องโหว่ล่าสุดของ GnuPG ความเชื่อมั่นก็เริ่มสั่นคลอน มีการเปิดเผย zero-day ในวิดีโอบรรยายของ CCC และบางรายการถูกทำเครื่องหมายว่า “wontfix” ซึ่งทำให้หลายคนผิดหวัง
    • มีคนพูดว่า “หมดความเชื่อใจใน Werner Koch แล้ว” และก็มีคนถามต่อว่าทำไมถึงคิดเช่นนั้น
    • บางคนถึงกับเรียก GPG ว่าเป็น ความพยายามที่หมดหวัง (lost cause) มาตั้งแต่หลายสิบปีก่อนแล้ว และบอกว่าผู้ใช้ด้านความปลอดภัยที่จริงจังได้ย้ายไปใช้เครื่องมือทางเลือกที่ดีกว่ากันหมดแล้ว
  • มีโพสต์บล็อกของ GnuPG ออกมา แต่ก็มีเสียงตอบรับว่าการยังคงเก็บฟีเจอร์ที่ถูกมองว่า “เป็นอันตราย” มาตลอด 30 ปีไว้นั้นเป็นเรื่องที่ยากจะยอมรับ
    • ผู้ใช้คนหนึ่งแสดงความเสียดายว่า Werner Koch ทุ่มเทให้กับ GPG มาอย่างยาวนาน แต่ตอนนี้กลับเห็นชัดแล้วว่ามี ข้อบกพร่องเชิงโครงสร้างที่แก้ไม่ได้ในระดับรากฐาน
  • ในบรรดาช่องโหว่ที่เกี่ยวข้องกับ GPG บางส่วนเป็นปัญหา “ข้อความที่ไม่น่าเชื่อถือซึ่งมี ANSI escape code ปะปนอยู่” โดยมีความเห็นว่ามันให้ความรู้สึกเหมือน XSS เวอร์ชันบนเทอร์มินัล
  • ยังมีการวิเคราะห์ด้วยว่า โครงสร้างแพ็กเก็ต ของ GPG เองนั้นซับซ้อนเกินไป
    • ข้อความหนึ่งชุดประกอบด้วยแพ็กเก็ตหลายรูปแบบ ทำให้ผู้โจมตีสามารถรบกวน state machine ได้
    • โดยเฉพาะ malleability bug ทำให้เกิดปัญหาการข้ามขั้นตอนตรวจสอบการยืนยันตัวตนจากความผิดพลาดของ state transition
    • มีข้อโต้แย้งว่าโครงสร้างที่ซับซ้อนเช่นนี้ก่อให้เกิด “Weird Machine” และควรถูกออกแบบใหม่เป็นฟอร์แมตไบนารีที่เรียบง่ายและชัดเจน
    • และก็มีคนเห็นว่าคำอธิบายประเด็นนี้ทำได้ยอดเยี่ยมมาก
  • การถกเถียงเรื่องการปฏิบัติตามมาตรฐานของ GPG ก็ยังดำเนินต่อไป
    • บางคนบอกว่า “นี่เป็นปัญหาของ GnuPG เท่านั้น ไม่เกี่ยวกับมาตรฐาน OpenPGP” แต่ก็มีคนแย้งว่าใน implementation หลักของ PGP ตัวอื่น ๆ เช่น Sequoia, minisign, age ก็พบ ช่องโหว่ของ parser เช่นกัน
    • ผู้ใช้อีกคนอธิบายว่าฝั่ง OpenPGP ตอนนี้แยกเป็น LiberePGP (GnuPG) กับ RFC-9580 (Sequoia) โดยแต่ละฝั่งเลือกแนวทางแบบมินิมัลลิสต์กับแม็กซิมัลลิสต์ตามลำดับ และย้ำว่าการหลีกเลี่ยงสงครามมาตรฐานพร้อมรักษาความสามารถทำงานร่วมกันได้เป็นเรื่องสำคัญ
    • บางส่วนยืนยันว่าปัญหา clearsig เป็นข้อบกพร่องของมาตรฐาน OpenPGP เอง
    • ขณะที่อีกคนมองว่าบั๊กของ GPG ท้ายที่สุดแล้วมีต้นตอมาจาก ปัญหาเชิงโครงสร้างของโปรโตคอล PGP และจึงควรนับว่าเป็นบั๊กในระดับโปรโตคอลโดยพฤตินัย
  • ในประเด็นลายเซ็น GPG มีคำถามว่า “ยังปลอดภัยอยู่ไหมหากจะใช้ GPG ต่อไปสำหรับการเซ็น git commit/tag?”
    • ผู้ใช้คนหนึ่งยกตัวอย่าง “ช่องโหว่ bitflip” ของ GPG ว่าเป็นปัญหาร้ายแรงที่เปิดทางให้ผู้โจมตีดัดแปลง plaintext ได้
    • อีกคนชี้ว่า โครงสร้างที่แชร์คีย์เดียวกันระหว่างหลายแอปพลิเคชัน นั้นอันตรายในตัวเอง และเสนอว่าควรแยกคีย์ตามแต่ละแอปจะปลอดภัยกว่า
    • อีกความเห็นหนึ่งมองว่าช่องโหว่รอบนี้ยังไม่ถึงระดับการโจมตีจากระยะไกล และแนะนำให้ ใช้งานอย่างระมัดระวังแทนที่จะตื่นตระหนก
    • มีผู้ใช้แชร์ประสบการณ์ว่าตนเคยใช้ GPG กับ YubiKey ข้ามหลายอุปกรณ์ แต่ภายหลังย้ายไปใช้ 1Password SSH agent แล้วพบว่าทุกอย่างง่ายขึ้นมาก
    • อีกคนเน้นว่าหากจะมาแทนที่ GPG อย่างสมบูรณ์ ก็ต้องแก้ ปัญหาการกระจายคีย์ ให้ได้ เพราะสิ่งที่ยากกว่าการเซ็นคือ วิธีแจกจ่าย public key อย่างน่าเชื่อถือ
  • ยังมีข้อกังวลต่อแนวโน้มใน ecosystem ของ Rust ที่มักเลือกใช้ไลเซนส์ MIT แบบไม่ทันคิด
    • ผู้ใช้คนหนึ่งบอกว่าหลายคนใช้เพราะ “MIT เป็นค่าเริ่มต้น” และเตือนว่าหาก การคุ้มครองแบบ copyleft ของ GPL3 หายไป อำนาจควบคุมของผู้ใช้อาจอ่อนแอลง
    • คนที่เห็นด้วยเสริมว่าเมื่อก่อนตนก็ใช้ MIT แต่ตอนนี้กำลังเปลี่ยนทุกโปรเจกต์ไปเป็น copyleft เต็มรูปแบบ
    • อีกคนวิเคราะห์ว่าปรากฏการณ์นี้ไม่ได้เกิดแค่กับ Rust แต่พบได้ใน ecosystem ของภาษาสมัยใหม่แทบทั้งหมด
      • การที่บริษัทใหญ่สร้างอาณาจักรอยู่บนโค้ดจากอาสาสมัครทำให้หลายคนกลับมามองเห็นคุณค่าของ copyleft อีกครั้ง
      • แต่ในสภาพแวดล้อมที่มีข้อจำกัดทางกฎหมายจนใช้ GPL ไม่ได้ ก็อาจจำเป็นต้องเลือก ไลเซนส์แบบ permissive ด้วยเหตุผลเชิงปฏิบัติ
      • แม้ Mozilla Public License จะน่าจะเป็นทางสายกลางแบบ weak copyleft ได้ แต่ก็มีความเสียดายที่ FSF ไม่ได้ผลักดันมันมากพอ
    • บางคนเสนอว่า “ในยุคที่สิ่งไม่ใช่มนุษย์ (LLM) เรียนรู้จากโค้ดได้ เราจำเป็นต้องมีไลเซนส์แบบใหม่ที่ยึดมนุษย์เป็นศูนย์กลาง”
    • อีกคนมองว่า “ไม่ว่าจะ GPL หรือ MIT สุดท้ายแล้ว การควบคุมการใช้งานก็เป็นเพียงฟีเจอร์หนึ่ง (feature)” และมองตรรกะเรื่องการควบคุมของซอฟต์แวร์เสรีในเชิงฟังก์ชัน
    • ผู้ใช้คนหนึ่งทิ้งความเห็นแบบติดดินว่า “สุดท้ายถ้าอยากให้ซอฟต์แวร์อยู่รอดยาว ๆ ก็ต้อง แก้บั๊ก ก่อน”
  • ก็ยังมีคนที่ใช้งาน GPG อย่างมีประโยชน์อยู่
    • หากใช้ร่วมกับ OpenPGP สมาร์ตการ์ด หรือ YubiKey ก็ถือว่าค่อนข้างเสถียร และตั้งค่าได้ง่ายกว่าโซลูชันฮาร์ดแวร์อื่น
    • และยังมีแผนจะใช้ต่อไปในงานอย่าง แบ็กอัปเข้ารหัส, ตัวจัดการรหัสผ่าน, การจัดการคีย์ SSH มากกว่าการใช้กับอีเมล