요약
Debian이 2주도 더 전에 막은 치명적 커널 취약점을 Ubuntu는 아직 고치지 않았습니다.
서버에 Ubuntu를 써 온 한 개발자가 11월 2일에 올린 글입니다. 리눅스 커널의 TCP 코드에 2016년부터 있던 취약점 CVE-2026-98432(CVSS 9.8점)를 Ubuntu가 패치하지 않자, 운영하던 Ubuntu 서버를 모두 내리고 다른 배포판으로 옮기겠다고 밝혔습니다.
왜 중요한가
- 보안 구독을 파는 회사의 배포판이 자원봉사자가 꾸리는 배포판보다 패치가 늦었다는 점을 정면으로 문제 삼습니다.
- 작성자는 VPS(가상 사설 서버) 업체의 기본값이고 믿을 만하다는 평판 때문에 Ubuntu를 썼는데, 그 믿음이 깨졌습니다.
핵심 내용
- 글을 쓴 시점에 Ubuntu는 LTS를 포함해 지원 중인 모든 릴리스를 취약 상태로 표시하고 있었습니다.
- 이 취약점은 원격에서 건드릴 수 있고, 앤트로픽은 서버 루트 권한을 얻는 공격 코드를 실제로 만들었다고 합니다.
- Debian은 10월 16일에 패치를 냈고, Arch와 Alpine도 이미 수정본을 내놓았습니다.
- 작성자는 "중요 취약점의 적시 패치"라는 Ubuntu 홈페이지의 약속이 실제 대응과 맞지 않는다고 비판했습니다.
- 서비스와 데이터를 옮길 시간이 없어 Ubuntu 서버를 일단 모두 내렸다고 했습니다.
HN 반응
- Ubuntu가 이 취약점을 긴급 패치 대상인 '심각'이 아니라 '높음'으로 분류하고도 이유와 완화책을 거의 설명하지 않았다는 비판이 이어졌습니다.
- 반면 IP 옵션(패킷 헤더에 붙는 부가 정보)이 달린 패킷은 인터넷에서 대개 걸러져 실제 공격은 어렵다는 반론도 나왔습니다.
설상가상으로, Ubuntu 보안 사고 페이지[0]에는 "Ubuntu Priority: High"라고 적혀 있습니다(Critical이었다면 일정과 상관없이 패치가 나갔을 텐데, 그게 아니라 High라는 겁니다). "Why this priority?" 링크가 있는데, 거기에는 이렇게만 적혀 있습니다.
이게 전부입니다. TBD나 다름없는 이 문장에는 마침표조차 없습니다. 그 뒤에는 "Ubuntu Priority"가 무엇인지 설명하는 일반적인 링크가 붙어 있는데, 그 페이지는 오히려 이들의 판단과 모순됩니다. 완화 방법도 전혀 나와 있지 않고, (지독하게 불명확한) 설명마저 NIST 페이지에서 그대로 복사한 것이라 Ubuntu가 직접 전하는 메시지는 하나도 없습니다.
apt upgrade를 할 때 "Ubuntu Pro로 더 많은 보안 업데이트를 받으세요"라는 문구를 처음 본 날부터 이미 느낌이 좋지 않았는데, 이번 일이 다른 배포판으로 옮기게 만든 결정타입니다.[0] https://ubuntu.com/security/CVE-2026-98432#priority-reason
공정한 평가는 아닌 것 같습니다. 근거를 알아보기 쉽게 안내하지 않은 건 맞지만, 그 근거는 여기 보안 점수 항목[0]에 있습니다. 저는 결국 Claude에게 커널 전문 용어를 제 작은 머리로 이해할 수 있는 말로 풀어 달라고 해야 했는데, 요지는 시스템을 다운시킬 수는 있어도 기밀 시스템 데이터를 공격자에게 노출하거나 시스템의 데이터를 훼손할 가능성은 낮은 버그라는 겁니다. 특히 이 익스플로잇은 IP 옵션이 붙은 패킷이 있어야만 가능한데, IP 옵션은 공개 인터넷에서 흔히 차단되거나 제거됩니다. 취약한 시스템뿐 아니라 인터넷을 거쳐 오는 취약한 요청 경로까지 있어야 하는데, 그건 직접 공격을 시도해 보기 전에는 알 수 없습니다. 게다가 그 공격은 SYN, 재전송된 SYN, Reset이 아주 근접한 시간에 모두 일어나야 해서 타이밍에 크게 좌우됩니다. 의지가 확고한 공격자라면 여러분의 네트워크 안에서는 아마 해낼 수 있겠지만, 인터넷을 통해서는... 가능성이 낮아 보입니다.
[0] https://ubuntu.com/security/CVE-2026-98432#impact-score
레드햇은 생각이 다릅니다[0][1]. 앤트로픽의 말을 앵무새처럼 따라 하는 걸 수도 있고, 앤트로픽이 영향을 과장했을 수도 있습니다(그럴 가능성이 높죠!). 하지만 이 취약점에 대한 현재의 중론은 그렇습니다. Ubuntu가 동의하지 않는다면 그렇다고 말을 했어야지, 페이지 맨 위에 "Cvss 3 Severity Score 9.8 · Critical"을 붙여 놓으면 안 됩니다.
클라우드 환경이 얼마나 중앙집중화되어 있는지를 생각하면, 그것만으로도 여전히 재앙 수준이라고 봅니다.
[0] https://access.redhat.com/security/cve/cve-2026-98432
[1] https://access.redhat.com/security/vulnerabilities/RHSB-2026-016
모든 클라우드 환경이 취약한 건 아닙니다. 예를 들어 GCP는 이런 옵션을 제거합니다.
다시 말씀드리지만, 근거를 잘 안내했다고 주장할 생각은 없습니다. 다만 9.8은 CVSS 3.0 점수고, 우선순위는 4.0 기준인 8.3으로 매긴 것으로 보입니다. 이 점은 분명히 맨 앞에 적어 뒀어야 합니다.
그래도 특정 상황에서는 기본 설치에서 RCE가 되는 취약점입니다. 게다가 다른 배포사들은 2주 전에 이미 패치한 문제인데, 보안 권고문에는 읽을 만한 설명도 완화 방법도 없습니다.
저는 셋 중 하나만 했어도 아무 불만이 없었을 겁니다. Debian처럼 일찌감치 조용히 패치했거나, 우선순위를 어떻게 매겼는지 알려 줬거나, 아니면 영문 모를 이유로 늦어지더라도 레드햇처럼 질 좋은 권고문을 냈다면요.
동료 보안 엔지니어를 욕하는 건 좋아하지 않지만, 이번 건은 정말 형편없었고 지금도 저는 직접 피해를 보고 있습니다.
바로 그겁니다. 숙고한 끝에 의견이 갈릴 수는 있어요. 하지만 숙고하려면 논의와 설명이 있어야죠! 소통이 이렇게까지 없다니 그저 어안이 벙벙합니다. 자기네 브랜드를 일부러 깎아먹으려는 것 같아요.
진짜 대체 무슨 일이 벌어지고 있는 거죠? 긴급 커널 업데이트 절차가 있다는 건 알잖아요. 당연히 있겠죠. 다른 곳은 다 방아쇠를 당기는 이 건에 대해서만 안 당기겠다면, 적어도 왜 그런지 설명은 해야죠.
리눅스 커널의 오랜 메인테이너(USB, PCI, driver core, sysfs, -stable 릴리스)인 그레그 크로아하트먼이 LLM을 활용한 CVE 발견을 주제로 강연을 했습니다. 그 강연에서 그는 Mythos가 드러낸 CVE들을 깎아내렸습니다. 위에 쓰신 내용은 그런 CVE의 취약점 점수를 낮춰야 한다는 그의 견해와 일치합니다.
이전 토론과 유튜브에 올라온 실제 강연은 여기서 보세요.
https://news.ycombinator.com/item?id=49929391
이걸로 루트 권한을 얻는 걸 사람들이 시연해 보였다는 걸 생각하면 "가능성이 낮다"는 말은 좀 의심스러운데요.
아이폰이 실제로 mptcp를 쓰는 것 같은데, 그건 tcp 옵션을 쓰니까 이 말이 얼마나 맞는지 잘 모르겠네요.
TCP 옵션과 IP 옵션은 꽤 다릅니다.
IP 옵션은 덩치 큰 고속 라우터에서 골칫거리입니다. CPU를 거치는 느린 경로로 처리해야 하기 때문입니다. (적어도 외부에서) IP 옵션이 붙은 패킷을 받아 줄 쓸모가 별로 없어서 대체로 아예 버려지는 편입니다. (다만 CPU는 패킷을 많이 옮기는 데 적합하지 않으므로, CPU로 올라오는 패킷은 거의 확실하게 강하게 제한됩니다.)
ip-option이 뭔지 오해한 댓글이 너무 많아서 어느 쪽이 맞는지 판단하기가 어렵습니다. 제가 아는 건 이렇습니다. 저는 5개 대륙에 공인 IP 수백 개를 가진 라우터를 운영하는데, 그중 어느 것에서도 WAN 쪽으로 ip-option이 붙은 IP 패킷이 들어온 적이 없고, 내부 쪽에서도 이걸 재현하려고 scapy로 직접 만든 것 말고는 본 적이 없습니다. 또 제가 시도해 본 어떤 인터넷 경로로도 이런 패킷이 통과하게 만들 수 없었습니다.
누가 이걸로 루트 권한을 땄다는 거죠? 제가 마지막으로 본 건 "일단 믿어봐"가 전부였는데요.
앤트로픽은 했다고 주장하고, 지금까지 이런 일로 거짓말을 한 게 들통난 적은 없습니다. 이론적으로 봐도 커널 네트워크 스택의 메모리 안전성 취약점을 익스플로잇할 수 있다면 루트 접근이 최종 목표일 테니 말이 됩니다.
결국 정말로 "일단 믿어봐"가 맞네요!
그럼 정확히 뭘 하길 바라시는 겁니까? 리눅스 서버 상당수를 루팅할 수 있는 익스플로잇을 공개하라고요?
패치가 충분히 널리 적용되고 나면 아마 요란하게 공개하겠죠.
claude/haiku5.5에게 그 CVE를 제 서버와 도커 이미지에 대해 검토해 보라고 시켰습니다. Claude는 그 서버에 비밀번호 없이 ssh로 접속할 수 있었고 루트 권한은 없었습니다. 검토를 마치고 서버에 취약점이 있다고 확인해 줬고, sudo 명령 몇 개를 실행해서 출력을 달라고 하더군요. mptcp 옵션을 끄는 명령도 실행해 달라고 했고요.
그다음에는 호스트 서버(U 26.04는 몇 주 전에 설치했습니다)와 그 서버의 도커 이미지에 대해 CVE 전체 검토를 하고 보안 검토 문서를 업데이트하라고 시켰고, Ubuntu 웹사이트에서 커널 보안 업데이트를 매일 확인하는 작업도 추가했습니다.
EDIT: 방금 Claude에게 패치를 작성하고 그 위에 이미지를 빌드해서 제 서버의 문제를 고칠 수 있느냐고 물었습니다. 할 수 있다고 하더군요. 그러면서 2줄짜리 패치 https://github.com/torvalds/linux/commit/e3f33b0.patch 를 적용해서 이 문제를 고친 커널 이미지를 빌드해 줄 수 있다고 알려 줬습니다. 참고하시라고요....
맞아요, 만족스러운 대응을 못 내놓는다는 게 관 뚜껑에 박는 마지막 못입니다. 이번 사건으로 Ubuntu에 대한 제 컨설팅 조언이 "추천하지 않음"에서 "즉시 갈아타라"로 올라갔습니다.
고객 중에는 이 변화가 뜻밖인 분들도 있을 겁니다. 제가 한때는 Ubuntu를 개발·배포 플랫폼으로 좋은 선택이라고 권했거든요. 그게 사실이 아니게 된 지 꽤 됐지만, 이제는 한물간 정도를 넘어(jumped the shark) 장어가 득시글거리는 물속으로 뛰어든 셈입니다. 더는 진지하게 대할 수가 없습니다.
그냥 Debian이 늘 최선이었어요. 이번 CVE에서는 RHEL마저 공을 놓쳤잖아요. 사람들이 지원받으려고 돈 내고 쓰는 배포판인데도요.
항상 그런 건 아닙니다. 특히 FIPS 암호화처럼 규정 준수 요건이 있거나(정부 고객이 있는 경우처럼), 상용 벤더를 써야 하는 요건이 있다면 Debian은 안 됩니다. 또 더 최신의 시스템 패키지나 믿을 만한 릴리스 주기가 필요하다면 Ubuntu가 더 나을 수 있습니다.
데스크톱에서는 독점 드라이버가 필요하면 Ubuntu가 설치하기 더 쉽습니다.
하지만 맞습니다, Debian이 자기한테 맞다면 저도 Ubuntu는 쓰지 않을 겁니다.
저는 FIPS를 한 번 다뤄 본 적이 있습니다. 다니던 회사가 제품에 커스텀 리눅스 배포판을 같이 출하했기 때문에, FIPS 요건을 맞추려고 레드햇의 OpenSSL 패키지를 사실상 억지로 끼워 넣어야 했습니다. 웃긴 건 고객이 FIPS를 켜고 나자 관리는 훨씬 어려워지고 암호화 강도는 오히려 확실히 나빠졌다는 겁니다.
어쨌든 FIPS가 필요한 건 다소 특수한 요건입니다. 특별한 요건에 부딪히기 전까지는 범용 서버의 기본 리눅스 배포판으로 Debian이나 Rocky가 아주 합리적인 선택입니다.
물론이죠. 대부분은 Debian이면 충분합니다. 하지만 특별한 요건이 있다면 다른 쪽이 더 나을 때도 있다는 거죠.
FIPS 암호화가 뭐고, 왜 FIPS가 RHEL에만 있는 건데요? 그리고 FIPS가 이 CVE와 무슨 상관이죠?
FIPS는 미국 정부의 보안 표준입니다: https://en.wikipedia.org/wiki/FIPS_140
이 CVE와는 별로 상관없지만, 미국 정부에 판매하려는 경우에는 흔히 필수 요건이 됩니다. 그래서 그 판매로 돈을 버는 회사는 그 인증이 없는 배포판으로 쉽게 옮길 수 없습니다.
인증받은 암호 구현을 쓰는 것에 관한 얘기입니다. 아마 RHEL에는 그런 인증이 있고, Debian은 규격은 맞지만 인증은 받지 않은 구현을 쓰는 거겠죠.
이 CVE와는 무관하지만, Debian이 언제나 적합한 배포판이라는 주장에 대한 반론입니다.
아마 FIPS 표준을 충족한다는 뜻일 거예요 https://en.wikipedia.org/wiki/FIPS_140
그렇지 않아요
상관없어요. 그 댓글에 대한 답글로 나온 얘기일 뿐이에요.
아뇨, 됩니다. Trixie의 OpenSSL은 지원되는 버전입니다.
https://packages.debian.org/trixie/openssl-provider-fips
라이브러리일 뿐이고, OS에 특별한 건 없습니다.
https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4985
제가 아는 한, 규정 준수는 외부 모듈로 제공됩니다.
https://openssl-library.org/post/2025-03-11-fips-140-3/
이 모듈은 Debian에 있는 것 같습니다.
apt-cache search fips | grep open
openssl-provider-fips - Secure Sockets Layer toolkit - cryptographic utility
dpkg -L openssl-provider-fips
/. /usr /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/ossl-modules /usr/lib/x86_64-linux-gnu/ossl-modules/fips.so /usr/share /usr/share/doc /usr/share/doc/openssl-provider-fips /usr/share/doc/openssl-provider-fips/changelog.Debian.gz /usr/share/doc/openssl-provider-fips/changelog.gz /usr/share/doc/openssl-provider-fips/copyright
검증 절차도 있는 것 같은데, 그걸 사용하는 머신마다 실행해야 한다고 합니다.
openssl fipsinstall -out /tmp/configfile.cnf -module /usr/lib/x86_64-linux-gnu/ossl-modules/fips.so 2>&1 | tee /tmp/result.txt
--
위 내용은 제 메모와 테스트 실행에서 가져온 겁니다. 하지만 레드햇이 여기서 뭐가 "특별"한지 모르겠습니다. 모듈이 로드되고 규정 준수를 명시한다면 준수하는 겁니다.
검증된 빌드가 아닙니다. 동작은 똑같지만, 정말로 검증된 FIPS 모듈이 필요하다면 그걸로는 충분하지 않습니다.
검증이 필요하다면 커널도 검증을 받아야 합니다.
물론 Debian에서 FIPS 검증을 받은 시스템을 돌리는 게 불가능한 건 아니지만, 검증된 구성 요소를 얻으려면 아마 WolfSSL 같은 다른 상용 제공업체와 계약해야 할 겁니다. 아니면 직접 컴파일하거나요. 하지만 그건 Ubuntu, 레드햇, Suse에서 이미 검증된 OS를 돈 주고 쓰는 것보다 훨씬 복잡하고 손이 많이 갑니다.
저는 매일 소프트웨어를 컴파일합니다. cmake가 투덜대기 시작하기 전까지는 어려울 게 없고, 그때도 매번 정상 궤도로 되돌려 놨어요.
그냥 동작하는 걸 컴파일하면 되는 문제가 아닙니다. 정확히 명시된 대로 컴파일해야 합니다. 그리고 모든 과정을 문서화해서 감사관에게 전부 올바르게 했다고 증명할 수 있어야 하고요. 아, 그리고 테스트된 플랫폼 목록이 있는데 Debian은 아마 거기에 없을 테니, 그 경우에는 왜 괜찮은지, 그리고 왜 테스트된 플랫폼 중 하나를 쓰는 게 합리적이지 않은지를 감사관에게 설명해야 합니다.
돈을 내고 사는 건 개발자가 컴파일하는 시간을 아끼는 게 아닙니다. 감사를 받을 때의 마찰을 줄이는 겁니다.
인증의 구체적인 내용이 궁금하네요. 어떤 인증서도 특정 바이너리가 올바르게 동작한다는 걸 증명할 수는 없잖아요. 컴퓨터가 어떻게 돌아가는지 제대로 아는 사람은 아무도 없는데, 여기 Oracle Linux 11.0은 괜찮다고 적힌 종이 한 장이 있다는 거죠. 비싸고 승인 도장이 찍혀 있으니 그걸로 증명이 된다고요.
FIPS 구현이 검증됐는지를 중시하는 회사라면, 사내의 누군가가 cmake를 꾸준히 정상으로 돌려놓는 데 기대기보다는 그걸 파는 회사에서 사는 쪽을 아마 선호할 겁니다. 그 시점에는 모듈만의 문제가 아니라 관리 책임, 법적 책임 같은 문제이기도 하니까요.