2P by GN⁺ 18시간전 | ★ favorite | 댓글 1개
  • GNU Screen 5.0.0 및 setuid-root 설치에서 심각한 보안 취약점이 발견됨
  • 로컬 루트 권한 상승, TTY 하이재킹, 세계 쓰기 가능한 PTY 생성 등이 주요 이슈임
  • 다수의 Linux 및 UNIX 배포판이 일부 또는 전부 영향을 받음
  • 임시 패치 제공 및 다수 배포판에서 우선적으로 조치 필요함
  • Screen의 setuid-root 설계 자체에 근본적인 보안 위험성 존재

1. 소개

  • 2024년 7월, Screen의 upstream 관리자가 코드 리뷰 요청을 하면서 보안 검토가 시작됨
  • 예전에는 별다른 문제가 발견되지 않았으나, 이번에는 Screen 5.0.0에서 setuid-root 설정 시 심각한 루트 권한 상승 취약점을 발견함
  • 추가적으로, 이전 버전(4.9.1 등) 에서도 영향을 주는 경미한 보안 취약점 다수를 확인함
  • 보고서에는 버전별 취약점 패치 세트(4.9.1, 5.0.0)가 첨부되어 있음
  • 배포판별 Screen 설정 및 버전, 주요 취약점, setuid-root 관련 개발상의 위험성, 보안 강화 권장사항, 공개 조율 과정 문제점, 영향 매트릭스 등이 포함됨

2. Screen 구성 및 버전 개요

  • 2024년 8월, Screen 5.0.0이 릴리스되어 Arch Linux, Fedora 42, NetBSD 10.1에서 탑재됨
  • 5.0.0에는 수많은 refactoring이 포함됐으며, 일부는 10년 이상 전부터 존재하던 코드임
  • 일부 취약점은 5.0.0에서 새로 도입됐고, 일부는 이전 버전(4.9.1 등) 에서도 존재함
  • 대부분의 배포판에서는 아직 4.9.1이 사용 중임
  • Screen 다중 사용자 모드는 setuid-root로 설치된 경우에만 사용 가능하며, 코드 복잡성으로 인해 보안 공격면이 크게 증가함
  • 주요 배포판 중 Arch Linux, FreeBSD, NetBSD가 setuid-root로 Screen을 설치함; Gentoo는 “multiuser” USE flag에서만 setuid-root로 설치 가능함

3. 보안 이슈 상세

3.a) logfile_reopen()을 통한 로컬 루트 취득 (CVE-2025-23395)

  • Screen 5.0.0의 setuid-root 실행 시, logfile_reopen() 함수가 권한을 내려놓지 않고 사용자 입력 경로로 파일을 생성함
  • 공격자는 root 소유의 임의 파일을 생성하여 터미널 데이터를 기록 및 악용할 수 있음
  • 이미 존재하는 파일도 악용 가능하며, 예를 들어 privileged shell script에 코드 삽입 등의 공격이 이루어질 수 있음
  • Arch Linux, NetBSD 5.0.0 완전 취약, Fedora와 Gentoo의 특정 환경 등에서 부분 취약함
  • 패치는 secure file handling 복원으로 적용되었으며, 배포판별 구체적 영향이 존재함

3.b) 다중 사용자 세션 연결 시 TTY 하이재킹 (CVE-2025-46802)

  • Attach() 함수에서 multiattach 플래그 활성화 시, TTY의 권한이 0666으로 일시 변경됨
  • 이 과정에서 경쟁 조건(race condition)으로 제3의 사용자가 해당 TTY에 읽기/쓰기 접근이 가능해짐
  • 입력 데이터 도청, 데이터 조작, 비밀번호 탈취 등 위험이 존재함
  • TTY 권한이 원상 복구되지 않는 코드 경로도 존재함
  • 패치는 chmod 666 조작 제거로 적용; 단, 일부 재접속 use case가 깨질 수 있으나 기존에도 동작하지 않았음

3.c) PTY 기본 권한 취약 (CVE-2025-46803)

  • 5.0.0에서 PTY의 기본 권한이 0620 → 0622(세계 쓰기 가능) 로 변경됨
  • 보안상 잠재적 위험도가 상승, 특히 모든 사용자가 다른 PTY에 쓸 수 있게 됨
  • 이 변경은 실수로 도입된 것으로 보이며, 패치는 compile 시 safe default(0620) 복원으로 해결
  • Arch Linux, NetBSD가 주요 영향 대상임

3.d) 소켓 에러 메시지를 통한 파일 존재 정보 유출 (CVE-2025-46804)

  • SCREENDIR 환경변수와 Error 메시지를 이용해 실존 파일/디렉토리 유무를 루트 권한으로 확인 가능
  • Minor 정보 유출이며, 모든 setuid-root 설치 환경에서 위험 존재

