swath vulnerability

เมื่ออาทิตย์ที่แล้ว มีรายงาน Debian #698189 ว่า swath มีช่องโหว่ด้านการรักษาความปลอดภัย คือสามารถเกิด buffer overflow และนำไปสู่การ execute คำสั่งด้วยสิทธิ์ของผู้ใช้ได้

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

1. แก้บั๊กที่ upstream SVN (rev 238)
2. backport แพตช์มาที่รุ่นใน Sid โดยต้องปรับแพตช์เล็กน้อย แล้วอัปโหลดเป็นรุ่น 0.4.3-3
3. request ขอ unblock 0.4.3-3 เพื่อให้แพกเกจได้ย้ายเข้า Wheezy ที่กำลัง freeze อยู่
4. backport แพตช์มาที่รุ่นใน Squeeze โดยต้องปรับแพตช์อีกครั้ง เตรียมแพกเกจรุ่น 0.4.0-4+squeeze1 เอาไว้ แล้วติดต่อ security team ของ Debian เพื่อขออัปโหลดเข้า security.debian.org แต่ปรากฏว่าทีม security เห็นว่าเป็นช่องโหว่ไม่ร้ายแรง สามารถรอได้ จึงบอกให้ผมอัปโหลดเข้า stable-proposed-updates แทน อย่างไรก็ดี ทีม security ได้สร้าง security tracker แบบไม่มีเลขอ้างอิง DSA ให้เพื่อติดตามการแก้ปัญหา
5. build package ใหม่อีกครั้งโดยเปลี่ยนเป้าหมายจาก stable-security เป็น stable แล้ว request ขอ upload เข้า stable พอได้รับอนุญาตแล้วจึงอัปโหลด จากนั้นก็รอ Debian ออกรุ่น stable update ครั้งต่อไป

ไม่ใช่เรื่องเล่น ๆ เลยนะนี่ กับบั๊กเล็ก ๆ อย่างนี้ กับโค้ดที่เขียนโดยไม่ระวัง ดังนั้น ต่อไปนี้คงต้องพยายามมากขึ้นที่จะทำความสะอาดโค้ดของ swath

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

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% นะครับ เพียงแต่ชี้ว่า การพบจุดโหว่ทำให้ซอฟต์แวร์ปลอดภัยได้อย่างไร

OpenSSL Weak Key

ไม่ได้ blog เสียนานด้วยเหตุผลหลาย ๆ อย่าง การสลับงานไปมาหลาย ๆ อย่างก็ส่วนหนึ่ง กิจกรรมของครอบครัวก็อีกส่วนหนึ่ง ขี้เกียจเขียนก็อีกส่วนหนึ่ง เอิ๊ก

ได้ข่าว DSA 1571-1 จากนิวตรอนเมื่อวันก่อน เล่นเอาวุ่น เมื่อมีการพบความหละหลวมของกุญแจที่สร้างโดย openssl ของ Debian/Ubuntu ตั้งแต่รุ่น 0.9.8c-1 เป็นต้นมา โดยเป็นแพตช์เฉพาะของ Debian มีผลตั้งแต่ etch เป็นต้นมา

ก่อนหน้านั้นไม่กี่ชั่วโมง ก็ได้รับแจ้งจาก alioth admin ว่าจะลบ SSH public key ทั้งหมดออกจากเซิร์ฟเวอร์ เพราะปัญหานี้

อีกไม่กี่ชั่วโมงถัดมา บล็อกโนเนะก็ ออกข่าว นี้เหมือนกัน

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

อาการของปัญหาคือ กุญแจที่สร้างจาก openssl รุ่นที่มีปัญหา มีความเป็นไปได้ในการสุ่มเพียง 32767 หรือ 2^15 แบบ ซึ่งอยู่ในวิสัยของการโจมตีแบบ brute force ได้ ดังนั้น ระบบใด ๆ ก็ตาม ที่ผู้ใช้เอากุญแจสาธารณะ SSH ดังกล่าวไปติดตั้งไว้ ก็มีสิทธิ์ถูกเจาะระบบในลักษณะการเดารหัสผ่านได้

ดังนั้น อย่างที่ Erich Schubert (DD คนหนึ่ง) ได้ blog ไว้ ปัญหานี้จึงไม่ได้กระทบแค่ผู้ใช้ Debian/Ubuntu เท่านั้น แต่ระบบ Linux, FreeBSD หรือ Unix ใด ๆ ที่ผู้ใช้ Debian/Ubuntu มีบัญชีอยู่ และเอากุญแจสาธารณะไปติดตั้งไว้ ก็มีสิทธิ์ถูกเจาะได้ทั้งนั้น จึงขอฝากเตือน admin ทั่วไปที่ไม่ได้ใช้ Debian/Ubuntu ด้วย ว่าอย่านิ่งนอนใจ

ล่าสุด Debian ได้ออกแพกเกจ openssh-blacklist เพื่อปิดกั้นการเข้าระบบผ่านกุญแจที่หละหลวมทั้งหมดแล้ว เป็นมาตรการอีกขั้นหนึ่ง ที่ distro อื่นสามารถใช้ช่วยแก้ปัญหาได้ แต่สำหรับผู้ใช้ Debian/Ubuntu คุณควรเปลี่ยนกุญแจก่อนที่จะอัปเกรด openssh (คืออัปเกรดแค่ openssl/libssl เพื่อสร้างกุญแจใหม่ก่อน แล้วเปลี่ยนกุญแจให้เรียบร้อย แล้วค่อยอัปเกรด openssh เพราะไม่งั้น กุญแจของคุณจะโดน blacklist ก่อนจะทันได้เปลี่ยน)

สำหรับรายละเอียดของปัญหา Daniel Leidert ซึ่งเป็น DD คนหนึ่ง เขียนอธิบาย ไว้ค่อนข้างดี คือผู้ดูแลแพกเกจ openssl ได้พยายามแก้ปัญหาการใช้ uninitialized memory ใน openssl ตามที่ตรวจพบโดย valgrind โดยไม่รู้ตัวว่า ได้ตัดแหล่งข้อมูลสุ่มสำคัญของ openssl ไป คือในการสุ่มกุญแจ openssl จะใช้ข้อมูลสุ่มจากหลาย ๆ แหล่ง เพื่อเพิ่ม entropy โดยแหล่งหนึ่งที่ใช้ คือบัฟเฟอร์หน่วยความจำที่ไม่มีการกำหนดค่า (uninitialized memory) นี้เอง พอถูกตัดออกไป ก็เหลือข้อมูลสุ่มอื่นอยู่บ้าง แต่อัตราการสุ่มได้ต่ำลงจนอยู่ในวิสัยที่จะเจาะแบบ brute force ได้ (คนที่พบบั๊กนี้คือ Luciano Bello)

อ่านแล้วก็สงสัยเหมือนกัน ว่ามีการใช้วิธีนี้ในโปรแกรมด้วย.. จำได้ว่าตอนสร้างกุญแจ gpg จะต้องเก็บข้อมูลจาก event ต่าง ๆ ด้วย เช่น ให้ขยับเมาส์มั่ว ๆ หรือสลับหน้าต่าง/หน้าจอไปมา ทำไม openssl ไม่ใช้วิธีนั้นบ้าง?

ว่าแต่ว่า คุณได้ตรวจสอบหรือยัง ว่าคุณโดนปัญหานี้ด้วยหรือเปล่า?