LibThai Security Update

ผ่านไปเรียบร้อย กับ LibThai 0.1.13 ซึ่งเป็น security update โดยแก้ปัญหา integer/heap overflow vulnerability (CVE-2009-4012, DSA-1971)

ปัญหานี้ Tim Starling ได้รายงานทางเมลส่วนตัวมาที่ผมตั้งแต่ช่วงปีใหม่ แต่กว่าจะได้เริ่มลงมือแก้ก็ผ่านไปเกือบอาทิตย์ เนื่องจากต้องไปเฝ้าไข้พ่อที่ รพ. อยู่ หลังจากที่ได้แพตช์แล้ว ก็ส่งแพตช์กลับไปให้เขาช่วยตรวจทานอีกรอบเพื่อความแน่ใจ เสร็จแล้วก็เริ่มติดต่อทีม Debian Security เพื่อขอ update ใน stable และ oldstable

ทีม security ก็ได้กำหนดหมายเลข CVE สำหรับใช้อ้างอิง พร้อมกับนัดหมาย embargo date มาให้ ในระหว่างนั้น ผมจะแพร่งพรายปัญหานี้ออกไปไม่ได้ แม้แต่ commit public VCS ก็ห้าม (แต่ผมก็พลาด โดยได้ commit SVN ไปตั้งแต่ก่อนติดต่อเขาแล้ว ซึ่งเป็นสิ่งไม่สมควร) เพื่อให้เวลาในการแก้ปัญหานี้ร่วมกับ distro ต่าง ๆ ที่ ship libthai ก่อนที่จะประกาศ release พร้อมกัน ทั้งนี้เพื่อความป้องกันการ exploit ที่จะเกิดขึ้นก่อนที่ผู้ใช้จะมีโอกาสได้ update นั่นเอง

เดิมทีนั้น ผมขอ update แค่ stable (lenny) เพราะแพกเกจใน oldstable (etch) นั้น เป็นโค้ดเก่าตั้งแต่ก่อนรื้อเขียนใหม่มาใช้ libdatrie แต่ทีม security บอกว่าต้อง update oldstable ด้วย เนื่องจาก Debian มีภาระผูกพันที่จะ maintain oldstable เป็นเวลาหนึ่งปีนับจาก stable ออก ก็เป็นอันว่าผมต้องทำงานทั้งหมด 3 ครั้ง ครั้งแรกแก้ที่ upstream trunk, ครั้งที่สอง backport มา lenny และครั้งที่สาม แก้โค้ดเก่าใน etch (ซึ่งครั้งหลังสุดนี้ใช้เวลานานหน่อย เนื่องจากเป็นโค้ดที่โละทิ้งไปแล้ว แถมไม่ใช่โค้ดของผมเองด้วย) แล้วก็ยังมีครั้งท้ายสุดจริง ๆ คือปล่อย upstream release และ upload ขึ้น unstable

ครั้งนี้ ทำให้ได้ประสบการณ์ใหม่:

• ได้เรียนรู้ระบบการจัดการ security bug ในโครงการซอฟต์แวร์ มีคน blog สรุปเอาไว้ดีพอสมควรครับ กล่าวคือ:
  • ถ้าคุณพบบั๊กที่เกี่ยวกับ security ที่ยังไม่เป็นที่ทราบกันในสาธารณะ คุณควรรายงานผ่านช่องทางพิเศษที่ไม่เปิดเผย (ขึ้นอยู่กับแต่ละโครงการจะกำหนด หรืออาจจะเป็นเมลส่วนตัว) เพื่อให้โอกาสผู้ดูแลได้แก้ปัญหาก่อนที่จะเกิด exploit กับผู้ใช้ เรียกว่าเป็น responsible disclosure (การเปิดเผยข้อมูลอย่างรับผิดชอบ)
  • การปิดบังปัญหานี้ เป็นแค่การปิดบัง ชั่วคราว ในระหว่างแก้ปัญหา เพื่อปกป้องผู้ใช้เท่านั้น ไม่ได้เข้าข่าย security through obscurity แต่อย่างใด หลังจากแก้ปัญหาเรียบร้อย ทุกอย่างก็จะเปิดเผยผ่าน security alert ซึ่งผู้ใช้จะอุดรูรั่วได้ทันท่วงทีก่อนที่จะมี exploit
  • ถ้าบั๊กนั้นเป็นที่ทราบกันในสาธารณะแล้ว ก็ควรมุ่งหาวิธีแก้ทันทีแทน
  • ถ้าบั๊กนั้นมีผลร้ายแรง ก็จะมีการกำหนด embargo date สำหรับปล่อย fix สู่สาธารณะพร้อม ๆ กัน โดยก่อนหน้านั้น ไม่ควรแพร่งพรายปัญหาสู่สาธารณะ
• social network ต่าง ๆ เช่น twitter, facebook, identi.ca กลายเป็นสิ่งยั่วยวนอย่างมากก่อน embargo date โดยเฉพาะถ้าคุณติดนิสัย tweet ทุกอย่างที่ทำ ควรมีสติเสมอ ถ้าคันปากนักก็หันไปหาสิ่งอื่นที่น่าสนใจ tweet แทน
• เห็นประโยชน์ของ distributed VCS (เช่น git, bzr, hg) ขึ้นมาทันที เพราะก่อน embargo date นั้น คุณไม่ควร commit โค้ดสู่ public VCS อันจะเป็นการแพร่งพรายปัญหาได้ ถ้าใช้ centralized VCS ก็อาจลำบากหน่อย คือต้อง maintain security patch ต่าง ๆ เอาไว้ในระหว่างที่ commit เรื่องอื่น แต่ถ้าใช้ distributed VCS ล่ะก็ แตก branch หรือ commit แบบ local แล้วไปทำงานส่วนอื่นต่อได้ตามสบาย ขอแค่อย่า push security commit เป็นพอ

ที่สำคัญคือ ผมได้เห็นภาพด้วยตนเองล่ะครับ ว่าซอฟต์แวร์โอเพนซอร์สนั้น มีแง่มุมที่ปลอดภัยอย่างไร ในขณะที่การเปิดซอร์ส libthai ของผม อาจเปิดโอกาสให้ cracker พบจุดโหว่ได้สะดวกขึ้น แต่ในขณะเดียวกัน ก็เป็นการเปิดโอกาสให้ผู้เชี่ยวชาญมาตรวจสอบซอร์สของผม แล้วรายงานให้ทราบเพื่อแก้ไขอย่างปลอดภัยได้เช่นกัน ซึ่งการอุดจุดโหว่นี้ ย่อมทำให้ซอฟต์แวร์ปลอดภัยกว่าไม่ได้อุดแน่นอน แม้ว่าจุดโหว่ที่ไม่ได้อุดนั้นจะซ่อนอยู่ภายใต้ security through obscurity ก็ตาม เพราะมันไม่ได้รับประกันความปลอดภัยจากการตรวจพบด้วยเครื่องมือต่าง ๆ ของพวก cracker เลย

แต่นี่ไม่ได้อ้างว่าซอฟต์แวร์โอเพนซอร์สจะปลอดภัยกว่า 100% นะครับ เพียงแต่ชี้ว่า การพบจุดโหว่ทำให้ซอฟต์แวร์ปลอดภัยได้อย่างไร