Chrome vá lỗi tràn bộ đệm heap WebP

 (chromereleases.googleblog.com)
1 điểm bởi GN⁺ 2023-09-13 | 1 bình luận | Chia sẻ qua WhatsApp
  • Bản cập nhật cho các kênh Chrome Stable và Extended Stable trên máy tính để bàn đã được phát hành, bao gồm bản vá cho lỗ hổng tràn bộ đệm heap WebP
  • Bản build mới là 116.0.5845.187 trên Mac và Linux, 116.0.5845.187/.188 trên Windows, và sẽ được triển khai dần trong vài ngày đến vài tuần
  • Bản phát hành lần này có 1 bản vá bảo mật, trong đó CVE-2023-4863 được phân loại ở mức Critical
  • Apple SEAR và The Citizen Lab thuộc University of Toronto Munk School đã báo cáo lỗ hổng này vào ngày 6/9/2023
  • Google cho biết có trường hợp khai thác thực tế, và quyền truy cập vào chi tiết lỗi có thể bị hạn chế cho đến khi phiên bản vá được áp dụng

Cập nhật kênh Chrome cho máy tính để bàn

  • Các kênh Stable và Extended Stable đã được cập nhật lên bản build mới dành cho máy tính để bàn
  • Phiên bản kênh Stable theo từng nền tảng như sau
    • Mac: 116.0.5845.187
    • Linux: 116.0.5845.187
    • Windows: 116.0.5845.187/.188
  • Kênh Extended Stable cũng được phát hành với phiên bản riêng
    • Windows: 116.0.5845.188
    • Mac: 116.0.5845.187
  • Bản cập nhật được triển khai dần trong vài ngày đến vài tuần
  • Có thể xem danh sách thay đổi đầy đủ của bản build này trong log

Bản vá bảo mật: CVE-2023-4863

  • Bản phát hành lần này bao gồm 1 bản vá bảo mật
  • Bản vá chính do nhà nghiên cứu bên ngoài đóng góp là lỗ hổng sau
    • Critical CVE-2023-4863: tràn bộ đệm heap trong WebP
    • Mã lỗi: 1479274
    • Người báo cáo: Apple Security Engineering and Architecture(SEAR), The Citizen Lab thuộc University of Toronto Munk School
    • Ngày báo cáo: 6/9/2023
    • Mức thưởng: $NA

Khai thác thực tế và hạn chế công bố thông tin

  • Google cho biết exploit CVE-2023-4863 tồn tại trong môi trường thực tế
  • Quyền truy cập vào chi tiết lỗi và các liên kết có thể bị hạn chế cho đến khi phần lớn người dùng cập nhật lên phiên bản đã vá
  • Hạn chế cũng có thể được duy trì nếu cùng lỗi nằm trong một thư viện bên thứ ba mà các dự án khác cũng phụ thuộc vào và chưa được vá

