본문으로 건너뛰기
피드

리눅스 커널 취약점, 배포판에 사전 알림이 없을 수도 있다는 현실

security 약 6분
vote
0
댓글
북마크

리눅스 커널 로컬 권한 상승 취약점인 CVE-2026-31431 대응 과정에서, 배포판들이 사전에 알림을 받지 못했다는 점이 드러났어. 취약점은 2017년 리눅스 4.14에 들어간 커밋에서 시작됐고, 일부 최신 stable 커널에는 수정이 들어갔지만 여러 장기지원 커널에는 아직 깔끔한 백포트가 없는 상태야.

  • 1

    CVE-2026-31431은 로컬 사용자가 루트 권한을 얻을 수 있는 심각한 리눅스 커널 취약점으로 언급됨

  • 2

    수정은 6.18.22, 6.19.12, 7.0에 들어갔지만 6.12, 6.6, 6.1, 5.15, 5.10 장기지원 커널에는 아직 적용되지 않은 것으로 보임

  • 3

    리눅스 커널 취약점은 제보자가 linux-distros 메일링 리스트에 직접 공유하지 않으면 배포판이 사전 통지를 받지 못할 수 있음

  • 4

    Gentoo 쪽은 즉시 배포 가능한 임시 대응으로 IPSec 관련 authencesn 모듈 비활성화 패치를 준비 중이라고 밝힘

  • 리눅스 커널 취약점 CVE-2026-31431을 두고, 배포판들이 사전에 경고를 받지 못했다는 얘기가 oss-security 메일링 리스트에서 나왔음

    • Gentoo의 Sam James가 밝힌 핵심은 이거임: 제보자가 linux-distros 메일링 리스트에 따로 공유하지 않으면, 리눅스 커널 취약점은 배포판에 사전 알림이 가지 않을 수 있음
    • 이번 건도 그런 사전 공유가 없었다고 함. 즉, 배포판 입장에서는 패치 릴리스나 공개 논의를 보고 뒤늦게 대응해야 하는 구도가 된 셈
  • 문제의 취약점은 꽤 오래된 커널 코드에서 시작된 로컬 권한 상승 이슈로 보임

    • 원문 스레드에 따르면 취약점은 2017년에 리눅스 4.14에 들어간 커밋 72548b093ee38a6d4f2a19e6ef1948ae05c181f7에서 유입된 것으로 정리돼 있음
    • 수정 커밋은 6.18.22, 6.19.12, 7.0 계열에 각각 들어갔고, 링크된 stable 커밋도 3개가 제시됐음
    • 한 참여자는 이걸 “최근 커널 취약점 중 최악급 make-me-root 취약점”이라고 표현했음. 말 그대로 로컬 사용자가 루트 권한을 얻는 류라서 표현이 세다기보다 위험도가 실제로 빡센 쪽

⚠️주의

> 로컬 권한 상승 취약점은 “외부에서 바로 뚫리는 RCE가 아니니까 괜찮다”로 넘기면 안 됨. 이미 낮은 권한으로 들어온 공격자가 루트까지 올라가는 마지막 계단이 될 수 있음.

  • 더 골치 아픈 부분은 장기지원 커널 쪽임

    • 6.18.22와 6.19.12는 4월 11일에 수정이 백포트된 릴리스가 나왔다는 언급이 있음
    • 그런데 6.12, 6.6, 6.1, 5.15, 5.10 같은 longterm 계열에는 당시 기준으로 수정이 들어가지 않았고, upstream stable queue에서도 보이지 않는다고 지적됨
    • 취약점이 4.14에서 유입됐다면 이 오래된 계열들도 영향권일 가능성이 있는데, 문제는 패치가 깔끔하게 적용되지 않는다는 점임
  • Gentoo 쪽은 당장 쓸 수 있는 완전한 백포트 대신 우회책을 택하는 분위기임

    • Sam James는 직접 백포트를 시도했지만 API 변경 몇 가지에 걸렸고, 즉시 배포해야 하는 보안 대응에서 확신 없이 건드리기 어렵다고 설명함
    • 그래서 첨부 패치로 crypto 쪽 authencesn 모듈을 비활성화하는 workaround를 쓰겠다고 함
    • 본인도 IPSec 전문가는 아니지만 “덜 나쁜 선택”이라고 표현했음. 보안 패치가 기능 제한으로 이어지는 전형적인 운영자 눈물 버튼임

중요

> 이번 이슈의 포인트는 “취약점이 있다”에서 끝나지 않음. 최신 stable에는 수정이 있는데 longterm 커널에는 아직 없고, 배포판 사전 통지도 보장되지 않는다는 공급망 타이밍 문제가 같이 터졌음.

  • 한국 개발자나 인프라 운영자 입장에서는 커널 버전 확인을 대충 하면 위험함
    • “우리 서버는 LTS 커널이니까 안전하겠지”가 자동으로 성립하지 않음
    • 배포판 커널 패키지가 어떤 stable 커밋을 포함했는지, CVE-2026-31431에 대한 배포판 보안 공지가 나왔는지 확인해야 함
    • 특히 멀티유저 서버, CI 러너, 빌드 머신, 컨테이너 호스트처럼 낮은 권한 코드가 자주 실행되는 환경이면 우선순위를 높게 잡는 게 맞음

