Nhiều vấn đề bảo mật được phát hiện trong GNU Screen

 (openwall.com)
2 điểm bởi GN⁺ 2025-05-14 | 1 bình luận | Chia sẻ qua WhatsApp
  • Các lỗ hổng bảo mật nghiêm trọng đã được phát hiện trong GNU Screen 5.0.0 và các bản cài đặt setuid-root
  • Các vấn đề chính gồm leo thang đặc quyền root cục bộ, chiếm quyền TTY, tạo PTY có thể ghi bởi mọi người
  • Nhiều bản phân phối Linux và UNIX bị ảnh hưởng một phần hoặc toàn bộ
  • Đã có bản vá tạm thời và nhiều bản phân phối cần ưu tiên xử lý
  • Bản thân thiết kế setuid-root của Screen có rủi ro bảo mật mang tính nền tảng

1. Giới thiệu

  • Vào tháng 7/2024, việc rà soát bảo mật bắt đầu khi maintainer upstream của Screen yêu cầu review mã
  • Trước đây không phát hiện vấn đề đáng kể nào, nhưng lần này đã tìm thấy lỗ hổng leo thang đặc quyền root nghiêm trọng trong Screen 5.0.0 khi chạy với cấu hình setuid-root
  • Ngoài ra, cũng xác nhận nhiều lỗ hổng bảo mật mức nhẹ ảnh hưởng đến các phiên bản trước đó (4.9.1, v.v.)
  • Báo cáo đính kèm bộ bản vá lỗ hổng theo từng phiên bản (4.9.1, 5.0.0)
  • Nội dung gồm cấu hình và phiên bản Screen theo từng bản phân phối, các lỗ hổng chính, rủi ro phát triển liên quan đến setuid-root, khuyến nghị tăng cường bảo mật, vấn đề trong quá trình điều phối công bố, và ma trận ảnh hưởng

2. Tổng quan cấu hình và phiên bản Screen

  • Tháng 8/2024, Screen 5.0.0 được phát hành và được đưa vào Arch Linux, Fedora 42, NetBSD 10.1
  • Bản 5.0.0 bao gồm rất nhiều đợt refactoring, trong đó một số phần là mã đã tồn tại hơn 10 năm
  • Một số lỗ hổng được đưa vào mới ở 5.0.0, và một số khác cũng tồn tại ở các phiên bản trước (4.9.1, v.v.)
  • Phần lớn các bản phân phối vẫn đang dùng 4.9.1
  • Chế độ đa người dùng của Screen chỉ dùng được khi cài đặt dưới dạng setuid-root, và do độ phức tạp của mã nên làm tăng đáng kể bề mặt tấn công
  • Trong các bản phân phối lớn, Arch Linux, FreeBSD, NetBSD cài Screen dưới dạng setuid-root; Gentoo chỉ có thể cài setuid-root khi dùng USE flag “multiuser”

3. Chi tiết các vấn đề bảo mật

3.a) Giành quyền root cục bộ thông qua logfile_reopen() (CVE-2025-23395)

  • Khi Screen 5.0.0 chạy dưới setuid-root, hàm logfile_reopen() tạo tệp theo đường dẫn do người dùng nhập mà không hạ đặc quyền
  • Kẻ tấn công có thể tạo tệp tùy ý thuộc sở hữu root để ghi và khai thác dữ liệu terminal
  • Ngay cả tệp đã tồn tại cũng có thể bị lợi dụng, ví dụ chèn mã vào shell script có đặc quyền
  • Arch Linux, NetBSD 5.0.0 bị ảnh hưởng hoàn toàn; Fedora và một số môi trường của Gentoo bị ảnh hưởng một phần
  • Bản vá được áp dụng bằng cách khôi phục xử lý tệp an toàn, với mức ảnh hưởng cụ thể khác nhau theo từng bản phân phối

