- Ubuntu 25.10에서 Rust로 작성된 coreutils(uutils) 의
date명령어 버그로 인해 일부 시스템의 자동 업데이트 기능이 작동하지 않는 문제가 발생 - 이 버그는 rust-coreutils 패키지 0.2.2-0ubuntu2 이하 버전에서 발견되었으며, 0.2.2-0ubuntu2.1 이상 버전에서 수정됨
- 문제는 클라우드 배포, 컨테이너 이미지, 데스크톱 및 서버 설치 환경 모두에 영향을 미쳤으나,
apt명령어를 통한 수동 업데이트에는 영향 없음 - Ubuntu는 이번 릴리스에서 Rust 기반 유틸리티(uutils, sudo-rs) 로의 전환을 시험 중이며, 이는 내년 장기 지원(LTS) 버전 적용 가능성을 평가하기 위한 과정
- 이번 사건은 Rust 전환 과정의 안정성 검증 필요성을 보여주며, 향후 배포판의 보안 및 유지보수 전략에 중요한 시사점을 제공
Ubuntu 25.10 자동 업데이트 장애 개요
- Ubuntu 프로젝트는 Rust 기반 uutils의
date명령어 버그로 인해 일부 시스템이 자동으로 업데이트를 확인하지 못하는 문제를 공식 발표- 영향을 받은 시스템에는 클라우드 배포 환경, 컨테이너 이미지, Ubuntu Desktop 및 Server 설치본이 포함
- 자동 업데이트 확인이 실패해 보안 패치 및 소프트웨어 갱신이 지연될 위험 존재
- Ubuntu 보안팀은 공지를 통해 해결 방법(remediation instructions) 을 제공
- 사용자는 rust-coreutils 패키지를 0.2.2-0ubuntu2.1 이상 버전으로 업데이트해야 문제 해결 가능
- 해당 버그는 자동 업데이트 프로세스에만 영향을 미치며,
apt명령어나 기타 수동 업데이트 도구에는 영향 없음
버그의 원인과 영향 범위
- 문제의 원인은 Rust로 재작성된 coreutils(uutils) 의
date명령어가 시스템 시간 처리 과정에서 오류를 일으킨 것으로 분석- 이로 인해 자동 업데이트 스케줄러가 정확한 날짜 계산에 실패, 업데이트 확인 루틴이 중단됨
- 영향 범위는 Ubuntu 25.10의 모든 배포 형태에 걸쳐 있으며, 특히 자동화된 서버 환경 및 클라우드 인스턴스에서 운영 중단 가능성 존재
- Ubuntu는 이번 문제를 통해 Rust 기반 시스템 유틸리티의 안정성 검증 절차 강화 필요성을 인식
Rust 기반 유틸리티 전환(“Oxidize” 프로젝트)
- Ubuntu는 25.10 릴리스에서 “oxidize” 프로젝트를 추진, 기존 C 기반 coreutils를 Rust 기반 uutils로 교체하는 실험 진행
- 동시에 sudo 명령어의 Rust 버전(sudo-rs) 도 도입하여 보안성과 메모리 안전성 향상 목표
- 이 프로젝트는 2026년 4월 예정된 장기 지원(LTS) 릴리스에 Rust 기반 유틸리티를 포함할 수 있을지 평가하기 위한 시험 단계
- LWN은 이미 2025년 3월 해당 프로젝트를 다루며, Rust 도입이 리눅스 배포판의 구조적 안정성에 미칠 영향을 분석한 바 있음
수정 버전 및 대응 지침
- Ubuntu 보안 공지에 따르면, rust-coreutils 0.2.2-0ubuntu2 이하 버전이 문제를 포함
- 0.2.2-0ubuntu2.1 이상 버전으로 업데이트 시 버그가 해결됨
- 사용자는
apt update && apt upgrade명령을 통해 패키지 수동 업데이트를 수행 가능- 자동 업데이트 기능이 복구되기 전까지는 정기적인 수동 점검이 권장됨
시사점 및 향후 전망
- 이번 사건은 Rust 전환 과정에서의 초기 불안정성을 보여주는 사례로 평가
- 메모리 안전성과 보안성 향상을 위한 Rust 도입이 기능적 안정성 검증과 병행되어야 함을 시사
- Ubuntu의 실험은 리눅스 배포판 전반의 Rust 채택 흐름을 가속할 가능성 있음
- 향후 LTS 릴리스에서 Rust 기반 유틸리티가 안정적으로 통합될 경우, 시스템 보안 및 유지보수 효율성 향상이 기대됨
Hacker News 의견
-
나는 이런 식으로 문제를 조기에 발견하는 게 괜찮다고 생각함
LTS 릴리스 전에만 정리된다면 문제없음- 나는 평범한 Ubuntu 사용자로서 이게 괜찮은지는 잘 모르겠음
uutils/coreutils의 테스트 호환성 그래프를 보면 아직 완전하지 않음
특히date는 테스트 2개만 통과하고 3개는 건너뛰고 3개는 오류임
이런 상태로 프로덕션 준비 완료라고 보기 어렵다고 생각함 - 시스템 여러 대를 운영하다 보면 일부 구성요소는 너무 신뢰해서 문제 발생 시 의심조차 안 하게 됨
이런 버그는 개별 사용자에겐 사소할 수 있지만, 대규모 환경에서는 치명적임
오늘 하루 종일 디버깅하다가 결국 시스템이 명시적으로 금지된 곳으로 데이터를 보내고 있었음을 발견했음
결과적으로 시스템 전체가 멈췄고, 의존하던 도구가 깨지면 관리가 정말 힘들어짐
만약 Rust가 아닌 다른 언어였다면 개발자들이 엄청난 비난을 받았을 것임 - 핵심 유틸리티가 명확한 이유 없이 새로 작성된 버전으로 교체되고, 그게 너무 불안정해서 안정 배포판이 제대로 업데이트도 못 하는 상황이라면 괜찮다고 할 수 없음
- “이슈를 이렇게 찾는 거야”라는 말이 마치 Microsoft식 대응처럼 들림 /s
- 나는 평범한 Ubuntu 사용자로서 이게 괜찮은지는 잘 모르겠음
-
기존 coreutils에 개선이 필요할 정도로 문제가 있었는지 궁금함
- 아마도 라이선스 문제 때문일 가능성이 있음. 예전에 이 댓글에서도 그런 추측이 있었음
- OpenBSD 유지보수자 입장에서는, 특정 언어가 시스템 언어로 적합한지 판단하려면 coreutils를 그 언어로 구현해보는 게 필수라고 함
관련 글: OpenBSD 메일링리스트 - CVE-2015-4042 같은 보안 이슈 때문일 수도 있음
- Rust로 작성되지 않았다는 게 문제였던 것 같음. 그런데 borrow checker가 왜 date 버그를 잡지 못했는지 의문임
- 배경을 알고 싶다면 Ubuntu의 공식 글인 Carefully but purposefully oxidising Ubuntu를 참고하면 됨
-
uutils에서의 패치 링크를 찾고 싶음
-
상위 댓글이 웃겼음 — “다음 Ubuntu 릴리스 이름은 Grateful Guinea-Pig일 것”이라고 함
-
Ubuntu changelog를 보면 버그가
date -r관련임
changelog와 버그 리포트, 이슈, PR을 보면
date -r이 파일 수정 시각을 출력해야 하는데, Rust 버전은 그냥 무시했음
이런 기본 동작 누락은 “안전한 대체품”을 표방하는 프로젝트로서는 실망스러움- 만약 이 버전이 coreutils의 공식 테스트를 통과했다면, 오히려 테스트 스위트가 불완전하다는 뜻일 수도 있음
- 그래도 버퍼 오버플로우는 없었음!
-
Ubuntu 보안 공지 — 전형적인 사례 같음
-
Ubuntu 25.10은 사용 불가능할 정도라고 느꼈음. 비-LTS 버전에 대해 이렇게 말한 건 처음임
- 어떤 점이 그렇게 심각한지 구체적으로 설명해줄 수 있는지 궁금함
-
“수십 년간 검증된 C 유틸리티를 Rust로 다시 쓰는 건 장기적으로 좋을 수 있지만, 단기적 문제는 예측 가능했다”는 말에 공감함
하지만 “장기적”이란 게 얼마나 긴 기간을 의미하는지 의문임
FOSDEM 발표에서 uutils 개발자가 잘못된 벤치마크로 성능이 더 낫다고 주장했는데, 실제로는 locale 미지원 때문이었다는 점도 문제였음
관련 링크: FOSDEM 발표, 스레드1, 스레드2- 하지만 이런 핵심 도구들도 결국 여러 번의 재작성을 거쳐온 결과물임. 너무 극단적으로 볼 필요는 없음
- locale 처리가 추가된 후에는 오히려 성능이 향상되었다는 Phoronix 기사도 있음
- 이런 재작성 대신, 같은 노력으로 형식 검증 시스템을 구축했다면 보안 측면에서 더 나았을지도 모른다는 생각이 듦
- 오픈소스 프로젝트가 개인의 명성 쌓기 수단으로 이용되는 경우도 있음
핵심 유틸리티를 새로 작성하는 건 포트폴리오에 큰 이점이 되기 때문임
-
guided state-space exploration이나 fuzzing의 최신 기술이 궁금함
기존 구현이 있다면 fuzzer가 두 버전의 동작을 비교해 화이트박스 검증을 할 수 있을 것 같음- 이런 경우 property testing이 잘 맞을 것 같음
전체 입력 공간에 대한 proptest를 작성하려면 많은 노력이 필요하지만, CLI 인자가 안정적이라면 충분히 가능함
man 페이지 같은 자료를 기반으로 자동 생성도 가능함
Rust에서는proptest크레이트를, CLI 차이 검증에는 Python의 Hypothesis를 외부 호출로 사용하는 게 좋을 듯함
- 이런 경우 property testing이 잘 맞을 것 같음