อธิบายเรื่อง heartbleed

1. ใน SSL/TLS ใหม่ๆ มีฟีเจอร์ heartbeat สำหรับ maintain session เพื่อลด cost ในการ reestablish secure connection

2. heartbeat ใช้วิธี request / response

3. request ที่ส่งส่วนนึงคือ data, byte length ของ data / response ส่วนนึงคือ data และ byte length ของ data ที่ได้รับ

4. ปัญหาคือ openssl implement heartbeat โดยไม่มีการตรวจสอบ byte length ว่าสัมพันธ์กับ data (/me .. ชิบหายแล้ว !) เวลาสร้าง response openssl จะเอาค่า byte length ที่ได้รับมาใช้ดื้อๆ

5. จาก 4 เราสามารถสร้าง request ขนาด 1 byte โดยระบุ byte length ว่ายาว 64 kB ก็ได้ และ openssl ก็จะเชื่อว่าเป็น 64kB “และ” จะสร้าง response กลับโดยอนุมานว่า data มีขนาด 64kB

6. สมมติว่า openssl ได้ request ตามข้อ 5 openssl จะ buffer data 1 byte ใน request ไว้ใน memory และจำว่ามันยาว 64 kB

7. เมื่อ openssl สร้าง response ก็จะนำข้อมูลใน buffer มาใช้ แต่เนื่องจากมันเชื่อว่าข้อมูลยาว 64 kB มันเลยสำเนาข้อมูลออกมาจาก buffer 64 kB เพื่อสร้าง response .. แปลว่ามันสำเนา (access) ข้อมูลเกินจากที่ควรจะเป็น ทำให้คนที่ request ขโมยข้อมูลจาก memory ของ openssl ได้

8. ข้อมูลใน memory อาจจะมี session key / private keys / sensitive info ที่ buffer ไว้สำหรับ ciphers ที่กำลังทำงานขณะนั้น

9. ถ้าได้ private key ข้อมูลที่วิ่งผ่าน SSL/TLS ก็จะสามารถถอดรหัสได้โดยง่าย รหัสผ่าน / ข้อมูลที่เคยหวังว่า SSL/TLS จะปกป้องได้ก็จะรั่วได้หมด ทุก services ที่พึ่งพา openssl จะเสมือนเป็น plaintext protocol

10. 60-70% ของ SSL/TLS ที่ใช้บนโลกนี้ ใช้ openssl รวมถึง internet banking บางเจ้า / cloud console แทบทุกเจ้า แต่ openssl ที่เป็นปัญหาอยู่ในรุ่น 1.0.1 ถึง 1.0.1f เก่ากว่านี้รอด ใหม่กว่านี้ก็รอด

11. ทางแก้ปัญหา อย่างน้อย ต้อง patch / upgrade เป็น openssl ใหม่ + เปลี่ยน certificate ใหม่ทั้งหมดทุก services ที่พึ่ง openssl เพราะ private keys อาจจะรั่วไปแล้ว / เปลี่ยนรหัสผ่านทุก users ที่ใช้บริการผ่าน services เพราะมันอาจถูกถอดรหัสไปได้หมด

12. provider ที่ users เยอะๆ ถึงเต้นกันใหญ่ ทั้ง facebook, google, amazon, … ถ้าคิดว่ามันเรื่องเล็ก ไม่ใช่เรื่องเร่งด่วน ไม่ควรเป็น admin