3.b) Chiếm quyền TTY khi kết nối vào phiên đa người dùng (CVE-2025-46802)

  • Trong hàm Attach(), khi bật cờ multiattach, quyền của TTY tạm thời bị đổi thành 0666
  • Trong quá trình này, một race condition cho phép người dùng thứ ba có quyền đọc/ghi vào TTY đó
  • Có nguy cơ nghe lén dữ liệu nhập, sửa đổi dữ liệu, đánh cắp mật khẩu, v.v.
  • Cũng tồn tại các nhánh mã mà quyền TTY không được khôi phục về trạng thái ban đầu
  • Bản vá loại bỏ thao tác chmod 666; dù một số trường hợp tái kết nối có thể bị hỏng, chúng vốn dĩ cũng không hoạt động trước đó

3.c) Lỗ hổng quyền mặc định của PTY (CVE-2025-46803)

  • Trong 5.0.0, quyền mặc định của PTY bị đổi từ 0620 → 0622 (mọi người đều có thể ghi)
  • Mức rủi ro tiềm ẩn về bảo mật tăng lên, đặc biệt vì mọi người dùng đều có thể ghi vào PTY của người khác
  • Thay đổi này có vẻ được đưa vào do nhầm lẫn, và bản vá khắc phục bằng cách khôi phục giá trị mặc định an toàn khi biên dịch (0620)
  • Arch Linux, NetBSD là các đối tượng bị ảnh hưởng chính

3.d) Rò rỉ thông tin về sự tồn tại của tệp qua thông báo lỗi socket (CVE-2025-46804)

  • Có thể dùng biến môi trường SCREENDIR và thông báo Error để kiểm tra sự tồn tại của tệp/thư mục thực tế với đặc quyền root
  • Đây là rò rỉ thông tin mức nhẹ, nhưng mọi môi trường cài đặt setuid-root đều có rủi ro

3.e) Race condition TOCTOU trong việc gửi tín hiệu (CVE-2025-46805)

  • Do độ trễ thời gian giữa các hàm CheckPid() và Kill(), có nguy cơ gửi tín hiệu với quyền root đến PID khác ngoài ý định
  • Chủ yếu chỉ cho phép các tín hiệu như SIGCONT, SIGHUP nên tác động bị giới hạn, nhưng vẫn có thể gây từ chối dịch vụ (DoS) hoặc ảnh hưởng nhẹ đến tính toàn vẹn

3.f) Tràn bộ đệm khi gửi lệnh do dùng strncpy() sai cách

  • Trong 5.0.0, việc dùng strncpy() sai cách gây tràn bộ đệm và làm chương trình crash
  • Nếu không được vá đúng cách, việc gửi lệnh có thể ghi đè bộ nhớ sau MAXPATHLEN và dẫn đến tình trạng dịch vụ không hoạt động
  • Đây không phải vấn đề bảo mật, nhưng cần sửa sớm vì độ ổn định

4. Rủi ro bổ sung liên quan đến triển khai setuid-root

  • Đã xác nhận logic xử lý UID nhiều người dùng trong chế độ multi-user còn yếu
  • Logic hạ đặc quyền ở trạng thái setuid-root là không đầy đủ
  • Trong các phiên do root tạo ra, việc hạ đặc quyền hiệu quả không diễn ra đầy đủ, khiến rủi ro tổng thể tăng cao

5. Khuyến nghị chung để tăng cường bảo mật

  • Trong quá trình refactoring quy mô lớn, đã xác nhận logic bảo mật hiện có bị phá vỡ
  • Do đặc tính của binary setuid-root, cần đưa vào bộ kiểm thử bảo mật và thiết kế bảo thủ cho mọi xử lý liên quan đến filesystem/biến môi trường
  • Đặc biệt không khuyến nghị chạy toàn bộ dưới setuid-root; tính năng multi-user chỉ nên bị giới hạn theo cơ chế opt-in cho nhóm đáng tin cậy
  • Các biến môi trường (PAH, v.v.) bắt buộc phải chỉ được chỉ định bằng đường dẫn đáng tin cậy

