ยกระดับความปลอดภัยของหน่วยความจำสำหรับเว็บฟอนต์

• Skrifa เป็นไลบรารีประมวลผลฟอนต์ตัวใหม่ที่เขียนด้วย Rust พัฒนาขึ้นเพื่อแทนที่ FreeType และทำให้ Chrome ประมวลผลฟอนต์ได้อย่างปลอดภัยยิ่งขึ้น
• ด้วยคุณสมบัติด้านความปลอดภัยของหน่วยความจำของ Rust จึงช่วยลดปัญหาด้านความปลอดภัยและเร่งความเร็วในการปรับปรุงเทคโนโลยีฟอนต์
• การเปลี่ยนจาก FreeType ไปเป็น Skrifa ช่วยยกระดับคุณภาพโค้ดและลดเวลาที่ใช้ในการแก้ไขปัญหาความปลอดภัย

เหตุผลที่ต้องแทนที่ FreeType

• ในสภาพแวดล้อมเว็บ จำเป็นต้องสามารถนำทรัพยากรที่ไม่น่าเชื่อถือจากแหล่งที่มาหลากหลายมาใช้งานได้อย่างปลอดภัย

• Chrome ใช้มาตรการด้านความปลอดภัยหลายอย่างเพื่อให้สามารถใช้เว็บฟอนต์ได้อย่างปลอดภัย

  • Sandboxing: เนื่องจากโค้ดไม่ปลอดภัยและฟอนต์ไม่น่าเชื่อถือ จึงรันภายในสภาพแวดล้อมป้องกันแยกต่างหาก
  • OpenType Sanitizer: ทำความสะอาดและตรวจสอบฟอนต์ก่อนประมวลผล
  • Fuzzing: ทดสอบไลบรารีที่เกี่ยวข้องกับการประมวลผลฟอนต์อย่างกว้างขวาง

• FreeType ถูกใช้เป็นไลบรารีประมวลผลฟอนต์หลักบน Android, ChromeOS และ Linux

  • หากเกิดช่องโหว่ด้านความปลอดภัย ก็มีความเสี่ยงที่จะส่งผลกระทบต่อผู้ใช้จำนวนมาก

ปัญหาด้านความปลอดภัยสำคัญที่เกิดขึ้นใน FreeType

• 1. การใช้ภาษาที่ไม่ปลอดภัย
  • FreeType เขียนด้วยภาษา C จึงอาจเกิดช่องโหว่ด้านความปลอดภัย เช่น ข้อผิดพลาดด้านหน่วยความจำและบัฟเฟอร์โอเวอร์โฟลว์
• 2. ปัญหาเฉพาะของโครงการ
  • การใช้แมโครทำให้ขาด type ขนาดแบบชัดเจน
    • แมโคร(FT_READ_*, FT_PEEK_*) ซ่อน type ขนาดแบบชัดเจน (เช่น int16_t)
  • เกิดบั๊กซ้ำ ๆ ในโค้ดใหม่
    • พบปัญหาระหว่างเพิ่มการรองรับ COLRv1 และ OT-SVG
  • การทดสอบไม่เพียงพอ
    • การสร้างฟอนต์ทดสอบที่ซับซ้อนทำได้ยาก จึงเกิดปัญหาการทดสอบไม่เพียงพอ
• 3. ปัญหาจาก dependency
  • มีปัญหาเกิดซ้ำในไลบรารีอย่าง bzip2, libpng, zlib ที่ FreeType ใช้งาน
• 4. ข้อจำกัดของการ fuzzing
  • ไฟล์ฟอนต์มีโครงสร้างข้อมูลซับซ้อน ทำให้มีปัญหาที่ไม่ถูกค้นพบจากการ fuzzing
    • ฟอนต์ประกอบด้วยกฎที่ซับซ้อนและ state machine
    • การสร้างโครงสร้างที่ถูกต้องทำได้ยาก จึงยากต่อการทำ fuzzing อย่างมีประสิทธิภาพ

การนำ Skrifa มาใช้และกระบวนการปรับใช้ใน Chrome

