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
  • Đợt rà soát bảo mật GNU Screen đã xác nhận các vấn đề như leo thang đặc quyền cục bộ, chiếm quyền TTY, lộ thông tin, điều kiện tranh chấp khi gửi tín hiệu và crash khi gửi lệnh, tập trung vào Screen 5.0.0 và các bản cài đặt setuid-root
  • Lỗ hổng nghiêm trọng nhất, CVE-2025-23395, nằm ở việc logfile_reopen() xử lý đường dẫn do người dùng cung cấp với quyền root, cho phép tạo file thuộc sở hữu root ở vị trí tùy ý hoặc ghi nối log vào file hiện có
  • Hành vi cũ của chế độ nhiều người dùng cũng bộc lộ vấn đề: Attach() tạm thời đổi TTY sang 0666, tạo khả năng người dùng khác đọc/ghi và chèn input
  • Mức độ rủi ro theo từng bản phân phối phụ thuộc vào cách cài đặt; Arch Linux và NetBSD 10.1 cung cấp Screen 5.0.0 dưới dạng setuid-root nên chịu ảnh hưởng lớn từ các lỗ hổng chính
  • Khuyến nghị hiện tại là không cài Screen dưới dạng setuid-root; tính năng nhiều người dùng cần opt-in dựa trên nhóm tin cậy, hạ quyền mặc định, nâng quyền có giới hạn và dọn dẹp biến môi trường

Bối cảnh công bố và bản vá

  • Tháng 7/2024, maintainer upstream của Screen yêu cầu rà soát codebase hiện tại, và việc rà soát bảo mật thực tế bắt đầu vào tháng 1/2025
  • Kết quả rà soát phát hiện một exploit root cục bộ trong bản cập nhật lớn Screen 5.0.0, ảnh hưởng đến các bản phân phối dùng setuid-root
  • Ngoài ra còn phát hiện các vấn đề có mức độ nghiêm trọng thấp hơn; một số cũng ảnh hưởng đến Screen 4.9.1 và các phiên bản cũ hơn vẫn còn trong nhiều bản phân phối
  • Các vấn đề được chia sẻ lên mailing list distros vào ngày 30/4/2025 và được công bố ngày 12/5/2025
  • Báo cáo có đính kèm các gói bản vá theo phiên bản

Cấu hình Screen và chế độ nhiều người dùng

  • Screen 5.0.0 được upstream phát hành dưới dạng bản phát hành lớn vào tháng 8/2024; Arch Linux, Fedora 42 và NetBSD 10.1 cung cấp phiên bản này
  • Nhiều bản phân phối Linux và UNIX vẫn dùng Screen 4.9.1 tại thời điểm viết
  • Chế độ nhiều người dùng của Screen cho phép attach vào phiên Screen do người dùng khác sở hữu khi có thông tin xác thực phù hợp
    • Tính năng này chỉ dùng được khi Screen được cài với bit setuid-root
    • Vì phần code Screen phức tạp chạy với quyền root, bề mặt tấn công tăng lên
  • Trong các hệ thống được rà soát, Arch Linux, FreeBSD và NetBSD cài Screen dưới dạng setuid-root
  • Gentoo Linux áp dụng bit setuid-root khi cờ USE "multiuser" được bật
  • Một số bản phân phối dùng setgid thay cho setuid
    • Mặc định của Gentoo Linux là setgid-utmp, cho phép Screen tạo bản ghi đăng nhập trong cơ sở dữ liệu utmp toàn hệ thống
    • Fedora Linux dùng setgid-screen, cho phép Screen đặt socket trong thư mục toàn hệ thống /run/screen

