Facebook HHVM cho phép giao thức TLS lỗi thời trong stream connection

HHVM 4.172.0 và tất cả các phiên bản trước đó sử dụng TLS 1.0 cho các kết nối bảo mật khi xử lý các URL tls:// trong stream extension. TLS1.0 có nhiều lỗ hổng đã được công bố và đã bị không còn khuyến nghị sử dụng. HHVM 4.153.4, 4.168.2, 4.169.2, 4.170.2, 4.171.1, 4.172.1, 4.173.0 thay thế TLS1.0 bằng TLS1.3. Các ứng dụng gọi các hàm stream_socket_server hoặc stream_socket_client với URL bắt đầu bằng tls:// bị ảnh hưởng.

Mô tả nguồn cho biết HHVM 4.172.0 và tất cả phiên bản trước đó bị ảnh hưởng khi ứng dụng dùng các hàm stream nêu trên với URL tls://.

• Dữ liệu affected có cấu trúc đánh dấu 4.172.0 đến trước 4.172.1, 4.171.0 đến trước 4.171.1, 4.170.0 đến trước 4.170.2 và 4.169.0 đến trước 4.169.2 là bị ảnh hưởng.
• Dữ liệu này cũng đánh dấu các phiên bản thấp hơn 4.153.4 là bị ảnh hưởng và mô tả 4.153.4 là bản sửa.
• Bản ghi cho nhánh bắt đầu từ 4.154.0 chứa lessThan là 1.168.2, một ranh giới không nhất quán với các nhánh còn lại. Phạm vi chính xác của nhánh này vì vậy chưa thể xác định đáng tin cậy từ dữ liệu đã cung cấp.
• Phần mô tả nguồn liệt kê 4.153.4, 4.168.2, 4.169.2, 4.170.2, 4.171.1, 4.172.1 và 4.173.0 là các bản thay thế giao thức cũ. Advisory của nhà cung cấp được kiểm tra trực tiếp chỉ công bố các bản patch 4.153.4, 4.168.2 và 4.172.1, đồng thời không liệt kê cùng toàn bộ các nhánh còn lại. Cần giữ nguyên sự khác biệt này khi đánh giá trạng thái của từng gói.

Facebook HHVM xử lý URL tls:// trong stream extension thông qua các hàm stream_socket_server và stream_socket_client. Trước khi được sửa, đường đi cho client và server chọn các phương thức TLS dành riêng cho phiên bản cũ, cho phép thương lượng giao thức TLS không còn an toàn. Bản vá thay đổi lựa chọn này sang các phương thức TLS chung hơn, còn advisory của nhà cung cấp mô tả kết quả là chỉ cho phép các kết nối TLS mới hơn. Input liên quan là URL bắt đầu bằng tls://; việc attacker có thể kiểm soát URL đó hay không phụ thuộc vào từng ứng dụng và không được xác lập trong bằng chứng hiện có. Phạm vi ảnh hưởng là các ứng dụng gọi những hàm này với scheme tls://, không phải mọi tiến trình HHVM chỉ vì chúng đang chạy HHVM. Các nguồn hiện có không mô tả đầy đủ mọi chi tiết thương lượng TLS ở cấp thư viện sau khi cập nhật.

Đường khai thác nằm ở các kết nối mạng do ứng dụng tạo ra thông qua stream extension. Dữ liệu có cấu trúc trong hồ sơ mô tả điều kiện khai thác là từ xa qua mạng, không yêu cầu xác thực hoặc tương tác của người dùng và có độ phức tạp thấp. Tuy nhiên, khả năng khai thác thực tế còn phụ thuộc vào việc deployment có tạo các kết nối tls:// bị ảnh hưởng hay không và attacker có thể tác động đến đường kết nối hoặc phiên TLS hay không. Hồ sơ được cung cấp đặt public_exploit là false và known_exploited là null; các trường này chỉ mô tả metadata hiện có, không chứng minh rằng chưa từng có khai thác. Không có nguồn được xem xét nào nêu tên exploit công khai, chiến dịch hoặc hoạt động khai thác thực tế.