• Skia ไลบรารีกราฟิกที่ Chrome ใช้งาน ใช้ FreeType สำหรับเมทาดาทาและการเรนเดอร์ฟอนต์
• Chrome สร้างฟอนต์แบ็กเอนด์ใหม่ของ Skia เพื่อแทนที่ FreeType ด้วย Skrifa

ขั้นตอนการนำ Skrifa มาใช้

• Chrome 128 (สิงหาคม 2024):
  • เริ่มทดลองใช้ Skrifa กับฟอร์แมตฟอนต์ที่ใช้น้อยกว่า เช่น คัลเลอร์ฟอนต์ และ CFF2
• Chrome 133 (กุมภาพันธ์ 2025):
  • นำ Skrifa มาใช้เต็มรูปแบบกับการประมวลผลเว็บฟอนต์บน Linux, Android และ ChromeOS
  • บน Windows และ Mac ใช้เป็นตัวประมวลผลสำรองเมื่อระบบไม่รองรับฟอร์แมตฟอนต์นั้น

เสริมความปลอดภัยและประสิทธิภาพ

• 1. ยกระดับความปลอดภัยของหน่วยความจำ
  • Rust รับประกันความปลอดภัยของหน่วยความจำโดยพื้นฐาน
  • อย่างไรก็ตาม มีการใช้ไลบรารี bytemuck เพื่อประสิทธิภาพ
    • ใช้เมื่อจำเป็นต้อง reinterpret ไบต์ผ่านโครงสร้าง type ที่เข้มงวด
    • เมื่อ Rust อัปเดตในอนาคตจนรองรับการแปลงแบบปลอดภัยได้ จะเปลี่ยนไปใช้ความสามารถนั้นแทน
• 2. ปรับปรุงความถูกต้องแม่นยำ
  • Skrifa รับประกันความไม่เปลี่ยนแปลงของโครงสร้างข้อมูล (immutable) ช่วยเพิ่มความอ่านง่ายของโค้ด ความสามารถในการบำรุงรักษา และประสิทธิภาพแบบมัลติเธรด
  • ตรวจสอบคุณภาพโค้ดด้วย unit test ประมาณ 700 รายการ
  • ใช้เครื่องมือ fauntlet เปรียบเทียบผลลัพธ์ของ FreeType และ Skrifa → ตรวจสอบว่าคุณภาพภาพตรงกันหรือไม่
• 3. การทดสอบในวงกว้างและการเสริมความปลอดภัย
  • มีการทำ fuzzing test ตั้งแต่เดือนมิถุนายน 2024 กับ Skrifa และโค้ดส่วนเชื่อมต่อ
    • จนถึงตอนนี้พบบั๊ก 39 รายการ → ไม่ใช่ช่องโหว่ด้านความปลอดภัย (เป็นความผิดพลาดด้านภาพหรือการแครชที่ควบคุมได้)
    • ยืนยันการปรับปรุงคุณภาพโค้ดโดยไม่ลุกลามเป็นปัญหาด้านความปลอดภัย

บทสรุปและแผนในอนาคต

• การนำ Skrifa ที่พัฒนาด้วย Rust มาใช้ ช่วยเสริมความปลอดภัยและยกระดับคุณภาพโค้ด
• เพิ่มผลิตภาพของการพัฒนาและมอบสภาพแวดล้อมฟอนต์ที่ปลอดภัยยิ่งขึ้นให้ผู้ใช้
• มีแผนจะนำ Skrifa ไปใช้กับการประมวลผลฟอนต์ของระบบบน Linux และ ChromeOS ในอนาคต

[iolothebard]

คราวก่อนเป็น zlib คราวนี้เป็น freetype…
พวกรุ่นเก๋าทยอยถูกแทนที่ไปทีละคน… ก็คล้ายกับโลกที่ผู้คนใช้ชีวิตอยู่เหมือนกันนะ

[GN⁺]

ความคิดเห็นจาก Hacker News