Phát hiện lỗi bảo mật và kênh báo cáo

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-09-13
Các ý kiến trên Hacker News

  • Trong Google Chrome, ảnh WebP được giải mã trong tiến trình renderer, nên ngay cả khi khai thác thành công thì cũng chỉ có thể thực thi mã renderer bên trong sandbox
    Renderer rất phức tạp nên mỗi năm có nhiều exploit được phát hiện, nhưng ngay cả khi giành được quyền thực thi mã trong renderer thì cũng không vượt quá đáng kể các quyền mà một trang web thông thường có
    Đặc biệt, không thể xem hay để lại tệp trong hệ thống tệp cục bộ, và cũng không thể đọc cookie của các tên miền khác

    • Tất nhiên, nếu có exploit thoát sandbox để kết hợp với nó thì câu chuyện sẽ khác
      Không phải là ưu tiên số một ngay lập tức, nhưng nếu chưa có exploit như vậy đang lưu hành ngoài thực tế, thì nên vá sớm nhất có thể vào một thời điểm không quá bất tiện
    • Internet hiện đại có vô số hình ảnh do người dùng tải lên, nên chỉ riêng việc có được quyền trong ngữ cảnh người dùng của một website cũng đã đủ lớn rồi
      Nó gần giống một dạng XSS tăng cường, ở chỗ không bị ràng buộc vào một site hay frontend duy nhất
    • Tôi đang dùng WebP lossless và nó hiệu quả hơn PNG rất nhiều
      À, tôi đã bình luận nhầm luồng; định trả lời câu “jpeg is good enough” ở https://news.ycombinator.com/item?id=37479576
    • Ý là renderer không thể gửi thông tin ngược lại cho website sao?
      Và chẳng phải ngay cả khi đã tắt JavaScript, đột nhiên website vẫn có thể thực thi mã hay sao?

  • Vì vậy tôi càng đồng cảm hơn với việc các nhà phát triển trình duyệt chậm chạp trong việc đưa vào định dạng mới
    WebP không có lợi thế lớn so với JPEG, chủ yếu chỉ là độ trong suốt, mà mức độ thành công cũng hạn chế
    Thế mà giờ nó đã dẫn đến nhiều lỗ hổng bảo mật ưu tiên cao, và mọi nơi liên kết với libwebp sẽ phải phát hành bản vá trong suốt tháng tới
    Không phải là nói đừng làm cái mới, nhưng tôi nghĩ các nhà phát triển có xu hướng đánh giá thấp chi phí khá nhiều

    • Firefox có một lớp sandbox bổ sung có thể áp dụng cho từng thư viện riêng lẻ, thay vì toàn bộ tiến trình: https://hacks.mozilla.org/2021/12/webassembly-and-back-again...
    • Công bằng mà nói, trước đây các vấn đề trong thư viện giải mã JPEG cũng từng được dùng làm đường dẫn phát tán mã độc
      Đúng là hệ sinh thái WebP kém trưởng thành hơn nhiều, nhưng tôi chắc chắn rằng mã xử lý các định dạng cũ hơn cũng từng có khá nhiều vấn đề bảo mật
      Dù vậy lập luận này vẫn hợp lý. Chỉ vài tuần trước, cộng đồng mạng còn có tâm lý cho rằng cần triển khai JPEG XL càng nhanh càng tốt, và để làm vậy thì nhà phát triển trình duyệt “chỉ cần đưa mã decoder tham chiếu vào codebase” với “chi phí gần như bằng không”
    • Nếu trình duyệt không chấp nhận định dạng mới, liệu lỗi như thế này có được phát hiện không?
      Các định dạng ảnh và thư viện khác rất có thể cũng đầy lỗi, nhưng vì không được dùng trong phần mềm lớn nên chẳng ai quan tâm
      Đặc biệt là với những người có khả năng tìm và khai thác các lỗi như thế này, phần thưởng so với thời gian bỏ ra là không tốt
      Không phải cứ lâu không dùng thì lỗi sẽ ít đi
    • Nguyên nhân của lỗ hổng bảo mật không phải là định dạng ảnh mới, mà là việc C/C++ thiếu an toàn bộ nhớ
      Nếu các encoder và decoder ảnh, cũng như các encoder/decoder khác, không dùng những ngôn ngữ không an toàn, thì khả năng tạo ra các lỗi như thế này sẽ thấp hơn
    • WebP là một định dạng phức tạp hơn JPEG rất nhiều, và độ phức tạp gần như tương quan trực tiếp với mật độ lỗi
      Ngoài ra, tôi cũng cho rằng văn hóa làm mã phức tạp hơn mức cần thiết và các nhà phát triển không thực sự hiểu rõ chi tiết cũng là vấn đề

  • Bản sửa lỗi này có trong Firefox 117.0.1 và Fenix 117.1.0 hôm nay: https://hg.mozilla.org/releases/mozilla-release/rev/e245ca21...

  • Tham khảo: image crate có một triển khai decoder WebP viết bằng Rust an toàn: https://github.com/image-rs/image
    Trong thời gian dài nó còn khá dang dở, nhưng năm ngoái nhiều tính năng WebP đã được triển khai
    Chromium hiện đã có chính sách cho phép dùng dependency Rust, vậy liệu Chromium cũng có thể bắt đầu áp dụng không?

    • Nếu Chrome có một flag kiểu “dùng phiên bản an toàn của thư viện XYZ dù có thể chậm hơn”, tôi sẽ chấp nhận mất hiệu năng và bật ngay
    • Đến năm 2023 mà vẫn tiếp tục viết mã C/C++ mới cho mục tiêu có bề mặt tấn công khổng lồ như trình duyệt web thì nghe thật vô lý

  • Commit ban đầu gây ra vấn đề: https://github.com/webmproject/libwebp/commit/f75dfbf23d1df1...
    Commit sửa lỗi này: https://github.com/webmproject/libwebp/commit/902bc919033134...
    Commit ban đầu tối ưu hóa bộ giải mã Huffman. Bộ giải mã này dùng một tối ưu hóa quen thuộc: đọc trước N bit rồi quyết định thực sự cần tiêu thụ bao nhiêu bit và phải giải mã thành symbol nào. Hoặc nếu đó là tiền tố N bit của nhiều symbol, nó sẽ quyết định cần tham chiếu bảng nào cho các bit còn lại
    Phiên bản cũ dùng bảng tra cứu cho các symbol ngắn, nhưng các symbol dài thì cần duyệt đồ thị. Phiên bản mới cải tiến bằng cách dùng một mảng các bảng tra cứu. Mỗi mục chứa (nbits, value), trong đó nbits là số bit cần tiêu thụ và value thường là symbol. Nhưng nếu nbits vượt quá N, value được diễn giải là chỉ mục bảng, còn nbits được diễn giải lại là độ dài mã dài nhất trong cây con đó. Vì vậy mỗi bảng theo sau phải có 2^(nbits - N) mục. Bảng gốc luôn cố định ở 2^N mục
    Phiên bản mới tính số mục tối đa (kTableSize) dựa trên số lượng symbol. Dĩ nhiên cây Huffman đến từ đầu vào không đáng tin cậy, và có thể dễ dàng hình dung trường hợp nbits trở nên rất lớn. Cụ thể, VP8 Lossless cho phép tối đa 15 bit, nên nếu mọi LUT đều được ánh xạ sang một bảng phụ riêng, bảng lớn nhất có thể có 2^N + 2^15 mục. Cũng không cần quá nhiều symbol để tạo ra điều này; chỉ cần 16-N symbol cho mỗi bảng là đủ
    Điều thú vị là bản thân mã có một chế độ chỉ tính kích thước bảng (gọi VP8LBuildHuffmanTable với root_table == NULL), nhưng không hiểu sao lại không được dùng và giả định một kích thước tối đa cố định. Vì vậy nếu tạo cây Huffman để tối đa hóa số mục, nó sẽ ghi tràn ra ngoài vùng đã cấp phát
    Có thể hiểu vì sao chuyện này xảy ra. Giai đoạn giải mã Huffman là một trong những phần tốn tính toán nhất trong nhiều định dạng nén, nên cả những cải tiến nhỏ cũng quan trọng. Tối ưu hóa trên khá nổi tiếng, nhưng đường đi của mã dài thường được xem là hiếm gặp nên có mức ưu tiên tối ưu hóa thấp. Thông điệp commit ban đầu đã phản bác giả định này và có thể được merge. Khó có thể chắc chắn rằng một ngôn ngữ an toàn bộ nhớ đã ngăn được vấn đề này hay không. Hiếm khi có trường hợp như ở đây, nơi người ta lại muốn chủ động tránh kiểm tra tràn
    [1] Tuy nhiên, hỏng bộ nhớ xảy ra trong lúc dựng bảng chứ không phải trong vòng lặp chặt, nên kiểm tra tràn một phần hẳn đã giúp ích rất nhiều. Bản sửa thực tế hoàn toàn không thay đổi hàm ReadSymbol. Dù vậy, tính an toàn của vòng lặp chặt vẫn cần được biện minh, và một biện minh sai có thể làm hỏng tất cả

    • Component này lẽ ra nên được viết bằng WUFFS
      Nếu nói rằng không cần kiểm tra biên là đúng thì ổn. WUFFS không phát sinh kiểm tra biên lúc runtime
      Nhưng nếu phần mềm sai vì vượt ra ngoài biên như lần này, thì trong WUFFS nó sẽ không biên dịch được
      Có thể bạn nghĩ “điều đó là bất khả thi”, và nếu WUFFS là một ngôn ngữ lập trình tổng quát thì nói vậy là đúng. Theo định lý Rice, các thuộc tính ngữ nghĩa không tầm thường là không quyết định được
      May mắn là WUFFS không phải ngôn ngữ tổng quát. Phần lớn phần mềm không thể viết bằng WUFFS, nhưng codec ảnh thì có thể
    • Đã hơn 10 năm tôi không làm lập trình viên C, mà vốn dĩ tôi cũng không giỏi lắm, nhưng qua phần mô tả thì tôi đồng ý rằng kiểm tra biên có lẽ đã bắt được vấn đề
      Dù vậy tôi cũng tự hỏi liệu có thể tạo được các bài kiểm thử tự động để bắt loại vấn đề này không
      Trong mã tôi tự xử lý, một số phép tính có thể được tách ra thành hàm riêng để kiểm thử độc lập. Ở đây có thể khó làm vì hiệu năng, nhưng tôi không chắc

  • Sửa lỗi ghi ngoài phạm vi trong BuildHuffmanTable
    https://github.com/webmproject/libwebp/commit/902bc919033134...

    • Cũng thú vị là ngay sau đó có một commit khác liên quan đến oss-fuzz: https://github.com/webmproject/libwebp/commit/95ea5226c87044...
      Có thể điều đó nghĩa là sau khi Google tìm ra lỗi này, họ đã tối ưu hóa fuzzer cho libwebp, và nhờ vậy đang tìm được thêm nhiều lỗi hơn

  • Có vẻ do Apple báo cáo, và trông rất giống bản cập nhật bảo mật này: https://support.apple.com/en-us/HT213906

    • Apple và “Citizen Lab của UoT Munk School” đã báo cáo, và trang được liên kết ghi đúng như vậy
      Vì thế khả năng này có vẻ khá cao. Có thể Apple đang dùng libwebp nội bộ trong ImageIO, hoặc đã mắc một sai lầm tương tự
    • Thật thú vị khi thấy phản ứng tuần trước và bây giờ khác nhau đến mức nào

  • Codec ảnh có một lịch sử dài các lỗ hổng
    Việc xử lý ảnh thực tế có thể là mã tuyến tính gọn gàng đến mức viết bằng FORTRAN IV an toàn bộ nhớ cũng được, nhưng khi có nén thì xuất hiện nhiều cấu trúc dữ liệu độ dài biến đổi, lần theo con trỏ, v.v.
    Thêm vào đó còn có áp lực phải chạy nhanh

  • Cái này có ảnh hưởng đến Electron không? Nếu có thì phiên bản nào?

  • Có đường nào thực tế để khai thác cái này không?
    Nghe nói trên 64-bit thì heap spray không còn thực dụng nữa
    Có đối tượng nào có thể dự đoán được trong bộ nhớ để ghi đè lên không?

    • Vì nó đã bị khai thác ngoài thực tế rồi, nên câu trả lời là có
      Ngay cả trên 64-bit, heap spray rõ ràng vẫn được dùng trong các kernel exploit. Tôi không rõ trong các exploit V8 thì người ta dùng primitive nào