3.e) 시그널 전송의 TOCTOU 경쟁 조건 (CVE-2025-46805)

  • CheckPid()Kill() 함수 간 시간차로 인해, 의도와 다른 PID에 root 권한으로 신호가 전송될 위험이 있음
  • 주로 SIGCONT, SIGHUP 등만 허용되어 영향은 제한적이나, 서비스 거부(DoS) 또는 경미한 무결성 훼손 발생 가능

3.f) 잘못된 strncpy() 사용에 따른 커맨드 전송 시 오버플로우

  • 5.0.0에서 strncpy()의 잘못된 사용으로 버퍼 오버플로우 및 프로그램 크래시가 발생함
  • 정상적으로 패치되지 않으면, 커맨드 전송 시 MAXPATHLEN 이후 메모리 덮어써 서비스 불능 상태로 이어짐
  • 보안 문제는 아니나, 안정성상 빠른 수정 필요함

4. setuid-root 구현 관련 추가 위험성

  • 멀티유저 모드에서 다중 사용자 UID 처리 논리 부실 확인됨
  • setuid-root 상태에서 drop privilege 로직이 완전하지 않음
  • root가 생성한 세션에서 효과적인 권한 하락이 이루어지지 않아 전반적으로 위험성이 높음

5. 보안성 강화 일반 권고

  • 대규모 코드 refactoring 과정에서 기존 보안 로직 붕괴 확인됨
  • setuid-root 바이너리의 특성상 보안성 테스트 스위트 도입 및 모든 파일시스템/환경 변수 처리를 보수적으로 설계할 필요성
  • 특히 setuid-root 전체 실행은 추천하지 않으며, multi-user 기능은 신뢰된 그룹 opt-in 방식으로만 제한할 것
  • 환경 변수(PAH 등)는 신뢰된 경로로만 지정하도록 필히 강제할 것

6. 취약점 발표 조율 과정에서의 문제점

  • Upstream과의 조율 과정이 비효율적으로 진행, 패치 개발 및 공개가 지연되는 문제 발생
  • Upstream의 코드 이해도 및 역량 부족으로 긴밀한 대응이 어려웠음
  • 결국 배포판 측에서 패치 개발 주도, 조정된 일정에 맞춰 보고서 발표 진행
  • Screen 프로젝트 자체의 유지, 관리 역량 부족도 확인됨

7. 영향도 매트릭스

  • Arch Linux(5.0.0, setuid-root): 3.a, 3.b, 3.c, 3.d, 3.e, 3.f 모든 취약 영향
  • Debian/Ubuntu 등 다수 배포판: 3.b(부분 영향)
  • Fedora 42(5.0.0, setgid-screen): 3.b(부분 영향), 3.f 영향
  • Gentoo(4.9.1, setgid-utmp): 3.b(부분 영향), unstable ebuild + multiuser USE flag시 5.0.0과 동일 영향
  • 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): 3.b(부분 영향)
  • openSUSE TW: 3.b(부분 영향)

8. 일정

  • 2024-07-01: upstream에서 코드 리뷰 요청 전달받음
  • 2025-01-08: 리뷰 시작
  • 2025-02-07: upstream에 비공개로 취약점 보고, 조율된 공개 요청
  • 2025-02~04: 패치 논의 진행, embargo 기간 이슈로 일정 재조정
  • 2025-05-12: 본 보고서 및 공식 발표 진행

9. 참고 링크

  • GNU Savannah [Screen 프로젝트 페이지]
  • openSUSE Bugzilla, 관련 패치, 참고 CVE, 버그 리포트 및 문서 링크 포함