• การแก้ปัญหาที่ Google พบด้วยการทำ fuzzing ต้องใช้วิศวกรซอฟต์แวร์อย่างน้อย 0.25 คน

  • ชอบวิธีการวัดงานเพิ่มเติมลักษณะนี้
  • อยากให้มีวิธีใช้คำสั่ง TTF hinting ได้ครบถ้วนแม้จะไม่ได้ใช้ FreeType
  • ดูเหมือนว่า Windows และ macOS จะไม่มีวิธีเปิดใช้ hinting ที่เหมาะสมอีกต่อไปแล้ว
  • FreeType เองก็ตั้งค่า hinting ที่ไม่เหมาะสมเป็นค่าเริ่มต้นมาตั้งแต่เวอร์ชัน 2.7
  • หากสงสัยว่าข้อความที่ทำ hinting อย่างเหมาะสมหน้าตาเป็นอย่างไร สามารถดูภาพหน้าจออ้างอิงได้
  • สงสัยว่า Windows ได้เลิกให้ความสำคัญกับ font hinting ไปแล้วนับตั้งแต่ XP
  • การสเกล UI และการดูภาพแรสเตอร์บนหน้าจอที่มีความละเอียดหลากหลายทำให้เกิดความพร่ามัว

• พลังที่แท้จริงของ Rust คือการเปลี่ยนผ่านไปสู่ความปลอดภัยอย่างค่อยเป็นค่อยไป และความสามารถในการผสานเข้ากับโปรเจ็กต์เดิม

  • สามารถย้ายองค์ประกอบทีละส่วนได้โดยไม่ต้องเขียนใหม่ทั้งระบบครั้งใหญ่

• กำลังเรียนรู้เกี่ยวกับวิธีที่ฟอนต์ถูกเรนเดอร์ตามการจัดเรียงซับพิกเซลของแผงมอนิเตอร์

  • Windows สมมติว่าทุกแผงใช้เลย์เอาต์ RGB และซอฟต์แวร์ ClearType ก็เรนเดอร์ฟอนต์ตามสมมตินั้น
  • บนจอแสดงผลประเภทใหม่จะเกิดอาการขอบสีของข้อความ
  • มีเครื่องมือจากภายนอกอย่าง MacType หรือ Better ClearType Tuner แต่ใช้กับ Chrome หรือ Electron ไม่ได้
  • เมื่อเทคโนโลยีแผงแบบใหม่แพร่หลายขึ้น ก็จำเป็นต้องมีความพยายามในการกำหนดมาตรฐานสำหรับส่งต่อเลย์เอาต์ซับพิกเซลไปยังเลเยอร์กราฟิก
  • เห็นความพยายามบางส่วนจาก Blur Busters แต่ผู้ผลิตยังตระหนักถึงเรื่องนี้ไม่มากพอ

• Skia เป็นไลบรารีขั้นสูงที่ทำเลย์เอาต์ข้อความระดับสูงและแคช glyph

  • Skia เขียนด้วย C++ และสร้างโดย Google
  • FreeType ใช้วัดและเรนเดอร์ glyph และรองรับทั้งโหมด anti-aliasing และ hinting ที่หลากหลาย
  • FreeType เขียนด้วย C และไม่ได้สร้างโดย Google
  • สงสัยว่าทำไม FreeType ถึงถูกนำไปเขียนใหม่ด้วย Rust ก่อน

• ฟอนต์จะถูกประมวลผลผ่าน OpenType Sanitizer ก่อน

  • สงสัยว่าฟอร์แมตฟอนต์แย่ถึงขนาดต้อง sanitize ไฟล์เลยหรือ
  • มีการระบุว่า integer overflow เป็นหนึ่งในสาเหตุของช่องโหว่
  • หลายภาษาไม่ตรวจจับ overflow และสถาปัตยกรรมสมัยใหม่อย่าง RISC-V ก็ไม่ได้มี overflow trap รวมอยู่ด้วย
  • ไม่เข้าใจว่าทำไมภาษาใหม่อย่าง Rust ถึงไม่ใส่ overflow trap มาด้วย