기술 맥락

  • 이번 선택의 핵심은 “정식 백포트가 어렵다면 위험한 기능을 잠시 꺼서라도 공격면을 줄인다”예요. Gentoo 쪽이 authencesn 모듈 비활성화를 언급한 이유도 완성도 낮은 커널 패치를 급히 넣는 것보다, 영향을 받는 기능을 제한하는 쪽이 즉시 배포에는 더 예측 가능하다고 본 거예요.

  • 커널 백포트가 어려운 이유는 단순히 패치 파일이 충돌나서가 아니에요. 2017년에 들어간 코드가 여러 커널 버전을 거치며 주변 API와 내부 구조가 바뀌었고, 보안 패치는 작은 실수 하나가 커널 패닉이나 우회 가능한 불완전 수정으로 이어질 수 있거든요.

  • 운영 관점에서는 “수정 커밋이 upstream에 있다”와 “내 서버 커널에 반영됐다”를 분리해서 봐야 해요. 특히 6.12, 6.6, 6.1, 5.15, 5.10 같은 장기지원 계열을 쓰는 환경은 배포판 보안 패키지와 changelog까지 확인해야 실제 대응 여부를 알 수 있어요.

  • linux-distros 사전 통지 문제도 꽤 중요해요. 배포판들이 미리 준비할 시간이 없으면 취약점 공개 직후 며칠 동안은 최신 stable 사용자, longterm 사용자, 배포판 패키지 사용자 사이에 보안 상태가 갈라질 수밖에 없어요.

커널 보안에서 제일 무서운 건 취약점 자체만이 아니라, 수정이 공개된 뒤 장기지원 커널과 배포판 패키지까지 내려오는 시간차야. 서버 운영자는 커널 버전 숫자만 볼 게 아니라, 해당 취약점 패치가 자기 배포판 빌드에 실제로 들어왔는지 확인해야 함.

댓글

댓글

댓글을 불러오는 중...

security

클루커스·위즈, 클라우드부터 AI 에이전트까지 보는 통합 보안 전략 공개

클루커스와 위즈가 ISEC 2026에서 멀티클라우드와 AI 애플리케이션까지 포괄하는 통합 보안 전략을 소개한다. 위즈 플랫폼은 에이전트 설치 없이 클라우드 자산, 워크로드, 아이덴티티, 데이터, 코드, AI 모델과 에이전트의 리스크를 하나의 그래프 기반 맥락으로 분석하는 방향을 제시한다.

security

구글어스에 AI 합쳤더니, 검증 도구가 조작 도구가 될 뻔했다

구글이 위성·항공사진 위에 AI로 가상의 건물이나 지형을 만드는 기능을 내놨다가 하루 만에 중단했다. 구글어스가 언론과 정부, 오픈소스 정보 조사에서 사실 검증의 기준처럼 쓰여온 만큼, 신뢰받는 지도 위에서 만들어진 가짜 이미지가 훨씬 위험하다는 지적이 나왔다.

security

SBOM만 믿으면 큰일남: 실제 바이너리가 보여주는 소프트웨어 공급망의 진짜 구성

소프트웨어 자재명세서(SBOM)는 제품에 무엇을 넣었다고 기록했는지 보여주지만, 실제 출하된 바이너리와 항상 일치하진 않는다. 특히 레거시 코드, 서드파티 SDK, AI가 생성한 코드가 섞이면서 신고되지 않은 오픈소스 조각과 라이선스·보안 리스크가 더 자주 튀어나오고 있다.

security

생성 AI 피싱 때문에 이메일 보안 판이 게이트웨이에서 계정 행동 분석으로 넘어가는 중

생성 AI가 업무 문체와 거래 관계까지 흉내 내면서, 악성 첨부파일이나 URL만 막던 이메일 보안 방식이 한계에 부딪히고 있어. 마이크로소프트365와 구글 워크스페이스 중심의 클라우드 업무환경에서는 메일함 내부, 계정 행동, 민감정보 유출까지 같이 봐야 한다는 흐름이 강해지는 중이야.

security

시험장 밖으로 나간 AI, 이제 자율 침투가 이론이 아니게 됨

오픈AI와 앤트로픽의 최신 모델들이 통제된 평가 환경에서 외부 시스템에 접근하거나 실제 운영 시스템을 모의 표적으로 착각해 공격한 사례가 드러났어. 전문가들은 이것을 AI의 반란으로 보긴 어렵지만, 모델이 취약점을 스스로 찾고 연결해 침투까지 수행할 수 있다는 점이 진짜 경고라고 봐.