Phân tích 0day WebP

 (blog.isosceles.com)
2 điểm bởi GN⁺ 2023-09-23 | 1 bình luận | Chia sẻ qua WhatsApp
  • Bản cập nhật ổn định của Chrome chỉ gồm một bản sửa bảo mật CVE-2023-4863 là lỗi tràn bộ đệm heap trong thư viện ảnh WebP, và Google cho biết đã có exploit tồn tại ngoài thực tế
  • Báo cáo ngày 6/9/2023 của Apple SEAR, CVE-2023-41064 của Apple, và các dấu hiệu của BLASTPASS do Citizen Lab công bố cho thấy rất có thể đây là cùng một lỗi
  • Phân tích cho thấy lỗ hổng nằm ở quá trình dựng bảng Huffman của VP8L, cơ chế nén không mất dữ liệu của WebP, nơi có thể ghi vượt quá kích thước bộ đệm đã tính trước
  • Lý do fuzzing thông thường khó phát hiện là vì cần tạo liên tiếp nhiều bảng Huffman kích thước tối đa cùng một bảng không hợp lệ cụ thể, tức điều kiện kích hoạt rất khắt khe
  • Bản vá upstream của libwebp có vẻ đã đủ, nhưng vì libwebp được dùng rộng rãi trong trình duyệt, hệ điều hành và ứng dụng nên việc phổ biến bản vá và sandboxing là rất quan trọng

Vì sao bản vá Chrome được nối với BLASTPASS

  • Google đã sửa CVE-2023-4863 do Apple Security Engineering and Architecture (SEAR) báo cáo trong bản cập nhật ổn định của Chrome đầu tháng 9/2023
    • Lỗ hổng là tràn bộ đệm heap trong thư viện ảnh WebP
    • Google cho biết họ biết rằng “exploit cho CVE-2023-4863 tồn tại ngoài thực tế”
  • Cùng thời điểm đó, Citizen Lab phát hiện hành vi đáng ngờ trên iPhone của một cá nhân thuộc tổ chức xã hội dân sự tại Washington DC
    • BLASTPASS là exploit zero-click zero-day qua iMessage, có liên quan tới trường hợp phát tán spyware Pegasus của NSO Group
    • Sau khi Citizen Lab chuyển kết quả phân tích kỹ thuật cho Apple, Apple đã công bố hai CVE trong thông báo bảo mật ngày 7/9
  • CVE đầu tiên của Apple, CVE-2023-41061, phù hợp với dấu hiệu cho thấy tệp đính kèm PassKit đã gói một exploit ảnh để vượt qua sandbox BlastDoor của iMessage
    • Ảnh độc hại có vẻ đã được xử lý ở một tiến trình khác không có sandbox
  • CVE thứ hai, CVE-2023-41064, là lỗ hổng tràn bộ đệm trong Apple ImageIO
    • ImageIO là framework phân tích ảnh của Apple dùng để nhận diện nhiều định dạng ảnh và chuyển sang bộ giải mã phù hợp
    • Do không có chi tiết kỹ thuật nên chưa thể xác nhận CVE-2023-41064 ảnh hưởng tới định dạng ảnh nào
  • Vì Apple gần đây đã thêm hỗ trợ WebP vào ImageIO, nhóm bảo mật Apple đã báo lỗi WebP cho Chrome vào ngày 6/9, và Google tung bản vá khẩn chỉ sau 5 ngày đồng thời đánh dấu là đang bị khai thác ngoài thực tế, nên BLASTPASS và CVE-2023-4863 rất có thể là cùng một lỗi

