- FFmpeg là framework mã nguồn mở cốt lõi cho xử lý media trên toàn cầu, là thành phần thiết yếu được dùng trong các dịch vụ lớn như VLC·Chrome·YouTube
- Gần đây, trình quét bảo mật dùng AI của Google phát hiện một lỗi nhỏ liên quan đến codec trò chơi từ năm 1995, làm dấy lên tranh cãi rằng các tập đoàn lớn đang đẩy gánh nặng quá mức lên các nhà phát triển tình nguyện
- Phía FFmpeg cho biết “dự án gần như được duy trì hoàn toàn bởi tình nguyện viên”, và cho rằng Google không nên chỉ báo cáo lỗ hổng mà cần cung cấp bản vá hoặc hỗ trợ tài chính
- Google nhấn mạnh đóng góp bảo mật minh bạch dựa trên chính sách công khai của Project Zero và chương trình Patch Rewards, nhưng cộng đồng FFmpeg chỉ ra giới hạn phần thưởng và sự thiếu hụt hỗ trợ thực tế
- Tranh cãi lần này cho thấy vấn đề AI tạo ra hàng loạt CVE và tính bền vững của việc bảo trì mã nguồn mở, đồng thời dẫn tới thảo luận về trách nhiệm của các tập đoàn công nghệ lớn
Tổng quan xung đột giữa FFmpeg và Google
- FFmpeg là framework đa phương tiện mã nguồn mở hỗ trợ transcoding, phát lại, streaming cho tệp âm thanh và video
- Các thư viện lõi như libavcodec, libavformat được dùng trong VLC, Kodi, Plex, Chrome, Firefox, YouTube...
- Tuy nhiên, cũng như nhiều dự án mã nguồn mở lớn khác, FFmpeg đang ở trong tình trạng thiếu hụt tài chính nghiêm trọng
- Trên Twitter đã nổ ra tranh luận giữa FFmpeg, Google, Chainguard và các nhà nghiên cứu bảo mật về cách công bố lỗ hổng bảo mật và trách nhiệm liên quan
- Trọng tâm thảo luận là việc AI tạo ra số lượng lớn báo cáo lỗ hổng nhưng nhiều trường hợp có giá trị thực tế thấp
Khởi nguồn tranh cãi: lỗi nhỏ do AI của Google phát hiện
- Tác nhân AI của Google phát hiện trong FFmpeg một lỗi liên quan đến giải mã codec LucasArts Smush
- Vấn đề này là lỗ hổng mức trung bình, chỉ ảnh hưởng đến 10~20 khung hình đầu tiên của trò chơi năm 1995 Rebel Assault 2
- Các nhà phát triển FFmpeg đã vá lỗi này, nhưng chỉ trích kiểu báo cáo kém hiệu quả và gọi đó là “CVE tràn lan (CVE slop)”
- FFmpeg cho biết họ hướng tới khả năng tương thích hoàn hảo với tuyên bố “FFmpeg aims to play every video file ever made”, nhưng cũng nói rằng phần lớn mã được viết bằng hợp ngữ, nên rất khó bảo trì
Gánh nặng đối với người bảo trì mã nguồn mở
- Cộng đồng FFmpeg chỉ trích rằng các tập đoàn lớn sử dụng FFmpeg như Google đang đẩy việc sửa lỗ hổng cho các tình nguyện viên không lương
- Quan điểm của họ là khi báo cáo lỗ hổng, Google cần đi kèm bản vá hoặc hỗ trợ tài chính
- Một ví dụ tương tự là Nick Wellnhofer, người bảo trì libxml2, đã tuyên bố ngừng bảo trì vì các báo cáo bảo mật lặp đi lặp lại từ bên thứ ba
- Ông cho biết việc một tình nguyện viên không được trả công phải dành nhiều giờ mỗi tuần để xử lý vấn đề bảo mật là điều không bền vững
Tranh cãi quanh chính sách công bố của Google Project Zero
- Tháng 7/2025, Google Project Zero(GPZ) đưa ra chính sách ‘** Reporting Transparency**’
- Lỗ hổng sẽ được công khai trong vòng 1 tuần sau khi phát hiện, và từ đó tự động bắt đầu thời hạn 90 ngày để sửa
- Việc vẫn công khai ngay cả khi bản vá chưa sẵn sàng bị chỉ trích là gây áp lực quá mức lên các dự án dựa chủ yếu vào tình nguyện viên
- FFmpeg đặt câu hỏi: liệu có công bằng không khi “AI tìm ra vấn đề bảo mật trong đoạn mã viết như sở thích rồi yêu cầu tình nguyện viên sửa”
- Dù Google có Patch Rewards Program, FFmpeg chỉ ra rằng “giới hạn 3 trường hợp mỗi tháng khiến nó không mang lại nhiều trợ giúp thực tế”
Góc nhìn đối lập và tính bền vững của mã nguồn mở
- Dan Lorenc của Chainguard bảo vệ vai trò của Google khi nói rằng việc công bố lỗ hổng bảo mật cũng là một đóng góp cho hàng hóa công số
- Ông cho rằng Google là một trong những công ty tích cực nhất trong việc hỗ trợ mã nguồn mở, và những tranh cãi như vậy thậm chí có thể khiến nhà tài trợ xa lánh hơn
- Tuy nhiên, phía FFmpeg nhấn mạnh họ thiếu nhân lực và tài chính để ứng phó với làn sóng CVE do AI tạo ra
- Các chuyên gia bảo mật cũng thừa nhận rằng vì FFmpeg là thành phần cốt lõi của hạ tầng Internet, việc công bố lỗ hổng vẫn là cần thiết
- Cuối bài viết nhấn mạnh rằng nếu không có hỗ trợ thực chất từ các tập đoàn lớn, việc duy trì các dự án mã nguồn mở cốt lõi là bất khả thi, đồng thời lấy trường hợp libxml2 để nêu bật sự cần thiết của một cấu trúc tài trợ bền vững
15 bình luận
Chắc không đến mức rạn nứt quan hệ như giữa quỹ WordPress và công ty WP Engine đâu nhỉ?
Có vẻ đây là phần tiếp nối của
https://daniel.haxx.se/blog/2024/…
ở trên
Nếu bài viết phía trên là các báo cáo hoàn toàn sai do cá nhân gửi đến để nhắm tiền thưởng bug bounty, thì vụ FFmpeg là các báo cáo hợp lệ nhưng vụn vặt do một tập đoàn lớn gửi đến.
Google chỉ ra thì nhất thiết phải phản hồi sao?
Có vẻ đây là tình huống mà bản thân lỗ hổng đã bị công khai, nên họ buộc phải phản ứng.
À ha... hóa ra còn có góc nhìn đó nữa. Cảm ơn bạn đã cho mình biết!
Đó là chỗ mà sau khi lỗ hổng bị công khai, người ta có thể lợi dụng nó để tấn công nhỉ, ghê thật
Thực ra dù có công khai hay không thì cũng có thể nói kiểu “nếu thấy tiếc thì tự mà sửa đi~”, nhưng có lẽ chính vì những người bảo trì không có kiểu tính cách đó nên dự án mới phát triển được đến mức này.
À ha.... Có lẽ điều bạn nói là đúng.
Có vẻ tôi đã suy nghĩ quá nhiều từ góc nhìn của mình.
Cảm ơn bạn đã nói vậy!
Ý kiến trên Hacker News
Có một đoạn trong bài khiến tôi ấn tượng. Có chuyện Mark Atwood phải giải thích với cấp trên ở Amazon rằng “họ không phải nhà cung cấp, không có NDA, và chúng ta không thể gây ảnh hưởng lên họ” để ngăn một quyết định liên quan đến FFmpeg trong nội bộ.
Tôi đồng ý với câu “đừng chỉ mang vấn đề đến mà hãy mang theo giải pháp”, nhưng tôi nghĩ nếu Google có tiền để tìm lỗi thì cũng có thể bỏ tiền để sửa chúng
Làm vậy sẽ không phải phụ thuộc vào các bản vá riêng tư, có thể đền đáp lại dự án đã giúp mình từ đầu, và về mặt đạo đức cũng là điều đúng đắn.
Nhưng trên thực tế, vấn đề là các rào cản tuân thủ hoặc quy trình trong nội bộ doanh nghiệp khiến việc upstream trở nên khó khăn
Tôi từng tưởng tượng ra một giấy phép mang tính châm biếm: nhân viên của các công ty thuộc S&P500 muốn báo lỗi thì phải quyên góp một khoản tiền nhất định, và nếu không trả trên một mức nào đó thì không thể kỳ vọng nhận được phản hồi trong một khoảng thời gian nhất định.
Khi doanh nghiệp thấy bất tiện, họ đâu ngần ngại chạy phần mềm dưới dạng kín hoặc chuyển sang AGPL, nên giờ đến lúc họ phải tự trả giá trực tiếp
Với tư cách là một người bảo trì mã nguồn mở, tôi đồng cảm với cảm giác rằng các tập đoàn lớn đang ép lao động miễn phí bằng cách công khai các vấn đề bảo mật.
Nhưng trên thực tế, bất kể ai báo cáo thì vấn đề bảo mật cuối cùng vẫn là thứ tôi phải giải quyết.
Dự án không ưu tiên bảo mật cũng không sao, nhưng khi đó phải chấp nhận cả rủi ro về danh tiếng đi kèm
Yêu cầu sửa nhanh với doanh nghiệp thương mại thì hợp lý, nhưng áp cùng yêu cầu đó cho OSS dựa trên tình nguyện viên thì không thực tế
Vấn đề này được nói là chỉ xảy ra ở 10–20 khung hình đầu tiên của một trò chơi từ năm 1995, nên tôi thấy việc xếp nó vào mức ‘nghiêm trọng trung bình’ là hơi quá.
Có vẻ như đây là một ví dụ làm lãng phí thời gian của người bảo trì
Nếu là vấn đề nghiêm trọng thì ai báo cũng tốt, còn nếu là báo cáo vụn vặt hoặc sai thì có thể bỏ qua.
Cuối cùng, chính dự án phải tự quyết định sẽ sửa lỗi nào
Tôi ủng hộ lập trường của nhóm FFmpeg. Nhiều công ty chỉ dùng FOSS để đánh bóng hình ảnh marketing, còn thực tế thì không đóng góp gì.
Trước đây có lẽ họ chỉ việc dùng lậu, còn bây giờ nhờ giấy phép mà có thể sử dụng mà không thấy cắn rứt lương tâm
Việc kiểm thử cả những codec họ không dùng nội bộ là hoàn toàn vì lợi ích công cộng.
Tất nhiên Google có khả năng tài trợ nhiều hơn cho FFmpeg, nhưng tôi không đồng ý với việc đưa tiền trực tiếp cho người bảo trì lần này
Ai cũng có thể tự do dùng, nhưng cũng để ngỏ khả năng bị lạm dụng.
Có người chê GPL 3 là quá tay, nhưng ít nhất nó có ý định ngăn sự bóc lột
Có những người tạo ra phần mềm định hình cả một thời đại miễn phí, và có những công ty dùng nó để rút sạch mọi giá trị.
Một bên vận hành bằng tình yêu, bên kia vận hành bằng giao dịch
Với các tập đoàn lớn thì cần công khai lỗ hổng, nhưng với OSS thiếu nguồn lực thì rủi ro có thể lớn hơn
Nếu Google muốn được sửa nhanh thì hãy gửi kèm bản vá, như vậy mọi bên đều có lợi
Đặc biệt nếu đó là loại lỗ hổng mà LLM có thể tìm ra, thì sớm muộn gì cũng có khả năng bị khai thác.
Nhờ công khai mà người dùng có thể tự phòng vệ, và việc FFmpeg quyết định sửa nó là lựa chọn tự nguyện.
Bản thân nghiên cứu bảo mật là một hình thức đóng góp chi phí cao cho mã nguồn mở.
Nói với nhà nghiên cứu rằng “đóng góp như thế vẫn chưa đủ” thì ngược lại lại thành ra đòi tình nguyện viên làm không công
Tính minh bạch của FOSS ngược lại còn giúp nâng cao nhận thức bảo mật
Nó không chấp nhận những vùng xám của thực tế
Nếu “một email có thể làm dừng ba dòng sản phẩm”, thì tôi nghĩ khoản hỗ trợ 10.000–20.000 USD mỗi năm cũng hoàn toàn đáng như phí bảo hiểm
Chỉ cần Google và Amazon hỗ trợ 50.000 USD mỗi bên thì các nhà phát triển FFmpeg đã có thể làm việc ổn định,
đặc biệt là Google, đơn vị vận hành YouTube, hoàn toàn có thể dễ dàng chi 100.000–200.000 USD
Chia sẻ chuỗi Twitter của lãnh đạo an ninh Google tổng hợp những đóng góp cho FFmpeg
Một công ty trị giá nghìn tỷ USD mà nói thiếu nhân lực hay thiếu tiền thì không thuyết phục
Tôi tò mò mục đích của Project Zero là gì.
Không biết ngoài việc chỉ đi tìm lỗ hổng ra thì còn lý do nào khác không
Đồng thời cũng có lợi cho việc thu hút nhân tài an ninh và quản lý danh tiếng.
Nhưng nếu đã có dư địa như vậy thì cũng nên đầu tư vào việc viết bản vá
Lỗ hổng được nói đến là Use After Free, và AI của Google đã tìm ra nó.
Nhưng để sửa nó thì chắc còn không mất đến 3 giây.
Việc một công ty đầy tiền ném báo cáo lỗi dạng spam vào một dự án tình nguyện thật khó chịu
Nó còn chưa đáng để phân loại thành CVE, chỉ cần là một báo cáo lỗi thông thường là đủ
Để tránh rò rỉ bộ nhớ thì cần một sửa đổi phức tạp hơn.
Có lẽ hướng đúng là để codec này bị vô hiệu hóa theo mặc định
Cho ăn rồi lại còn đòi cả gói nữa nhỉ.
Báo cáo lỗi rõ ràng cũng là một đóng góp quan trọng mà...
Cảm giác như có ai đó tự nguyện đi dọn vệ sinh khu phố, rồi một ông lớn sở hữu nhiều đất nhất trong khu lại bảo với người đang dọn rằng ở góc kia có đầu lọc thuốc lá kìa.
Tôi cũng nghĩ phép so sánh này là phù hợp.
Đây là một phép so sánh thích hợp.
Có đúng là đáng để làm ầm lên không? Đọc kỹ thì đây là một lỗ hổng bảo mật mức trung bình chỉ có hiệu lực trong 10~20 khung hình đầu tiên của một trò chơi cổ điển cụ thể. Bạn thực sự cho rằng đây là một đóng góp quan trọng đối với FFmpeg sao? Tôi nghĩ đóng góp quan trọng nhất cho cộng đồng mã nguồn mở là tài trợ để họ có thể phát triển ổn định; đặc biệt với một công ty đang sử dụng rất tốt thành quả đó, việc ấy có lẽ nên được ưu tiên hơn chứ?
Chính những người như vậy đã khiến XZ bị cài backdoor.
Bản thân các báo cáo lỗi đúng là hạng S, nhưng họ lại đi rêu rao khắp nơi rằng vì không kịp xử lý trong thời hạn một lỗ hổng nghiêm trọng của một định dạng video từ thời Tổng thống Kennedy còn được dùng.
Họ không phải đưa thứ có thể ăn được, mà là đưa thứ buộc phải ăn rồi hỏi tại sao không ăn xong trong thời hạn.
FFmpeg thì nhân lực có hạn, vậy việc Google dùng AI để đổ ra hàng chục báo cáo lỗi về những định dạng giờ thậm chí không còn được dùng nữa, đồng thời gây áp lực phải sửa tất cả trong thời hạn, có đúng đắn không?