CVE-2025-23395: exploit root cục bộ trong logfile_reopen()

  • CVE-2025-23395 ảnh hưởng khi Screen 5.0.0 chạy với quyền setuid-root
  • Hàm logfile_reopen() không hạ quyền khi xử lý đường dẫn do người dùng cung cấp
  • Người dùng không có đặc quyền có thể tạo file ở vị trí tùy ý với các thuộc tính sau
    • Chủ sở hữu: root
    • Nhóm: nhóm thực của người dùng gọi
    • Chế độ file: 0644
  • File đã tồn tại cũng có thể bị khai thác
    • Dữ liệu ghi vào Screen PTY sẽ được append vào file đó
    • Mode và quyền sở hữu của file hiện có không bị thay đổi
  • Screen hạ quyền đúng cách khi mở log file lần đầu, nhưng khả năng leo thang đặc quyền xuất hiện vào thời điểm nó quyết định cần mở lại log file
  • Trong kiểm tra stolen_logfile(), nếu link count của log file ban đầu trở về 0 hoặc kích thước thay đổi ngoài dự kiến, logfile_reopen() sẽ được gọi
  • Điều kiện này có thể được người dùng không có đặc quyền cố ý kích hoạt
  • Patch 0001 cho Screen 5.0.0 đưa lại cách xử lý file an toàn trong quá trình reopen log file
  • Vấn đề này phát sinh từ commit cũ 441bca708bd, nơi lf_secreopen() bị loại bỏ, và thay đổi đó được đưa vào bản phát hành 5.0.0

CVE-2025-46802: chiếm quyền TTY khi attach phiên nhiều người dùng

  • CVE-2025-46802 xảy ra trong hàm Attach() khi cờ multiattach được bật
  • Khi attach vào phiên nhiều người dùng, Screen dùng chmod() để đổi mode của TTY hiện tại thành 0666
  • Đường dẫn TTY được kiểm tra bằng các điều kiện như có nằm dưới /dev hay không và isatty(), nên riêng hành vi này không tạo thành một exploit root cục bộ độc lập
  • Vấn đề là trong thời gian quyền TTY tạm thời được nới lỏng, một điều kiện tranh chấp xuất hiện khiến người dùng khác có thể đọc và ghi TTY đó
  • Trong thử nghiệm đơn giản dựa trên API inotify của Linux, một script Python có thể mở TTY bị ảnh hưởng sau mỗi hai hoặc ba lần thử
  • Kẻ tấn công có thể làm các việc sau
    • Chặn dữ liệu được nhập vào TTY
    • Chèn dữ liệu vào TTY
    • Đánh lừa người dùng nhập mật khẩu
    • Chèn control sequence để gây nhầm lẫn cho nạn nhân hoặc nhắm vào các vấn đề liên quan trong terminal emulator
  • Ở một số đường return của Attach(), mode TTY ban đầu không được khôi phục
    • Ví dụ: không tìm thấy phiên đích và đối số "quiet" được đặt
  • Bản vá loại bỏ thao tác chmod() tạm thời
    • Patch 0001 cho Screen 4.9.1
    • Patch 0004 cho Screen 5.0.0
  • Ngay trước khi công bố, có xác nhận rằng bản vá này có thể phá vỡ một số trường hợp reattach, nhưng những trường hợp đó cũng đã bị lỗi trong Screen 4.9.1
  • Vấn đề này tồn tại trong các phiên bản Screen ít nhất từ năm 2005 và ảnh hưởng đến các bản phân phối Linux cũng như BSD cung cấp hỗ trợ nhiều người dùng bằng setuid-root
  • Ngay cả khi không dùng setuid-root, về lý thuyết vẫn có ảnh hưởng vì người dùng có quyền đổi mode TTY của chính mình, nhưng Screen không tiếp tục vào phiên của người dùng khác nếu không có quyền root