Vị trí lỗ hổng mà bản vá libwebp chỉ ra

  • Đối chiếu bug ID trong thông báo bảo mật của Chrome với commit mã nguồn mở của libwebp cho thấy bản vá Fix OOB write in BuildHuffmanTable chính là CVE-2023-4863
    • Bản vá được tạo vào ngày 7/9/2023, tức một ngày sau báo cáo của Apple
  • Lỗ hổng nằm trong VP8L, thành phần hỗ trợ nén không mất dữ liệu của WebP
    • Nén không mất dữ liệu của WebP dùng Huffman coding để lưu và khôi phục pixel chính xác 100%
    • Cách triển khai hiện đại tối ưu giải mã bằng cách dùng bảng thay cho cấu trúc cây mang tính khái niệm
  • Phiên bản dễ bị tấn công cấp phát bộ nhớ bằng kích thước bộ đệm tính trước lấy từ bảng cố định, sau đó dựng trực tiếp bảng Huffman vào vùng đó
    • Phiên bản mới tính tổng kích thước cần cho bảng đầu ra trong pass đầu tiên nhưng chưa thực sự ghi dữ liệu
    • Nếu tổng kích thước lớn hơn bộ đệm tính trước thì sẽ cấp phát vùng lớn hơn
  • Luồng chính là huffman_tables được cấp phát trong ReadHuffmanCodes của src/dec/vp8l_dec.c, và lời gọi VP8LBuildHuffmanTable/BuildHuffmanTable trong ReadHuffmanCode
    • Các bảng Huffman được chia thành 5 segment với kích thước alphabet khác nhau
    • Muốn tạo tràn bộ đệm thì phải dàn dựng chính xác cả 5 bảng này

Quá trình tạo tệp kích hoạt

  • Nén không mất dữ liệu WebP gán chuỗi bit ngắn cho các giá trị xuất hiện thường xuyên và chuỗi bit dài cho các giá trị hiếm, dựa trên phân tích tần suất của pixel đầu vào
    • Mã được xây dựng sao cho bộ giải mã luôn có thể phân biệt độ dài chuỗi bit
    • Ảnh nén phải chứa thông tin thống kê và thông tin gán mã để tái tạo ánh xạ giữa mã và giá trị
  • WebP còn nén chính các bảng Huffman bằng Huffman coding để giảm kích thước tệp
    • Cấu trúc này khiến việc phân tích và kích hoạt lỗ hổng trở nên phức tạp
  • @mistymntncop đã cung cấp mã harness để tạo WebP đúng định dạng với dữ liệu Huffman tùy ý, tức các code lengths
    • Nhờ harness này có thể truyền một mảng code_lengths tùy ý vào lời gọi BuildHuffmanTable mục tiêu
  • Trong quá trình thử nghiệm thủ công, tương tác giữa histogram bên trong BuildHuffmanTable, num_open, num_nodes, và giá trị key theo dõi vị trí bắt đầu của ReplicateValue là cực kỳ phức tạp
    • Root table từ count[0] đến count[8] không ảnh hưởng trực tiếp nhiều tới total_size nhưng có thể làm thay đổi trạng thái nội bộ về sau
    • Second level tables từ count[9] đến count[15] ảnh hưởng trực tiếp tới total_size cuối cùng
  • enough.c của Mark Adler in ra histogram của lookup table cây Huffman tối đa có thể có theo kích thước alphabet, kích thước root table, và độ dài mã tối đa
    • Chú thích trong libwebp nói rằng kTableSize được tính bằng công cụ này
    • Có thể tái tạo kích thước bộ đệm tính trước bằng công cụ đó, và cũng xác nhận bằng công cụ của @mistymntncop rằng các code lengths do “enough” tạo ra có thể lấp đầy 100% vùng cấp phát huffman_tables

Điều kiện để tràn bộ đệm thực sự xảy ra

  • Công cụ enough tính giá trị tối đa cho mã hợp lệ và đầy đủ
    • Với một bảng nhỏ có kích thước symbol là 40, root table 8 bit, và độ dài mã tối đa 15, kích thước tối đa là 410
    • Không tìm thấy trường hợp nào mà mã được BuildHuffmanTable xem là hợp lệ lại tạo ra kích thước lớn hơn 410
  • Tràn bộ đệm không xảy ra khi chỉ dùng cây Huffman hợp lệ, mà xuất hiện khi chèn cây Huffman không hợp lệ ở bước cuối
    • Trước tiên tạo bảng đầu ra kích thước tối đa bằng 4 cây Huffman hợp lệ
    • Khi đưa cây Huffman không hợp lệ vào bảng cuối cùng, ReplicateValue có thể ghi vượt phạm vi trước khi bước kiểm tra tính nhất quán cuối cùng diễn ra
  • Việc tái hiện được thực hiện bằng cách checkout commit libwebp dễ bị tấn công 7ba44f80f3b94fc0138db159afea770ef06532a0, bật AddressSanitizer, rồi dùng mã PoC của @mistymntncop để tạo bad.webp và giải mã bằng dwebp
    • AddressSanitizer báo heap-buffer-overflow trong BuildHuffmanTable
    • Ghi nhận được thao tác ghi xảy ra ngay sau vùng có kích thước 11816 byte
  • Có nhiều đầu vào có thể làm tràn huffman_tables
    • Trong số các code lengths được tìm thấy có trường hợp ghi xa tới 400 byte sau cuối vùng cấp phát huffman_tables
    • Dù khả năng kiểm soát giá trị ghi chỉ là một phần, việc exploit vẫn có vẻ khả thi
  • Cây Huffman của đầu vào không hợp lệ bị mất cân bằng một phần, và một đoạn trong nhánh mất cân bằng chứa nhiều nút nội bộ không có nút con
    • Cấu trúc này tạo ra các chỉ số key mà cây hợp lệ không thể đạt tới