Hacker News 의견
  • Screen에 여러 사용자가 같이 세션에 접속할 수 있게 해주는 멀티 유저 모드가 있음, 이 기능 덕분에 tmate 같은 도구가 가능해진다고 생각함, tmux도 동일한 취약점이 있는지 궁금함
    • tmux는 유닉스 도메인 소켓을 사용함, 왜 screen이 setuid 방식을 썼는지 이해되지 않음, root 권한이 필요 없어 보임, TFA에 설명된 바에 따르면 현재 screen 개발자들이 코드베이스를 완전히 파악하지 못해 setuid-root 방식이 쉽게 기능을 구현할 수 있어서 선택한 걸로 보임
    • 이 기능 정말 훌륭함, 트레이닝 세션에서 학생마다 내 노트북에 자신의 로그인 계정을 주고 ssh 셸을 'screen -x <특정 유저의 창>'으로 제한하여 학생이 해당 screen ACL에 허락된 윈도우만 쓸 수 있게 함, 나는 projector로 각 학생의 화면을 한 명씩 확인해 보여줌, 근데 보안 구멍 투성이라는 건 놀랍지 않음
    • screen -x 명령어를 쓴 경험 있음
  • Debian에서는 GNU screen이 setuid root 권한으로 설치되어 있지 않음
    • Debian Stable(bookworm) 패키지는 너무 오래되어 5.0.0 취약점에 영향 없음, 예전엔 Debian이 소프트웨어 버전이 너무 느림을 싫어했으나, 지금은 필요한 몇몇 응용프로그램만 따로 패키지 소스를 써서 신버전을 쓰고, 다른 것들은 구버전으로도 잘 사용 중임
    • Gentoo도 마찬가지임, 하지만 Gentoo에서는 utmp 그룹에 SETGID가 설정됨, 어떤 의미가 있는지는 잘 모름
    • Slackware 15에서는 screen이 suid가 없음
    • Fedora에서는 setuid로 설치된 것으로 보임
  • 블로그 글 랜더링 버전 소개함: https://security.opensuse.org/2025/05/12/screen-security-issues.html
  • GNU Screen의 로그 파일 기록 기능에 대한 문서가 부족해 글 작성자에게 이메일 보냄, GNU는 더 나은 이슈 추적 시스템이 필요하다고 생각함, 관련 자료: http://www.zoobab.com/screenrc
  • observed behaviour가 2005년부터 Screen에 있었음, 반패턴으로 오랫동안 rkhunter 같은 도구로 커버됨, 90년대에도 screen이 setuid root였다고 확신함
  • upstream(공식 개발팀)이 이번에 관여했다는 것이 놀라움, 약 5년 전에 GNU screen 개발이 완전히 중단된 것 같아 슬펐음, 지금도 그런지 궁금함, 화면에 attach하지 않고 screen에 새 창 추가할 수 있는 기능이 있는지도 궁금함
    • upstream이 SUSE팀에 검토를 요청한 것임, 개발 인력이 부족하고 현재 유지보수가 잘 안 되고 있음, 만약 그렇다면 아쉬움, tmux 등 대체제는 있어도 많은 사람들이 Screen을 오래 사용해 옴, 도구 노후화 현상이 아쉬움
    • setuid-root로 배포한 게 관여한 전부임, 이렇게 설정하는 배포판만 취약함, 그 외는 영향 없음, 공식 패치가 느릴 땐 배포판에서 직접 패치함
    • GNU 도구 개발이 멈추는 게(버그 픽스는 예외) 나쁜 일만은 아니라고 봄, 기능이 충분히 완성됐다는 신호일 수 있음
    • upstream과의 소통이 어려워 버그 픽스/릴리즈의 자세한 정보를 가지고 있지 않음, 보안 검토 요청은 했으나 연락이 어려운 상황인 듯함
    • 오픈소스는 한 소프트웨어가 끝나고 대체제가 나와도 바로 전환할 유인이 부족해 관성이 생기는 문제가 있음, 반대로 상표 만 사서 완전히 다른걸로 바꿔버리는 사례도 나옴(Audacity처럼), 좋은 해결책이 없음
  • 랜더링된 버전 링크: https://security.opensuse.org/2025/05/12/screen-security-issues.html
  • 얼마나 많은 개발자들이 인기있는 오픈소스 도구들을 전부 직접 써보는지, 그리고 그 도구들을 사용하는 분야에는 어느 정도의 돈이 오가는지 궁금함
  • tmux는 OpenBSD 기본에 4.6부터 들어갔던 걸로 기억하며, 감사를 거쳤음, 좀 더 보안을 신경 쓰는 사람들에게 좋은 대안임
    • screen이 언급된 걸 보고 과거에 tmux로 전환했다가 실수로 screen을 안 써서 헷갈렸던 기억이 남
  • screen과 setuid가 언급된 게 재미있음, 한 번은 이상한 이슈를 해결하려고 screen에 chmod u+s를 줬었음, 이런 걸 해야 한다는 게 기분이 이상했음, 하지만 알고보니 screen에는 setuid에 의존하는 기능이 있었고 어떤 시스템은 기본적으로 그렇게 배포된다는 걸 알게 됨, 그리고 u+s를 주니 screen이 내 ~/.screenrc 대신 root의 ~/.screenrc를 읽었음(임시방편으로 받아들임), screen의 build마다 setuid 지원이 다를 수도 있다고 생각함
    • setuid는 원래 그런 식으로 동작함, 바이너리에 특수 비트를 세팅하면 항상 제공된 user로 실행하라는 의미임