6. Các vấn đề trong quá trình điều phối công bố lỗ hổng

  • Quá trình điều phối với upstream diễn ra kém hiệu quả, dẫn đến chậm trễ trong việc phát triển bản vá và công bố
  • Do thiếu hiểu biết và năng lực đối với mã nguồn phía upstream, việc phối hợp chặt chẽ gặp khó khăn
  • Cuối cùng phía các bản phân phối đã chủ động phát triển bản vá, và báo cáo được công bố theo lịch đã điều phối
  • Cũng cho thấy thiếu năng lực duy trì và quản lý của chính dự án Screen

7. Ma trận ảnh hưởng

  • Arch Linux (5.0.0, setuid-root): bị ảnh hưởng bởi toàn bộ các lỗ hổng 3.a, 3.b, 3.c, 3.d, 3.e, 3.f
  • Debian/Ubuntu và nhiều bản phân phối khác: 3.b (ảnh hưởng một phần)
  • Fedora 42 (5.0.0, setgid-screen): 3.b (ảnh hưởng một phần), 3.f
  • Gentoo (4.9.1, setgid-utmp): 3.b (ảnh hưởng một phần), với ebuild unstable + USE flag multiuser thì ảnh hưởng giống 5.0.0
  • FreeBSD 14.2 (4.9.1, setuid-root): bị ảnh hưởng bởi 3.b, 3.d, 3.e
  • NetBSD 10.1 (5.0.0, setuid-root): bị ảnh hưởng bởi 3.a, 3.b, 3.c, 3.d, 3.e, 3.f
  • OpenBSD 7.7 (4.9.1): 3.b (ảnh hưởng một phần)
  • openSUSE TW: 3.b (ảnh hưởng một phần)

8. Lịch trình

  • 2024-07-01: nhận yêu cầu review mã từ upstream
  • 2025-01-08: bắt đầu rà soát
  • 2025-02-07: báo cáo riêng tư các lỗ hổng cho upstream, yêu cầu công bố có điều phối
  • 2025-02~04: thảo luận bản vá, điều chỉnh lại lịch do vấn đề về thời gian embargo
  • 2025-05-12: công bố báo cáo này và thông báo chính thức