CVE-2025-46803: giá trị mặc định PTY world-writable trong Screen 5.0.0

  • CVE-2025-46803 là vấn đề trong Screen 5.0.0 khi mode mặc định của PTY do Screen cấp phát đổi từ 0620 sang 0622
  • Với giá trị mặc định này, bất kỳ ai trong hệ thống cũng có thể ghi vào Screen PTY
  • Về bảo mật, vấn đề tương tự CVE-2025-46802, nhưng không bao gồm khía cạnh rò rỉ thông tin
  • Trong Screen 4.9.1, giá trị mặc định ở mức code là 0622, nhưng giá trị mặc định 0620 của cấu hình autotools được áp dụng, nên giá trị mặc định an toàn được sử dụng
  • Trong Screen 5.0.0, configure.ac được viết lại làm mất giá trị mặc định 0620 ở cấp autoconf, sau đó công tắc configure pty-mode được đưa lại với mặc định 0622
  • Không xác nhận được release note của 5.0.0 và chỉ có một số mục trong ChangeLog; thay đổi mode mặc định của PTY dường như không phải là quyết định có chủ ý
  • Patch 0002 cho Screen 5.0.0 khôi phục mode PTY mặc định an toàn trong configure.ac
    • Cần chạy autoreconf để áp dụng thay đổi
  • Các packager được khuyến nghị truyền rõ công tắc configure --with-pty-mode=0620
  • Gentoo Linux và Fedora Linux truyền rõ --with-pty-mode an toàn
  • Arch Linux và NetBSD không truyền công tắc này nên nhận giá trị mặc định mới và bị ảnh hưởng

CVE-2025-46804: lộ sự tồn tại của file qua thông báo lỗi đường dẫn socket

  • CVE-2025-46804 là rò rỉ thông tin mức nhẹ xảy ra khi Screen chạy với quyền setuid-root
  • Được xác nhận trong cả các phiên bản Screen cũ hơn và 5.0.0
  • Screen kiểm tra SocketPath với quyền root và làm lộ thông tin đường dẫn mà người dùng không đặc quyền thường không biết được qua thông báo lỗi
  • Khi dùng biến môi trường SCREENDIR, có thể suy luận các thông tin sau
    • /root/.lesshst có phải file thường hay không
    • Thư mục /root/.cache có tồn tại hay không
    • Đường dẫn /root/test có không tồn tại hay không
  • Bản vá thay đổi để trong bản cài setuid-root, khi đường dẫn đích không do UID thực của tiến trình kiểm soát, chỉ hiển thị thông báo lỗi chung
    • Patch 0002 cho Screen 4.9.1
    • Patch 0005 cho Screen 5.0.0
  • Tất cả bản phân phối được rà soát đều bị ảnh hưởng

CVE-2025-46805: điều kiện tranh chấp TOCTOU khi gửi tín hiệu

  • CVE-2025-46805 là điều kiện tranh chấp TOCTOU phát sinh khi gửi tín hiệu tới PID do người dùng cung cấp trong ngữ cảnh setuid-root
  • CheckPid() hạ quyền xuống ID người dùng thực rồi kiểm tra liệu kernel có cho phép gửi tín hiệu tới PID đích hay không
  • Tín hiệu thực tế được gửi sau đó qua Kill(), và lúc này có thể sử dụng quyền root
  • Giữa bước kiểm tra và bước gửi thực tế, PID đã được kiểm tra trước đó có thể bị thay thế bằng một privileged process khác
  • Cũng có khả năng đánh lừa tiến trình daemon Screen đặc quyền gửi tín hiệu cho chính nó
  • Hiện tại chỉ có thể gửi SIGCONT và SIGHUP, nên tác động nhiều khả năng nằm trong phạm vi từ chối dịch vụ cục bộ hoặc xâm phạm tính toàn vẹn ở mức nhẹ
  • Vấn đề này bắt nguồn từ bản sửa chưa hoàn chỉnh của CVE-2023-24626
    • Trước bản sửa đó, các tín hiệu tương ứng có thể được gửi đến tiến trình tùy ý mà không cần điều kiện tranh chấp
  • Bản vá thay đổi để tín hiệu thực tế cũng được gửi với quyền UID thực như CheckPid()
    • Patch 0003 cho Screen 4.9.1
    • Patch 0006 cho Screen 5.0.0
  • Tất cả bản phân phối được rà soát đều bị ảnh hưởng

