GNU Emacs, Gnus và Org mode tin cậy MIME nội tuyến, có thể xử lý nội dung không an toàn

Trong Emacs trước 29.3, Gnus coi nội dung MIME nội tuyến là đáng tin cậy.

• GNU Emacs: NVD liệt kê các phiên bản bị ảnh hưởng là trước 29.3.
• GNU Org mode: NVD liệt kê các phiên bản bị ảnh hưởng là trước 9.6.23. Thảo luận của dự án cho biết Org mode bên ngoài cần có thay đổi tương ứng với phần sửa trong Emacs.
• Debian GNU/Linux 10.0: Được liệt kê là bị ảnh hưởng. Debian LTS công bố bản sửa trong gói emacs 1:26.1+1-3.2+deb10u5.
• Các gói Debian có bản sửa được xác nhận: Nhánh bullseye có bản emacs 1:27.1+1-3.1+deb11u3; nhánh bookworm có bản emacs 1:28.2+1-15+deb12u1; bookworm-backports có bản emacs 1:29.3+1-2~bpo12+1.
• Org mode trên Debian buster: Bản 9.1.14+dfsg-3+deb10u2 được công bố là đã sửa và yêu cầu gói Emacs 1:26.1+1-3.2+deb10u5 để có đầy đủ thay đổi.

Tại ranh giới xử lý bị ảnh hưởng, Gnus hiển thị nội dung MIME nội tuyến nhưng trước chuỗi bản vá chưa đánh dấu nội dung đó là không đáng tin cậy. Thảo luận về bản vá Emacs xác định lisp/gnus/mm-view.el, cụ thể là mm-display-inline-fontify, là nơi nội dung được đánh dấu không đáng tin cậy; biến untrusted-content trong lisp/files.el và cơ chế bảo vệ xem trước LaTeX của Org mode là các thay đổi liên quan. Đầu vào có thể đến từ nội dung hoặc tệp đính kèm trong email. Thảo luận của dự án nêu Gnus và các MUA tái sử dụng thư viện Gnus, trong đó có notmuch và mu4e; rmail không được cho là bị ảnh hưởng, nhưng nhận định này có điều kiện và không phải một loại trừ tuyệt đối. Mô hình đánh giá giả định người dùng cục bộ phải tương tác với nội dung, và hồ sơ không cho thấy đây là một dịch vụ mạng từ xa không cần xác thực. Một maintainer của dự án cho biết commit Gnus được liên kết với bản ghi này không đủ để tự mình hoàn tất việc sửa lỗi; Org mode bên ngoài cũng cần thay đổi tương ứng, vì vậy đường thực thi dễ bị khai thác và ranh giới bản vá hoàn chỉnh vẫn có điểm chưa chắc chắn.

• Khả năng tiếp cận: Việc khai thác cần xảy ra trong phiên sử dụng Emacs với Gnus hoặc MUA tái sử dụng thư viện Gnus, khi nội dung MIME hoặc email được xử lý.
• Xác thực và đặc quyền: Mô hình đánh giá không yêu cầu đặc quyền trước hoặc xác thực riêng cho thao tác xử lý nội dung.
• Tương tác người dùng: Người dùng phải mở, hiển thị hoặc xử lý nội dung liên quan.
• Độ phức tạp: Hồ sơ đánh giá mô tả độ phức tạp thấp.
• Trạng thái khai thác: Bản ghi được cung cấp đánh dấu public_exploit là false và known_exploited là chưa xác định. Đây là dữ liệu trạng thái của bản ghi, không phải bằng chứng rằng lỗi chưa từng bị khai thác. Các nguồn đã xem không nêu tên exploit, chiến dịch, nạn nhân hoặc sự cố cụ thể.