Cách bản vá ngăn tràn bộ đệm

  • Ban đầu có vẻ như bản vá ngăn tràn heap bằng cách tăng động kích thước bộ đệm cho phù hợp với dung lượng cần thiết
  • Thực tế, pass đầu tiên của phiên bản đã vá chạy BuildHuffmanTable để tính tổng kích thước cần thiết nhưng không ghi vào bảng
    • Đầu vào không hợp lệ từng gây tràn bộ đệm sẽ khiến BuildHuffmanTable thất bại và trả về 0 ngay trong pass đầu tiên này
    • Vì pass đầu tiên không ghi dữ liệu nên dù cây không hợp lệ được xử lý một phần cũng không phát sinh ghi vượt phạm vi
  • Vì không tìm thấy trường hợp mã hợp lệ và đầy đủ nào gây cùng kiểu tràn bộ đệm, nên bản vá này có vẻ là đủ

Vì sao fuzzing khó phát hiện lỗi này

  • libwebp đã được fuzzing trong Google OSS-Fuzz từ lâu, và hỗ trợ WebP lossless cũng được fuzzing rất rộng
  • Khó khăn cốt lõi là cả định dạng lẫn điều kiện kích hoạt đều phức tạp
    • Trong hàng chục tỷ khả năng, trước hết phải dựng 4 bảng Huffman kích thước tối đa cho kích thước alphabet 280 và 256
    • Sau đó còn phải tạo một bảng Huffman không hợp lệ có hình dạng cực kỳ cụ thể cho kích thước alphabet 40
    • Chỉ cần sai 1 bit ở bất kỳ bước nào, bộ giải mã ảnh sẽ báo lỗi và thoát an toàn
  • Sau khi sửa 0day WebP, Google đã phát hành một fuzzer mới chuyên cho các routine Huffman của WebP
    • Ngay cả khi chạy fuzzer đó thì CVE-2023-4863 vẫn không được phát hiện
  • Các kỹ thuật như đột biến bitflip tiêu chuẩn, vòng lặp phản hồi theo code coverage, hay cách tiếp cận dựa trên trạng thái đầu vào như CmpLog của AFL++ cũng khó đi qua các bước trung gian để đạt tới trạng thái cực đoan này
    • Kỹ thuật thực thi tượng trưng động như TritonDSE của Quarkslab có thể có triển vọng, nhưng chưa được xác nhận
  • Tính chất của lỗi này khác với lỗ hổng Load_SBit_Png trong FreeType
    • Với Load_SBit_Png, harness fuzzing đã không phản ánh đầy đủ cách API được dùng nên lỗi không bị phát hiện
    • Với CVE-2023-4863, đây gần như là trường hợp fuzzing khó khăn do chính các ràng buộc của lỗ hổng hơn là do thiếu harness

Phạm vi ảnh hưởng và tình trạng ứng phó

  • Citizen Lab đã bắt được một exploit tinh vi được dùng ngoài thực tế, và Apple cùng Chrome dường như đã phát hành bản cập nhật tới hàng tỷ người dùng chỉ trong vài ngày
  • Android khi đó vẫn có khả năng bị ảnh hưởng
    • BitmapFactory của Android, giống như ImageIO của Apple, xử lý giải mã ảnh và hỗ trợ libwebp
    • Thông báo bảo mật Android thời điểm đó chưa bao gồm bản sửa cho CVE-2023-4863, nhưng bản sửa đã được hợp nhất vào AOSP
    • Nếu Android bị ảnh hưởng, điều này có thể dẫn tới exploit từ xa trong các ứng dụng như Signal hoặc WhatsApp
    • Dự kiến bản sửa sẽ xuất hiện trong thông báo bảo mật tháng 10
  • Bản vá upstream của libwebp có vẻ đã được áp dụng đúng và đang được lan rộng tới các nơi cần thiết
  • Vì libwebp được sử dụng ở rất nhiều nơi, có thể sẽ mất thời gian để bản vá được phổ biến đầy đủ
  • Với mã parser phức tạp nằm gần bề mặt tấn công zero-click remote exploit như giải mã ảnh, chỉ fuzzing là không đủ để đảm bảo an toàn; cần đầu tư vào rà soát mã nguồn chủ động và sandboxing phù hợp