Crash khi gửi lệnh do sử dụng strncpy() trong Screen 5.0.0

  • Screen 5.0.0 có một vấn đề liên quan đến strncpy() không được xem là vấn đề bảo mật, nhưng cần ưu tiên sửa
  • Trong commit 0dc67256, nhiều lời gọi strcpy() được thay bằng strncpy()
  • strncpy() không phải là hàm xử lý chuỗi an toàn, mà là hàm padding buffer độ dài cố định bằng số 0; vì vậy nó ghi số 0 đến hết buffer đích ngay cả sau byte \0 đầu tiên
  • Trong vòng lặp xử lý đối số dòng lệnh của attacher.c, sau lần lặp đầu tiên vẫn truyền MAXPATHLEN làm kích thước đích
  • Vì con trỏ p đã tăng nhưng vẫn truyền cùng kích thước, các lời gọi strncpy() sau đó sẽ ghi byte \0 vượt quá cuối buffer
  • Trên Arch Linux, khi gửi hơn một đối số lệnh tới phiên Screen đang chạy, lỗi sau được quan sát trong bản build bật _FORTIFY_SOURCE
    • *** buffer overflow detected***: terminated
    • Aborted (core dumped)
  • Nếu không có _FORTIFY_SOURCE, có thể không có lỗi thấy được, và -fsanitize=address cũng có thể không hiển thị lỗi
  • Người gọi có thể ghi đè bằng số 0 lên MAXPATHLEN byte sau buffer cmd, nhưng vì ngay sau đó có buffer writeback[MAXPATHLEN] cùng kích thước, khả năng khai thác có lợi cho kẻ tấn công được đánh giá là không có
  • Patch 0003 cho Screen 5.0.0 thay strncpy() bằng snprintf() và truyền chính xác kích thước buffer đích còn lại
  • Tất cả bản phân phối cung cấp Screen 5.0.0 đều bị ảnh hưởng

Phạm vi ảnh hưởng theo bản phân phối

Hệ thống Phiên bản Screen Đặc quyền đặc biệt Ảnh hưởng
Arch Linux 5.0.0 setuid-root 3.a, 3.b, 3.c, 3.d, 3.e, 3.f
Debian 12.10 4.9.0 Không có một phần 3.b
Ubuntu 24.04.2 4.9.1 Không có một phần 3.b
Fedora 42 5.0.0 setgid-screen một phần 3.b, 3.f
Gentoo 4.9.1 setgid-utmp, setuid-root khi cờ USE multiuser được bật một phần 3.b
openSUSE TW 4.9.1 Không có một phần 3.b
FreeBSD 14.2 4.9.1 setuid-root 3.b, 3.d, 3.e
NetBSD 10.1 5.0.0 setuid-root 3.a, 3.b, 3.c, 3.d, 3.e, 3.f
OpenBSD 7.7 4.9.1 Không có một phần 3.b

Lo ngại và khuyến nghị về thiết kế setuid-root

  • Chế độ nhiều người dùng của Screen liên quan đến ba UID
    • effective UID 0 cho privileged operation
    • UID thực của người dùng tạo phiên
    • UID thực của người dùng attach vào phiên
  • Code Screen hiện tại có vẻ có cấu trúc khó phản ánh đúng sự phân biệt này
  • Phiên nhiều người dùng Screen do root tạo sẽ “hạ quyền” xuống UID thực 0 của người tạo phiên, nên về thực chất không hề hạ quyền
  • Trong quá trình refactor Screen 5.0.0, logic bảo mật tồn tại lâu năm đã bị phá vỡ, dẫn đến CVE-2025-23395 và CVE-2025-46803
  • Trước khi refactor thêm, cần có test suite có thể xác minh các thuộc tính bảo mật của triển khai
  • Nhà phát triển xử lý binary setuid-root cần hiểu rủi ro của khu vực này
  • Screen tiếp tục chạy với quyền nâng cao rồi chỉ hạ quyền có chọn lọc ở các thao tác được xem là nguy hiểm
  • Một chương trình setuid-root vững chắc nên mặc định hạ quyền và chỉ nâng quyền ở những thao tác thực sự cần quyền nâng cao
  • Trong ngữ cảnh setuid-root, cần có logic chỉ giữ lại các biến môi trường được cho phép rõ ràng và loại bỏ phần còn lại
  • Các biến môi trường như PATH cần được dọn dẹp để chỉ trỏ tới các thư mục hệ thống đáng tin cậy
  • Hiện tại, khuyến nghị là không cài dưới dạng setuid-root không chỉ Screen 5.0.0 mà cả nhánh 4.9 cũ hơn
  • Một phương án thay thế là cung cấp tính năng nhiều người dùng theo kiểu opt-in và chỉ cho thành viên của nhóm tin cậy chạy phiên bản Screen hỗ trợ nhiều người dùng