Kết quả kỹ thuật có thể là nội dung email được đưa vào cơ chế xử lý vốn dành cho dữ liệu tin cậy, với khả năng kích hoạt xử lý không an toàn. Các thảo luận của dự án mô tả hai loại hậu quả liên quan trong chuỗi thay đổi: thực thi mã trong một đường xử lý và làm cạn kiệt dung lượng đĩa trong đường xử lý LaTeX; tuy nhiên phạm vi chính xác của bản ghi này vẫn bị tranh luận. Mô hình đánh giá giả định không cần đặc quyền trước, cần tương tác người dùng và giữ nguyên phạm vi ảnh hưởng. Tác động được đánh giá chủ yếu là mất tính sẵn sàng, trong khi không xác định tác động đến tính bí mật hoặc toàn vẹn. Không có bằng chứng trong hồ sơ cho thấy lỗi này tự động dẫn đến leo thang đặc quyền hoặc ảnh hưởng sang hệ thống khác.

Nội dung email hoặc MIME được tạo dựng có thể được xử lý với mức tin cậy cao hơn dự kiến trong quy trình đọc thư. Thảo luận của dự án liên hệ chuỗi thay đổi với việc xử lý có thể dẫn tới thực thi mã hoặc làm cạn kiệt dung lượng đĩa, nhưng không cung cấp một kịch bản khai thác đã được xác thực riêng cho bản ghi này. Hệ quả vận hành thực tế có thể là Emacs hoặc MUA bị treo, tiêu thụ tài nguyên, từ chối dịch vụ cục bộ hoặc buộc người dùng phải khởi động lại quy trình làm việc. Đánh giá được cung cấp tập trung vào tác động sẵn sàng và không xác định tác động đến tính bí mật hoặc toàn vẹn. Không có tên chiến dịch, nạn nhân hoặc vụ xâm nhập cụ thể nào được nêu trong bằng chứng đã xem.

1. Nâng cấp GNU Emacs lên 29.3, là bản upstream được hồ sơ xác định là mốc sửa cho các phiên bản trước đó.
2. Nếu triển khai Org mode bên ngoài Emacs, nâng cấp lên 9.6.23 và bảo đảm cả phần sửa của Org mode lẫn phần sửa của Emacs đều được cài đặt. Một bản sửa ở chỉ một phía không chứng minh rằng toàn bộ đường xử lý đã được bảo vệ.
3. Với Debian, cài đúng gói đã sửa cho nhánh đang sử dụng: buster dùng 1:26.1+1-3.2+deb10u5; bullseye dùng 1:27.1+1-3.1+deb11u3; bookworm dùng 1:28.2+1-15+deb12u1; bookworm-backports dùng 1:29.3+1-2~bpo12+1. Với gói Org mode trên buster, dùng 9.1.14+dfsg-3+deb10u2 cùng với gói Emacs tương ứng.
4. Nếu chưa thể cập nhật, ưu tiên sử dụng cơ chế hỏi người dùng đối với tài nguyên không an toàn khi cơ chế này đã được đưa vào bản backport của nhà phân phối. Bằng chứng đã xem không xác nhận một workaround cấu hình chung có thể thay thế cho việc cập nhật.
5. Không suy ra trạng thái an toàn của các nhánh song song hoặc bản phát hành khác chỉ từ một mốc sửa ở nhánh nêu trên; tiếp tục đối chiếu trạng thái gói của nhà phân phối.

1. Kiểm kê phiên bản GNU Emacs và Org mode trên các máy dùng để đọc email, sau đó đối chiếu từng nhánh với các mốc bị ảnh hưởng và bản sửa trong affected_summary.
2. Xác định các máy đang bật Gnus hoặc MUA tái sử dụng thư viện Gnus, đặc biệt là notmuch và mu4e. Việc không phát hiện rmail không đủ để kết luận hệ thống an toàn.
3. Kiểm tra quy trình xử lý email có hiển thị MIME nội tuyến hoặc kích hoạt xem trước LaTeX hay không, vì đây là các đường xử lý được thảo luận trong nguồn kỹ thuật.
4. Rà soát nhật ký và telemetry để tìm các lần Emacs tạo tiến trình xử lý LaTeX bất thường, tăng sử dụng đĩa, treo hoặc hết tài nguyên trong lúc hiển thị thư. Đây là biện pháp giám sát phòng ngừa, không phải IOC đã được xác nhận.
5. Đối chiếu changelog của gói phân phối với đúng bản sửa tương ứng. Không dùng việc thiếu log hoặc không thấy hành vi bất thường để kết luận rằng hệ thống không bị ảnh hưởng.