9. Liên kết tham khảo

  • GNU Savannah [trang dự án Screen]
  • openSUSE Bugzilla, các bản vá liên quan, các CVE tham khảo, liên kết tới bug report và tài liệu

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-05-14
Ý kiến Hacker News
  • Screen có chế độ đa người dùng cho phép nhiều người cùng truy cập một phiên, tôi nghĩ chính tính năng này giúp các công cụ như tmate có thể tồn tại, cũng tò mò không biết tmux có lỗ hổng tương tự hay không
    • tmux dùng Unix domain socket, không hiểu vì sao screen lại dùng cách setuid, có vẻ không cần quyền root, theo phần mô tả trong bài thì có vẻ các nhà phát triển screen hiện tại chưa nắm hoàn toàn codebase nên đã chọn cách setuid-root vì dễ triển khai tính năng hơn
    • Tính năng này thực sự rất tuyệt, trong các buổi training tôi cho mỗi học viên một tài khoản đăng nhập trên laptop của mình và giới hạn shell ssh bằng screen -x <cửa sổ của người dùng cụ thể> để học viên chỉ có thể dùng những cửa sổ được ACL của screen cho phép, tôi dùng projector để lần lượt kiểm tra và trình chiếu màn hình của từng học viên, nhưng việc nó đầy lỗ hổng bảo mật thì cũng không quá bất ngờ
    • Tôi từng dùng lệnh screen -x
  • Trên Debian, GNU screen không được cài với quyền setuid root
    • Gói Debian Stable (bookworm) quá cũ nên không bị ảnh hưởng bởi lỗ hổng 5.0.0, trước đây tôi từng ghét việc Debian cập nhật phần mềm quá chậm, nhưng giờ thì chỉ dùng nguồn gói riêng cho vài ứng dụng cần thiết để lấy bản mới, còn lại vẫn dùng bản cũ khá ổn
    • Gentoo cũng vậy, nhưng trên Gentoo thì có SETGID cho nhóm utmp, tôi không rõ điều đó có ý nghĩa gì
    • Trên Slackware 15, screen không có suid
    • Có vẻ trên Fedora nó được cài dưới dạng setuid
  • Giới thiệu bản dựng hiển thị của bài blog: https://security.opensuse.org/2025/05/12/screen-security-issues.html
  • Tôi đã gửi email cho tác giả bài viết vì tài liệu về tính năng ghi log của GNU Screen quá thiếu, tôi nghĩ GNU cần một hệ thống theo dõi issue tốt hơn, tài liệu liên quan: http://www.zoobab.com/screenrc
  • observed behaviour đã tồn tại trong Screen từ năm 2005, trong thời gian dài nó được các công cụ như rkhunter xử lý như một phản mẫu, tôi khá chắc screen đã là setuid root từ tận thập niên 90
  • Việc upstream (nhóm phát triển chính thức) lần này có tham gia khiến tôi ngạc nhiên, khoảng 5 năm trước tôi đã buồn vì có vẻ việc phát triển GNU screen hoàn toàn dừng lại, không biết giờ còn vậy không, cũng tò mò liệu có chức năng thêm cửa sổ mới vào screen mà không cần attach vào màn hình hay không
    • upstream là bên đã yêu cầu đội SUSE xem xét, nhân lực phát triển đang thiếu và hiện tại việc bảo trì không được tốt lắm, nếu đúng vậy thì khá đáng tiếc, dù có các lựa chọn thay thế như tmux nhưng nhiều người đã dùng Screen từ rất lâu, thật tiếc cho tình trạng lão hóa của công cụ
    • Việc họ tham gia chỉ là phát hành dưới dạng setuid-root, chỉ các bản phân phối cấu hình như vậy mới bị ảnh hưởng, các bản khác thì không, khi bản vá chính thức chậm thì bản phân phối sẽ tự vá
    • Tôi không nghĩ việc các công cụ GNU ngừng phát triển (trừ sửa lỗi) hoàn toàn là điều xấu, đó có thể là dấu hiệu cho thấy tính năng đã đủ hoàn thiện
    • Vì khó liên lạc với upstream nên tôi không có thông tin chi tiết về các bản sửa lỗi/phát hành, dù đã yêu cầu rà soát bảo mật nhưng có vẻ tình hình liên lạc không dễ dàng
    • Mã nguồn mở có vấn đề quán tính: dù một phần mềm đã hết vòng đời và có công cụ thay thế, vẫn thiếu động lực để chuyển ngay sang cái mới; ngược lại cũng có trường hợp chỉ mua lại thương hiệu rồi biến nó thành thứ hoàn toàn khác (như Audacity), không có giải pháp tốt
  • Liên kết bản hiển thị: https://security.opensuse.org/2025/05/12/screen-security-issues.html
  • Tôi tò mò có bao nhiêu nhà phát triển thực sự tự dùng thử tất cả các công cụ mã nguồn mở phổ biến, và trong các lĩnh vực sử dụng những công cụ đó đang có bao nhiêu tiền được luân chuyển
  • Tôi nhớ tmux đã có trong mặc định của OpenBSD từ bản 4.6 và đã được audit, đây là lựa chọn thay thế tốt cho những ai quan tâm đến bảo mật hơn
    • Việc thấy nhắc đến screen khiến tôi nhớ ngày trước đã chuyển sang tmux, rồi sau đó do không dùng screen nữa nên có lúc bị nhầm lẫn
  • Thú vị là screen và setuid lại được nhắc đến, có lần tôi đã phải chạy chmod u+s cho screen để xử lý một vấn đề kỳ lạ, cảm giác việc phải làm vậy rất khó chịu, nhưng rồi mới biết screen có những tính năng phụ thuộc vào setuid và trên một số hệ thống nó thực sự được phát hành mặc định như vậy, và khi đặt u+s thì screen lại đọc ~/.screenrc của root thay vì ~/.screenrc của tôi (tôi đành chấp nhận như một cách chữa cháy), tôi nghĩ mỗi bản build của screen có thể khác nhau về hỗ trợ setuid
    • setuid vốn dĩ hoạt động như vậy, khi đặt bit đặc biệt trên binary thì nghĩa là nó sẽ luôn chạy với user được chỉ định