Quá trình điều phối công bố và trạng thái upstream

  • Tháng 2/2025, các vấn đề được báo cáo riêng cho upstream Screen và đề xuất công bố có điều phối
  • Upstream bày tỏ mong muốn giữ kín các vấn đề trước khi công bố để sửa lỗi và cho biết cần 1–2 tháng
  • Khoảng một tháng sau, hoạt động và thảo luận bản vá từ phía upstream bắt đầu, nhưng cuộc thảo luận không đủ hiệu quả
  • Đến khi gần hết thời hạn embargo tối đa 90 ngày, không có thêm trao đổi; trong thời gian đó, các bản phân phối như NetBSD đã cập nhật lên Screen 5.0.0 và trở nên bị ảnh hưởng hoàn toàn bởi CVE-2025-23395
  • Có đánh giá rằng upstream chưa đủ quen với codebase Screen và chưa hiểu đầy đủ các vấn đề bảo mật được báo cáo
  • Upstream muốn công bố sớm hơn trong khi một số vấn đề vẫn chưa được xử lý, nên bản nháp được chuyển nhanh tới mailing list distros
  • Sau đó, phía SUSE trực tiếp phát triển các bản sửa còn thiếu, đồng thời điều chỉnh và tài liệu hóa các bản vá đã được thảo luận ở dạng nháp với upstream
  • Nếu có năng lực upstream chuyên trách, quy trình công bố có điều phối được cho là có thể hoàn tất trong khoảng 2 tuần
  • Upstream của Screen dường như thiếu nhân lực và chuyên môn, điều này đáng lo ngại vì đây là một tiện ích mã nguồn mở được dùng rộng rãi

