# GNU Screen에서 발견된 여러 보안 문제

> Clean Markdown view of GeekNews topic #20893. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=20893](https://news.hada.io/topic?id=20893)
- GeekNews Markdown: [https://news.hada.io/topic/20893.md](https://news.hada.io/topic/20893.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-05-14T09:58:10+09:00
- Updated: 2025-05-14T09:58:10+09:00
- Original source: [openwall.com](https://www.openwall.com/lists/oss-security/2025/05/12/1)
- Points: 2
- Comments: 1

## Topic Body

- **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, 버그 리포트 및 문서 링크 포함

## Comments



### Comment 38639

- Author: neo
- Created: 2025-05-14T09:58:11+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=43971716) 
* 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
  * Tmux 작성자와의 Q&A도 있었음, 16년 전부터 문서화 부족에 대해 불만이 있었음, 관련 자료: https://undeadly.org/cgi?action=article&sid=20090712190402
* 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로 실행하라는 의미임