요약
Ubuntu가 치명적 등급의 리눅스 커널 취약점을 LTS 세 버전 모두에서 아직 고치지 않았습니다.
freenode의 셀프 호스팅 코너에 10월 31일 올라온 짧은 글입니다. CVSS(취약점 심각도 점수) 9.8을 받은 CVE-2026-98432가 Ubuntu에서는 아직 고쳐지지 않았다고 전했습니다.
왜 중요한가
- 인터넷에 노출된 서버나 여러 사용자가 함께 쓰는 서버처럼 격리를 LTS 커널에 맡긴 시스템이 가장 위험합니다.
- 공식 패치가 나올 때까지는 위험을 어떻게 막을지 관리자가 스스로 판단해야 합니다.
핵심 내용
- 22.04, 24.04, 26.04 LTS(장기 지원판) 어느 버전에도 수정된 커널 패키지가 없습니다.
- Ubuntu는 수정 커널을 언제 내놓을지 일정을 밝히지 않았습니다.
- 그때까지 기본 커널 유지, 별도 완화책 적용, 패치된 커널로 이전 가운데 하나를 골라야 한다고 했습니다.
- 취약점이 커널의 어느 부분에 있는지, 다른 배포판은 어떤지는 다루지 않았습니다.
HN 반응
- 일부 이용자는 IP 옵션이 붙은 TCP 패킷을 iptables로 미리 버리는 임시 규칙을 공유했지만, 그러지 않으려고 배포판을 쓴다는 반론이 나왔습니다.
- 자원봉사로 꾸리는 배포판도 고쳤는데 회사가 왜 못 하느냐며 Debian으로 옮기겠다는 댓글이 많았고, 아무 설명이 없는 점도 비판받았습니다.
raw PREROUTING 체인에 U32 드롭 규칙을 넣으면 커널 CVE가 악용되기 전에 iptables나 nftables로 이 패킷을 막을 수 있는데도, 이걸 짚는 공개 논의가 없다는 게 이상합니다...
sudo iptables -t raw -I PREROUTING -p tcp -m u32 ! --u32 "0>>24&0x0F=5" -j DROP
OS 벤더가 손을 놓고 있어도 리눅스 관리자가 직접 이런 조치를 할 수 있다는 건 리눅스의 큰 장점이죠. 하지만 배포판을 쓰는 이유 자체가 직접 해결책을 만들어 쓸 필요도 없고, 최소한의 보안을 위해 늘 신경을 곤두세우지 않아도 되게 하려는 것 아닙니까.
어젯밤에 제 서버에는 전부 패치했습니다. 인터넷에 노출된 서비스를 운영하기가 점점 어려워지고 있어요. 요즘 "해킹당해서 고객님의 데이터가 유출됐습니다"라는 메일을 너무 많이 받아서 어이가 없을 지경입니다. AI 공격 도구를 쓰는 사람들이 군대처럼 웹을 샅샅이 뒤지고 있는 게 틀림없어요.
모르는 분들을 위해 설명하면, 이 규칙은 헤더를 읽어서 길이가 5*4바이트가 아니면, 즉 옵션이 들어 있으면 패킷을 버립니다.
이 취약점 하나를 패치하지 않은 것만으로도 저는 이제 우분투를 쓸 만한 배포판 목록에서 지우게 됐습니다. 자원봉사로 운영되는 배포판도 고치는데, 자금력 있는 회사가 왜 못 합니까? 고칠 시간이 없었던 것도 아니고, 수정 사항을 현재 커널에 옮기는 일이 특별히 어려운 것도 아닙니다.
이걸로 마지막 쐐기가 박혔습니다. 저는 이미 새 가상 서버를 Debian으로 주문하고 있습니다. 기존 서버는 당분간 우분투로 두겠지만, 앞으로 서버용으로는 우분투를 고려하지 않을 겁니다. 제 생각은 "Debian은 자원봉사자들이 하니까 상용 업체만큼 빨리 수정을 내놓지는 못할 것"이었는데, 알고 보니 완전히 거꾸로였네요.
그렇다고 해도 저는 우분투에 단 한 푼도 낸 적이 없으니, 우분투가 저를 신경 쓰지 않는 것도 지극히 당연하긴 합니다.
우분투가 또 이러기로 했다는 사실 자체는 별로 흥미롭지 않습니다. 저는 그들이 패치를 내놓지 않은 이유가 무엇인지 알고 싶습니다. 공식 입장이 있다면 그것을, 없다면 비공식적인 추측이라도요.
패치가 그렇게 복잡해 보이지도 않고, 요즘 커널 업그레이드는 흔해 빠진 일이잖아요. 대체 무엇이 수정을 이렇게 오래 미루게 하는 걸까요?
정규 외 절차로 긴급 반영하기가 귀찮아서 정기 패치 시기를 기다리고 있는 것 같아요.
영향을 생각하면 나쁜 선택이라고 봅니다.
조직이 커질수록 거버넌스 담당자들이 끼어들어서 제멋대로인 규칙으로 일을 늦추는 게 문제죠.
그래도 HN이나 레딧에서 쏟아지는 비난은 분명 보고 있을 텐데요. 이 일에 대해 아무 입장도 안 내놓는 게 이상합니다.
요즘은 평범한 레딧 이용자의 의견에 별로 신경 쓰지 않는 사람이 많아요.
그럴 만하죠. 하지만 HN 사용자들은 대체로 IQ 분포의 중앙값을 기준으로 레딧 쪽과 반대편에 있잖아요.
그렇게 믿는다는 것 자체가 그 말이 사실이 아니라는 증거입니다.
거버넌스 담당자들은 아마 HN에 많이 살지는 않겠죠.
아니면 그냥 신경을 안 쓰거나요.
PHP2SHELL 수정은 제때 나왔습니다.
그러니 분명 무슨 이유가 있겠죠.
만약 아주 타당한 이유가 있는데 아직 말할 수 없는 거라면요?
그럼 "아주 타당한 이유가 있지만 아직은 자세히 말씀드릴 수 없다"고 말하면 되잖아요.
질문이 있습니다.
제가 본 소비자용 공유기 겸 무선 AP는 전부 리눅스로 돌아갑니다.
그런데 그 커널에 대한 보안 업데이트는 한 번도 본 적이 없습니다. 단 하나도요. 한 번도.
이건 우려할 만한 일일까요? 본인이 tplink, netgear, asus 같은 소비자용 공유기를 쓰지 않더라도 말입니다.
추가합니다: 제가 먼저 말씀드렸어야 할 맥락은, LLM이 스크립트 키디들에게 국가 차원의 도구와 전문성을 쥐여 주고 있다고 생각한다는 점입니다. 이미 알려진 이 버그는 앞으로 나올 스무 개에 비하면 늘 덜 흥미로운 문제일 겁니다.
우려할 만한 일이냐고요? 그렇습니다. 그래서 해킹당하겠냐고요? 아마 아닐 겁니다.
대부분의 소비자용 공유기는 특정 커널 버전에 묶인, 온갖 이상한 벤더 전용 패치가 덕지덕지 붙은 낡은 스택으로 돌아갑니다. 퀄컴, 당신 말이에요!
하지만 보통은 기본적으로 모든 트래픽을 차단하기 때문에 WAN 쪽에서 보면 블랙홀처럼 보입니다. 대다수 소비자에게는 그 정도면 "안전"하다고 봐야겠죠.
재미 삼아 OpenWRT 저장소에 열려 있는 PR들을 한번 보세요. 그분들은 정말 대단한 일을 하고 있지만, 벤더가 조금만 더 나은 선택을 했어도 쉬웠을 일로 고생하는 모습을 보면 답답합니다.
그래도 저는 OpenWRT 같은 쪽을 훨씬 선호합니다. 편집증이라고 불러도 좋지만, 지난 몇 주를 겪고 나니 블랙박스에 기기를 연결하는 게 점점 더 꺼려져요.
여기서는 소비자용 공유기 이야기를 하고 있다는 건 압니다. 하지만 서버나 홈랩을 운영하는 분들, 또는 외부 연결을 받아들이는 무엇이든 운영하는 분들이 읽고 계시다면 분명히 말씀드리고 싶습니다. 서버에서는 "아마 아닐 겁니다"가 "표적이 되면 아주 쉽게 뚫린다"로 바뀝니다.
그 외에는 잠겨 있는 시스템에서도 표적이 될 수 있는 커널 버그의 예를 들어 주실 수 있나요? 예를 들어 LAMP만 돌리고 나머지 포트는 소프트웨어 방화벽으로 전부 막아 둔 시스템이라면요. 이 기사에 나온 버그조차 실제로 악용하기는 꽤 까다로워 보입니다.
지원이 끝난 시스템도 여전히 많이 돌아다니는데, 그것들이 완전히 안전하다고 주장하려는 건 아닙니다. 다만 제가 알기로 커널 취약점은 보통 다른 곳의 사소한 취약점을 더 심각하게 만들고(예를 들면 연쇄적인 권한 상승), 그 자체만으로 악용하기는 대체로 어렵다고 생각했습니다. 제가 틀렸다면 알려 주세요.
넷필터가 DROP하지 않는 TCP 패킷(IP 옵션이 붙은 것)을 리눅스 커널에 보낼 수 있다면, 기술적으로는 취약한 겁니다.
당신의 LAMP 스택이 쓰는 그 포트 하나도 거기에 포함됩니다.
아니면 공격자가 LAN 안처럼 장비 반대편에서 들어올 수도 있습니다. 악의를 품은 직원이나 집에 온 손님 같은 사람이 내부 네트워크에서 기기를 노릴 수 있는데, 거기서는 대부분의 기기(서버만이 아니라)가 보호 수준이 낮고 파일 공유/SMB, SSH, SMTP, RDP, 데이터베이스 같은 열린 포트에 접근할 수 있는 경우가 많습니다.
지금 이야기하는 바로 이 버그는 무슨 이유로 예시에 안 들어가나요?
소비자용 공유기 중에는 기술 지원 문제 해결을 위해 원격 접속을 허용하는 게 많지 않나요?
wireguard나 ssh용으로 포트를 포워딩해 두는 경우는요?
그런 건 대개 기본으로 켜져 있지 않습니다.
제가 아는 한, 일부 모델에서 발견된 백도어는 전부 LAN 쪽에서만 접근할 수 있고, 공격자가 이미 네트워크 안에 있다면 이미 늦은 겁니다.
그러면 안 되죠. 제 스마트 전구에 RCE가 있고 공유기와 함께 별도 VLAN에 격리돼 있다고 해서, 그 전구가 공유기를 공격해서 다른 VLAN에 있는 제 기기에 접근하도록 권한을 올릴 수 있어서는 안 됩니다. 피해는 자기 VLAN 안으로 한정돼야 합니다.
동의하지 않습니다. 네트워크 안의 기기에서 이 버그를 통해 루트 권한을 얻는 것 같은 일도 막아 두는 게 좋다고 생각합니다. 그런 기기는 다른 경로로 언제든 장악당할 수 있고, 그다음에 스스로 루트로 올라갈 수 있으니까요.
엄청난 위험이고, 시간문제일 뿐입니다. 특히 펌웨어 업데이트가 끊긴 하드웨어는 더 그렇습니다.
저도 어떻게 할지 고민 중입니다.
안드로이드가 6개월 지난 패치를 매달 내놓던 망령이 이제 되돌아와 화를 부를 겁니다.
Turris [1]는 몇 년째 공유기를 꼼꼼하게 업데이트해 왔습니다.
[1] https://www.turris.com
Turris를 알게 돼서 좋네요.
10G 모델은 소비자용 느낌이 좀 덜한 것 같습니다. 그쪽으로 가려면 cisco, arista 같은 곳도 보안 업데이트는 해 주겠죠.