Mốc thời gian chính

  • 2024-07-01: Nhận yêu cầu rà soát từ upstream
  • 2025-01-08: Bắt đầu công việc rà soát bảo mật
  • 2025-02-07: Báo cáo riêng cho upstream Screen và đề xuất công bố có điều phối
  • 2025-02-11: Tạo bug riêng tư trên bug tracker GNU Savannah
  • 2025-04-30: Quyết định gán CVE và chia sẻ bản nháp lên mailing list distros
  • 2025-05-07: Chia sẻ bản vá hoàn chỉnh cho Screen 4.9.1 và 5.0.0 lên mailing list distros và upstream
  • 2025-05-12: Báo cáo được công bố trên blog và mailing list oss-security

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-05-14
Ý kiến trên Hacker News

  • Tôi không biết Screen có chế độ đa người dùng như vậy, nhưng có lẽ chính tính năng này là lý do các công cụ như tmate có thể hoạt động
    Nghe nói nếu có thông tin xác thực phù hợp, bạn có thể gắn vào một phiên Screen do người dùng khác sở hữu, và tính năng này chỉ khả dụng khi Screen được cài dưới dạng setuid-root
    Vì vậy tôi bắt đầu tự hỏi liệu tmux có bị ảnh hưởng bởi cùng loại lỗ hổng hay không

    • tmux dùng Unix domain socket, nên không liên quan
      Tôi không biết vì sao screen lại chọn cách setuid ở đây; trông có vẻ hoàn toàn không cần quyền root
      Ở phần dưới bài viết có một lời giải thích khá hợp lý rằng các nhà phát triển screen hiện tại không hoàn toàn quen thuộc với codebase; nếu vậy, có thể setuid-root là cách dễ nhất để làm cho tính năng này hoạt động
    • Đây là một tính năng khá tuyệt
      Trong một buổi đào tạo, tôi từng cấp cho mỗi học viên một tài khoản đăng nhập trên laptop của mình, giới hạn shell SSH ở screen -x, rồi dùng danh sách kiểm soát truy cập của screen để mỗi học viên chỉ dùng được cửa sổ của họ
      Trong lúc thực hành, với tư cách là chủ sở hữu screen, tôi có thể đưa màn hình của từng học viên lên máy chiếu để cả lớp xem kết quả
      Nếu có nhiều lỗ hổng bảo mật thì tôi cũng không ngạc nhiên
    • Đúng, screen -x

  • Trên Debian, GNU screen không được cài với quyền setuid-root

    • Gói trong Debian Stable, tức bookworm, quá cũ nên không bị ảnh hưởng bởi lỗ hổng 5.0.0
      Trước đây tôi luôn không thích việc Debian thường tụt hậu về phiên bản phần mềm, nhưng giờ thì ngoài vài ứng dụng như trình duyệt, nơi tôi thật sự không muốn phụ thuộc vào phần mềm quá cũ và dùng nguồn gói khác, còn lại tôi vẫn ổn với các gói cũ
    • Trên Slackware 15, /usr/bin/screen trỏ tới screen-4.9.0, và file thực thi cũng không có suid
    • Gentoo cũng vậy
      Tuy nhiên trên Gentoo, nó có SETGID cho nhóm utmp, nhưng tôi không rõ tác động của việc đó là gì
    • Trên Fedora thì có vẻ là setuid-root

  • Bài blog đã render nằm ở đây: https://security.opensuse.org/2025/05/12/screen-security-iss...

  • Tôi từng gửi email cho tác giả GNU Screen về việc tính năng ghi log ra file không được tài liệu hóa đầy đủ: http://www.zoobab.com/screenrc
    GNU cần một hệ thống theo dõi issue tốt hơn

    • Từng có một phần Q&A với tác giả Tmux, và khoảng 16 năm trước ông ấy cũng đã phàn nàn về thiếu tài liệu
      https://undeadly.org/cgi?action=article&sid=20090712190402
    • Việc này được tài liệu hóa chi tiết trong manual của GNU screen: https://www.gnu.org/software/screen/manual/screen.html#Log
    • Rất nhiều dự án cũ gặp vấn đề là các issue bị chôn vùi trong chiều sâu vô tận của các mailing list không được lập chỉ mục
      Việc Discord bị chỉ trích vì khiến những thông tin như vậy không thể truy cập được là hợp lý, nhưng IRC mà một số dự án vẫn dùng thực ra còn tệ hơn thế gấp đôi
      Tôi mong các dự án như vậy chuyển sang những nơi như Gitea, Forgejo, Codeberg, GitLab, GitHub để gom nội dung liên quan lại một chỗ và bảo đảm khả năng được tìm thấy

  • Zellij là một lựa chọn thay thế hiện đại khá tốt cho screen và tmux, có mặc định rất ổn và UI được thiết kế để dễ khám phá
    Tôi khuyên dùng cho những ai từng thấy lợi ích so với công sức bỏ ra của terminal multiplexer là chưa rõ ràng
    https://zellij.dev
    https://github.com/zellij-org/zellij

    • Tôi đã thử vài năm trước và thấy khá mượt
      Nhưng so với tmux thì độ trễ khá dễ nhận thấy, nên tôi vẫn tiếp tục dùng tmux
      Khi đó tôi vốn đã dùng một kết nối có độ trễ, nên có lẽ tôi cũng hơi nhạy cảm
    • Lần cuối tôi xem Zellij, nó trông như một dự án mới rất hay trong hệ sinh thái multiplexer, nhưng không hỗ trợ cơ chế copy/paste hoàn toàn bằng bàn phím
      Tôi dùng tính năng đó rất nhiều nên không thể thiếu, và cho đến khi nó được thêm vào thì tôi đành phải dùng tmux
    • Hay thì hay, nhưng tôi thật sự thích screen và các lệnh đã ăn sâu vào trí nhớ cơ bắp của tôi
      Tôi đã dùng nó hơn 20 năm

  • Tôi ngạc nhiên là upstream có tham gia vào chuyện này
    Khoảng 5 năm trước tôi đã buồn bã kết luận rằng việc phát triển GNU screen đã dừng hẳn, nên giờ tự hỏi không biết có còn như vậy không
    Tôi không biết screen vẫn còn tính năng thêm cửa sổ mới mà không gắn vào screen hiện có hay không

    • Upstream đã yêu cầu đội SUSE xem xét
      Có vẻ họ thiếu nhân lực phát triển, và upstream có thể không có đủ chuyên môn để bảo trì đúng cách
      Nếu đúng vậy thì thật đáng buồn. Tôi biết có tmux và các lựa chọn thay thế khác, nhưng rất nhiều người đã dùng Screen trong thời gian rất dài, và thật đáng tiếc khi thấy một công cụ dần mục ruỗng
    • Bài viết nói rằng do khó giao tiếp với upstream nên hiện họ không có thông tin chi tiết về các bản sửa lỗi và bản phát hành phía upstream đã đưa ra
      Có vẻ họ đã yêu cầu rà soát bảo mật nhưng khó duy trì liên lạc, còn toàn bộ tình hình thì tôi không rõ
    • Tham gia ở đây cũng chỉ đến mức phân phối nó dưới dạng setuid-root
      Bản phân phối nào cấu hình như vậy thì dễ bị tấn công, bản nào không thì không
      Tôi xem đó là mức tham gia rất nông. Nếu upstream quá chậm, bản phân phối sẽ tự vá
    • Việc phát triển công cụ GNU dừng lại không nhất thiết là chuyện buồn. Tất nhiên là ngoại trừ sửa lỗi
      Về cơ bản có thể xem đó là dấu hiệu của một công cụ đã hoàn thiện
    • Trong mã nguồn mở có vấn đề quán tính khi một phần mềm kết thúc và phần mềm khác được tạo ra để thay thế nó
      Không có động lực để chuyển ngay, vì đó không phải là cập nhật mà là chuyển đổi
      Ngược lại, việc ai đó mua nhãn hiệu của phần mềm cũ rồi biến nó thành thứ hoàn toàn khác như trường hợp Audacity cũng tệ
      Vì vậy có vẻ không có giải pháp tốt

  • Bản đã render: https://security.opensuse.org/2025/05/12/screen-security-iss...

  • Nếu tôi nhớ đúng, tmux đã được đưa vào hệ thống cơ sở từ OpenBSD 4.6 và là công cụ đã được, hoặc vẫn đang được, audit
    Đây là lựa chọn tốt cho những ai muốn một phương án an toàn hơn một chút

    • Thấy screen xuất hiện lại khiến tôi nhớ tới thời mình từng chuyển sang tmux rồi quên mất screen

  • Hành vi được quan sát đã tồn tại trong các phiên bản Screen ít nhất từ năm 2005, và từ lâu như vậy nó đã là một anti-pattern; các công cụ như rkhunter cũng đã xử lý vấn đề này
    Dù vậy, tôi nghĩ screen đã là setuid root từ những năm 90

  • Thực sự có bao nhiêu lập trình viên đang vận hành những công cụ mã nguồn mở phổ biến nhất?
    Các ngành đang sử dụng những công cụ đó có bao nhiêu tiền?