Lỗ hổng làm cho các kết nối stream có thể sử dụng giao thức TLS cũ với mức bảo vệ yếu hơn. Nếu attacker có thể khai thác các điểm yếu của giao thức hoặc điều kiện của phiên kết nối, tính bí mật và toàn vẹn của dữ liệu truyền có thể bị ảnh hưởng. Hậu quả tổ chức phụ thuộc vào dữ liệu, endpoint và dịch vụ đi qua kết nối; hồ sơ không xác định một đường dẫn riêng dẫn đến nâng quyền hoặc thực thi mã. Không có bằng chứng trong hồ sơ cho thấy đã xảy ra breach hoặc mất tính sẵn sàng của một dịch vụ cụ thể.

Việc cho phép giao thức TLS cũ có thể làm giảm mức bảo vệ cryptographic cho dữ liệu đi qua các kết nối stream của ứng dụng. Tùy vào loại lưu lượng, cấu hình kết nối và khả năng của attacker, hậu quả có thể bao gồm nguy cơ đọc hoặc thay đổi dữ liệu trong phiên truyền thông bị ảnh hưởng. Các ứng dụng xử lý dữ liệu nhạy cảm qua tls:// nên được ưu tiên kiểm tra vì việc nâng cấp có thể ảnh hưởng đến tính bảo mật của các luồng kết nối đó. Bằng chứng hiện có không xác nhận breach, mất dữ liệu thực tế hoặc gián đoạn dịch vụ.

1. Nâng cấp theo nhánh sang một bản patch được advisory của nhà cung cấp công bố rõ ràng: 4.153.4, 4.168.2 hoặc 4.172.1, tùy nhánh đang sử dụng.
2. Với các nhánh mà bản ghi cung cấp liệt kê thêm các bản sửa 4.169.2, 4.170.2, 4.171.1 hoặc 4.173.0, hãy xác minh metadata phát hành và gói thực tế của nhánh tương ứng trước khi coi đó là bản sửa đã được xác nhận bởi nhà cung cấp. Không suy rộng bản sửa của một nhánh sang nhánh khác.
3. Theo mô tả được cung cấp, bản sửa thay thế TLS1.0 bằng TLS1.3; advisory của nhà cung cấp diễn đạt thận trọng hơn là chỉ cho phép các kết nối TLS mới hơn.
4. Nếu chưa thể nâng cấp, bằng chứng hiện có không nêu một workaround hoặc cấu hình giảm thiểu cụ thể do nhà cung cấp khuyến nghị. Do đó, cần ưu tiên lập kế hoạch nâng cấp và xác định mọi ứng dụng còn phụ thuộc vào các lời gọi tls:// bị ảnh hưởng.

1. Kiểm kê phiên bản HHVM đang chạy và đối chiếu với từng nhánh bị ảnh hưởng, thay vì chỉ kiểm tra tên sản phẩm.
2. Rà soát mã nguồn và cấu hình ứng dụng để tìm các lời gọi stream_socket_server hoặc stream_socket_client sử dụng URL bắt đầu bằng tls://.
3. Kiểm tra telemetry của TLS handshake hoặc dữ liệu quan sát trên proxy để xác định các kết nối còn thương lượng giao thức TLS cũ. Đây là biện pháp kiểm tra phòng ngừa, không phải IOC được nhà cung cấp công bố.
4. Xác nhận phiên bản runtime thực tế của các worker, container hoặc host đang xử lý các lời gọi trên; không suy luận trạng thái an toàn chỉ từ phiên bản được khai báo trong manifest.
5. Bằng chứng hiện có không cung cấp log event, đường dẫn file log hoặc IOC cụ thể cho lỗ hổng này. Việc không thấy dấu hiệu như vậy không chứng minh deployment đã an toàn.