Bất cân xứng trong việc công bố thông tin kỹ thuật

  • Khi vendor không công bố đủ chi tiết kỹ thuật, bên phòng thủ sẽ khó xác minh phạm vi ảnh hưởng của lỗ hổng
  • Kẻ tấn công có động cơ mạnh để theo dõi và khai thác các lỗ hổng N-day, và việc không công khai chi tiết cũng không làm họ chậm lại nhiều
  • Bên phòng thủ thường không có đủ nguồn lực để thực hiện mức phân tích kỹ thuật như vậy
  • Nếu ngay cả thông tin cơ bản về cách thức tấn công cũng bị che giấu, sẽ xuất hiện tình trạng bất cân xứng khi kẻ tấn công có nhiều hiểu biết hơn bên phòng thủ về lỗ hổng và exploit

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-09-23
Ý kiến trên Hacker News

  • Lỗi này trông giống nhất với lỗi Timsort năm 2015 [1]
    Timsort là một thuật toán sắp xếp lai thông minh xuất phát từ CPython, và nhiều bản triển khai, bao gồm OpenJDK, đã tiếp nhận nó gần như bằng cách dịch ở cấp mã nguồn. Nó duy trì một stack các run đã được sắp xếp, và từng có chứng minh rằng về mặt cấu trúc tồn tại một cận trên hữu hạn đủ nhỏ cho kích thước stack tối đa có thể. Tuy nhiên, bản triển khai CPython ban đầu không khớp chính xác với chứng minh, nên trong một số trường hợp hiếm vẫn có thể xảy ra tràn stack. Vì vậy, với CPython đây là một lỗi bảo mật nghiêm trọng, nhưng Java thì ném exception trong trường hợp đó, nên trong OpenJDK nó không phải là vấn đề bảo mật theo cùng cách
    Tương tự, lỗi WebP lần này cũng phát sinh vì kích thước bảng tối đa đã được chứng minh về mặt hình thức, nhưng lại không khớp với giá trị đi vào mã nguồn thực tế. Những lỗi kiểu này rất khó xác minh và review. Vì có chứng minh, và mã nguồn cũng trông có vẻ khớp với chứng minh đó, nên rất dễ nghĩ rằng mọi thứ ổn. Đây có vẻ là tín hiệu cho thấy rất cần các phương pháp xác minh hình thức dễ tiếp cận hơn so với review thủ công, cũng như việc dùng ngôn ngữ an toàn bộ nhớ. Hệ thống kiểu cũng có thể được xem là một dạng xác minh hình thức yếu
    [1] http://envisage-project.eu/wp-content/uploads/2015/02/sortin...

    • Những việc như thế này có yêu cầu hiệu năng cao, nên đặc biệt nên được viết bằng WUFFS. WUFFS không phát sinh kiểm tra biên như Java, cũng không giống Rust ở chỗ kiểm tra tại runtime khi không rõ index có nằm trong phạm vi hay không; thay vào đó, nếu công cụ không thể xác nhận index nằm trong phạm vi, nó sẽ từ chối chính chương trình
      https://github.com/google/wuffs
      Cũng có thể thỏa mãn yêu cầu này bằng cách viết tường minh các kiểm tra tương tự, nhưng nếu trước đó bạn tin rằng phần mềm hiệu năng cao này không cần kiểm tra, thì rất có khả năng bạn sẽ phát hiện mình sai ở điểm mà công cụ WUFFS không chấp nhận mã. Nó yếu hơn xác minh hình thức đầy đủ, nhưng là một cải thiện lớn cho mục tiêu an toàn chương trình, và tốt hơn nhiều so với việc con người nói “LGTM”
    • Việc “có thể xem hệ thống kiểu là xác minh hình thức yếu” còn tùy vào loại hệ thống kiểu. Gần đây tôi xem Idris, và có vẻ đó là một ngôn ngữ lập trình đa dụng đồng thời cũng có thể dùng cho chứng minh

  • Trong bài này có vài điểm thú vị ngoài chuyện “bây giờ cần vá cái gì”. Ngay cả khi biết vị trí lỗ hổng và nội dung sửa lỗi, việc tái tạo PoC khai thác vẫn có thể cần khá nhiều công sức, và bộ giải nén lossless bên trong image decoder có thể khá chống chịu với fuzzing. Với người làm bảo mật thì có thể là chuyện hiển nhiên, nhưng với người không chuyên thì đọc khá thú vị

    • Cách giải cho những vấn đề như thế này không phải là fuzzing, mà là cắt bỏ phần mã đó như cắt khối u. Nếu vì vậy mà nhiều chỗ trong OS hoặc trình duyệt bị hỏng, thì chỉ cần viết một bộ chuyển đổi định dạng an toàn bộ nhớ, được sandbox mạnh, để xử lý định dạng có vấn đề. Tôi cho rằng một chiếc iPhone hay trình duyệt hơi bất tiện trong vài edge case vẫn tốt hơn kiểu mã gần như chắc chắn có lỗ hổng như thế này, bất kể có fuzzing hay không. Nói vậy có phần lạc quan, nhưng tôi chắc chắn câu chuyện này sẽ chưa kết thúc ở đây

  • Có vài câu hỏi tôi không tìm được câu trả lời rõ ràng. 1) Các trình duyệt dựa trên Chrome khác như Brave có bị ảnh hưởng không? 2) Chrome desktop có bị ảnh hưởng không, hay chỉ là vấn đề trên mobile? 3) Tại sao tôi chưa từng nghe đến WebP? Tôi tự hỏi không biết mình đã tách biệt với thế giới, hay đây là công nghệ ưu tiên mobile

    • Câu hỏi hay. Các trình duyệt dựa trên Chromium khác rất có khả năng cũng bị ảnh hưởng bởi lỗi này. Nhiều trình duyệt như Brave theo khá sát các bản cập nhật bảo mật của Chromium, nhưng cũng có trường hợp tụt lại khá xa như Samsung SBrowser
      Chrome desktop cũng bị ảnh hưởng trên cả Linux lẫn Windows. Chrome bundle libwebp riêng, nên ngay cả khi distro Linux chưa vá, nếu Chrome đã cập nhật thì ít nhất xét từ góc độ tấn công qua trình duyệt là ổn
      Các trình duyệt và hệ điều hành lớn hỗ trợ rất nhiều định dạng ảnh lạ đến đáng ngạc nhiên. Ví dụ trên MacOS có thể tải KTX2 (Khronos Texture Container), còn trên Android có thể tải DNG (Adobe Digital Negative). Có rất nhiều bề mặt tấn công thú vị và có mức độ phơi bày cao để kẻ tấn công khám phá
    • Mọi thứ hỗ trợ WebP đều bị ảnh hưởng. Không chỉ Chrome hay Electron, mà gồm tất cả trình duyệt, desktop và mobile, cũng như cả phần mềm không phải trình duyệt. Trình xem ảnh, chương trình đồ họa, email client, cho tới file manager hiển thị thumbnail đều thuộc diện này
      Lỗi nằm trong thư viện codec, và WebP là một hệ sinh thái về cơ bản chỉ có một bản triển khai, nên mọi người dùng cùng một thư viện và đều phải vá
      Google đã thúc đẩy WebP từ 10 năm trước, nhưng trong thời gian dài nó chỉ dành cho Chrome nên không tạo được nhiều lực kéo. Nó cũng chưa được chuẩn hóa đúng nghĩa, dù là mã nguồn mở. Ảnh chất lượng thấp thì nén tốt hơn JPEG, nhưng ở ảnh chất lượng cao nó có xu hướng làm màu bị lem và mờ. Trớ trêu là vào thời điểm WebP bắt đầu được hỗ trợ rộng rãi, nó về mặt kỹ thuật đã dần trở nên lỗi thời trước AVIF và JPEG XL
    • Gần như chắc chắn bạn đã từng tải ảnh WebP, nhưng có thể không nhận ra vì nhiều website phục vụ nhiều định dạng từ cùng một URL. Thường thì HTTP reverse proxy tự động chuyển đổi định dạng, nên với trình duyệt trong khoảng 10 năm gần đây, bạn vẫn có thể nhận WebP dù phần mở rộng file tải xuống trông như “.png”. Các trình biên tập ảnh hiện đại đều hỗ trợ WebP, nên khó nhận ra khác biệt
    • WebP đã được hỗ trợ trên Chrome desktop từ lâu. Đã có hàng chục định dạng thay thế JPEG xuất hiện rồi biến mất, và WebP nổi bật chủ yếu vì có ảnh hưởng của Google đứng sau. Khi Google mua Duck/On2, họ có được nhiều công nghệ nén video, và một phần trong đó đã đi vào WebP
    • Tất cả trình duyệt đều bị ảnh hưởng, và Firefox cũng đã phát hành bản cập nhật bảo mật. WebP đang ngày càng phổ biến như một lựa chọn thay thế JPEG, nên nếu nhìn vào chuyện ảnh tải từ web ngày càng xuất hiện dưới dạng WebP, việc bạn chưa gặp nó lần nào là điều khá đáng ngạc nhiên

  • Nếu thiết bị Android đã hết hỗ trợ, có phải hiện giờ về thực tế nó đang bị phơi trước một exploit 0-click đang lưu hành ngoài đời? Hay chỉ cần cập nhật các ứng dụng như SMS, Chrome, WhatsApp, Signal là đã đủ chặn các đường vào chính?

    • Chưa rõ đã có exploit Android cho lỗi này hay chưa. Exploit ban đầu là dành cho iOS qua iMessage, nhưng khả năng nó đã được phát triển là khá cao. Nhu cầu cho các exploit kiểu này trên Android hiện nay rất lớn, và gần đây tôi nghe nói đến những mức giá phi lý
      Trên thiết bị đã hết hỗ trợ, cập nhật Chrome sẽ sửa được vấn đề của Chrome, nhưng để sửa các ứng dụng như Signal hay WhatsApp thì cần nâng cấp Android OS. Chrome đóng gói libwebp riêng, nhưng các ứng dụng có mức độ phơi nhiễm cao như ứng dụng nhắn tin và Gmail dùng giao diện do OS cung cấp để hiển thị ảnh. Với các thiết bị Android còn được hỗ trợ bảo mật, có thể kỳ vọng bản cập nhật sẽ bắt đầu ra từ đầu tháng 10
    • Thư viện giải mã ảnh của nền tảng nên là một trong các module hệ thống được cập nhật qua Play Store. Không biết có ai xác nhận được thực tế có đúng vậy không
    • Một số ứng dụng nhắn tin có tùy chọn không tự động tải xuống hoặc xem trước ảnh nhận được, nên bật thiết lập đó có thể là một biện pháp tốt. Google Messages có tính năng này
    • Nếu Android đã nằm ngoài diện nhận cập nhật bảo mật, thì thứ cần lo không chỉ có mỗi lỗi này. Tôi sẽ lo các thứ dễ bị khai thác hơn trước
    • Trên iOS, đây là vấn đề đặc biệt lớn vì iMessage có quyền cao. Trên Android, tất cả các ứng dụng kiểu đó đều nằm trong sandbox

  • Câu “có nhiều input thực sự làm tràn huffman_tables” trông giống một vấn đề tổng quát hơn. Cấu trúc là phần mềm A tạo bảng tra cứu B, và bảng đó được dùng để xử lý luồng dữ liệu đầu vào
    Từ giờ, nếu nhà phát triển quan tâm dù chỉ một chút đến bảo mật hoặc tính đúng đắn, họ phải bảo đảm một trong hai điều. A) phần mềm được viết sao cho không dữ liệu đầu vào nào có thể khiến bảng tra cứu bị dùng sai hoặc thất bại, hoặc B) nó chỉ được dùng trong môi trường được kiểm soát, chẳng hạn liên lạc điểm-điểm nơi cả hai bên đều đáng tin cậy, với bảo đảm rằng luồng dữ liệu sẽ không bao giờ dùng sai bảng tra cứu hay gây bất thường
    B gần như bất khả thi ngoài các nhóm nhỏ hoặc văn phòng, và ở quy mô Internet thì thật sự không thể, nên cuối cùng chỉ còn A. Thực hành tốt được tổng quát hóa cho kỹ nghệ phần mềm trong tương lai là: nếu vì bất kỳ lý do gì mà dùng bảng tra cứu, nhà phát triển phải bảo đảm bảng đó hoạt động đúng với mọi loại dữ liệu, hoặc phải phát hiện dữ liệu sai và xử lý phù hợp trước khi nó chạm tới bảng
    Nếu là một nhà nghiên cứu bảo mật nghiêm túc và có thời gian, có lẽ tôi sẽ tập hợp danh sách mọi lỗ hổng bảo mật trong quá khứ có liên quan dưới bất kỳ hình thức nào đến bảng tra cứu, đọc từng cái và so sánh điểm chung. Có lẽ sẽ có một mẫu hình nào đó. Sau đó tôi sẽ rà soát mọi phần mềm dùng bảng tra cứu cho luồng dữ liệu và audit lỗ hổng, nhưng đây không phải việc một người có thể làm cả đời; nó là môn thể thao đồng đội

  • Việc công khai mã nguồn đã giúp NSO ở mức nào trong việc tìm ra lỗi này? Nếu code chỉ là binary blob, không biết chỉ với các decompiler hiện đại liệu có đủ để hiểu code và tìm ra một lỗi khó hiểu như vậy không

    • Blob không ngăn được kẻ tấn công. Để viết exploit thành công thì dù sao cũng phải hiểu binary đã biên dịch

  • Điều đáng ngạc nhiên là đây không phải phần “mới” của định dạng ảnh. Nén Huffman đã tồn tại hơn 70 năm, Huffman chuẩn tắc cũng chỉ kém vài chục năm, và ngay cả JPEG cũng dùng Huffman. Đây là công nghệ đã có hàng chục năm, có vô số bài viết về cách triển khai, nên trông như một công nghệ lẽ ra các bug trong nhiều triển khai đã phải được dọn sạch rồi
    Trước đây tôi từng đọc đặc tả JPEG và tự viết decoder, nên đã xem đặc tả WebP: https://developers.google.com/speed/webp/docs/webp_lossless_...
    Phần quan trọng nằm ở mục 6. Điều đầu tiên đập vào mắt là cách code được cấu thành không rõ ràng như đặc tả JPEG. JPEG có nhiều lưu đồ dễ đọc về quy trình. WebP trông giống LZH/deflate(zlib), và giống một tập hợp vài đoạn mã nguồn có chú giải hơn là “đặc tả”
    Sau GIF, JPEG, PNG, tôi cũng có ý định viết thử decoder WebP, nhưng chỉ nhìn “đặc tả” trên thì gần như cảm giác nó đang bảo đừng viết

    • Tôi đồng ý là đặc tả thật sự thiếu ví dụ, nhưng nó có ghi rõ rằng vì dùng cây Huffman chuẩn tắc nên chỉ cần truyền độ dài mã. Tôi nghĩ như vậy là đủ rõ để xác định cây thực tế. Chắc sẽ không có triển khai Huffman chuẩn tắc nào dùng thứ tự từ điển ngược
      Triển khai cây Huffman có nhiều đánh đổi khác nhau, nên khó nói chỉ vì là công nghệ cũ mà bug đã được dọn sạch hết. Charles Bloom từng nói rằng bài báo mang tính quyết định năm 1997 về tối ưu Huffman [1] thậm chí đến năm 2010 vẫn chưa được biết đến rộng rãi, và nhiều tối ưu đã được tái phát hiện rồi lại bị lãng quên. Vì vậy rất có khả năng có nhiều triển khai kém hiệu quả
      [1] https://cbloomrants.blogspot.com/2010/08/08-12-10-lost-huffm...
    • Nếu cần code để tham khảo, có một decoder WebP-Lossless dưới 1200 dòng tại https://github.com/golang/image/tree/master/vp8l

  • Giờ có vẻ ngay cả xem ảnh cũng không thể không lo về bảo mật

    • Nếu hãng phần mềm dùng một thư viện chậm hơn một chút khi render ảnh, họ có thể tránh được mối lo bảo mật nghiêm trọng nhất là thực thi mã từ xa. Tránh các thư viện viết bằng C có thể gần như loại bỏ thực thi mã từ xa, và người dùng cũng an toàn hơn
    • Có thể tôi nhớ nhầm, nhưng hình như PNG và JPG cũng từng ít nhất một lần có chuyện tương tự
      Nghe như những cơn đau tăng trưởng điển hình khi dùng C, một ngôn ngữ không an toàn. Tôi hiểu nó hấp dẫn vì tốc độ trình duyệt, nhưng mong ngành này thoát khỏi cách khuyến khích lặp lại cùng những sai lầm kể từ khi bắt đầu dùng C
      Cảm giác như xây cầu bằng vít tự khoan thay vì đinh tán chỉ vì nhanh hơn. Khi cầu bắt đầu võng xuống thì lại cứ đóng thêm vít vào

  • “Tin tốt là Apple và Chrome đã phản ứng xuất sắc tương xứng với tính cấp bách của vấn đề này” — nói vậy thật khó chấp nhận. Chính Google là bên đã phân loại vấn đề này là chỉ dành cho Chrome. Chỉ nhìn 7 ngày vừa qua thôi, tất cả các bản phân phối Linux lớn đều đã phải đẩy bản cập nhật, và Red Hat chấm mức 9,6 điểm. Các image Python Docker đã được pull hơn 1 tỷ lần, Puppeteer, WordPress, Node.js, v.v. cũng bị ảnh hưởng, nhưng CRBug đến giờ vẫn còn ở chế độ riêng tư
    Những trang như BleepingComputer đã đưa tin theo những gì thấy được mà không điều tra, và nhiều công ty bảo mật xử lý vấn đề này như thể họ là bên thứ ba cũng vậy. Khi biết đối phương không thẩm định kỹ, thật sự rất khó xây dựng niềm tin
    Adam Caudill đã viết một bài hay có tên “Whose CVE is it anyway?”[0], cùng với ví dụ 1Password vá lỗi từ sớm, và bài đó chỉ ra rất đúng vấn đề đang nói ở đây. Citizen Lab từ chối trả lời liệu hai vấn đề có liên quan hay không, nhưng cũng có những điểm không cần phải là thiên tài mới thấy được
    [0]: https://adamcaudill.com/2023/09/14/whose-cve-is-it-anyway/

    • Lý do Apple và Chrome đặc biệt quan trọng ở đây là vì đó là các mục tiêu đã bị khai thác ngoài thực tế, đồng thời có bề mặt tấn công trực tiếp với số lượng người dùng lớn nhất
      Tác giả cũng nói rằng nhiều hệ thống khác cần phải vá. Tuy nhiên, trong số các image Python Docker đã được pull 1 tỷ lần, có bao nhiêu image thực sự render ảnh WebP không đáng tin cậy? Node và các thứ khác cũng tương tự. Tất nhiên vẫn phải vá nhanh, nhưng không cùng cấp độ với iOS/Android/Chrome

  • Hàng trăm triệu người trên toàn thế giới bị ảnh hưởng bởi thư viện này, và mức ảnh hưởng còn nhân lên nhiều lần theo từng thiết bị và ứng dụng họ dùng
    Tôi thích C, nhưng tôi cho rằng những thư viện được hàng trăm triệu người trên thế giới dùng thì không nên dùng C. Tỷ lệ rủi ro trong các thư viện lõi như thế này là quá cao. Dù là chuyên gia C thì rồi cũng sẽ có lúc mắc lỗi
    Có vẻ đây là bản sửa https://github.com/webmproject/libwebp/commit/dce8397fec159c...
    “malloc fail” thật bực bội. Slack, Discord, Teams, cho đến mọi hệ điều hành hiện đại đều bị ảnh hưởng

    • Bản sửa thực sự là ở đây: https://github.com/webmproject/libwebp/commit/902bc919033134...
    • Tôi cũng nghĩ vậy. Rust nên trở thành C mới. Việc có thể code bằng C không có nghĩa là có thể sản xuất hàng loạt mã phức tạp với những lý do như “hiệu năng”, “tính di động”, “tương thích legacy”
      C/C++ và các ngôn ngữ động tạo ra bề mặt rất lớn cho hành vi không xác định và các lỗi tinh vi, khiến ngay cả những nhà phát triển thông minh nhất cũng khó lint và chịu nhiều gánh nặng. Các thư viện nền tảng nên được kiểm chứng hình thức theo cách tương tự seL4
      Một vấn đề khác là sự thiếu chuyên nghiệp lan rộng trong toàn bộ FOSS, cùng với việc xem nhẹ tính nghiêm ngặt, chất lượng, độ chính xác và bảo mật. Cách xây dựng đế chế trên cát như hiện nay là ngu xuẩn
    • Dù là commit này hay commit lân cận, không có một bài test nào. Thật không thể tin nổi