[방어] 분석 — CVE-2026-31428

• 심각도 medium · CVSS 5.5 · EPSS 0.00131 · 악용난이도 hard

nfnetlink_log 모듈의 __build_packet_message() 가 skb_put()·skb_copy_bits() 로 NFULA_PAYLOAD 속성을 수동으로 구성하면서, 4바이트 정렬이 맞지 않을 경우 패딩(1‑3 바이트)이 초기화되지 않아 그대로 사용자 공간에 전달됩니다. 로컬 프로세스가 NFLOG 소켓(NETLINK_NFLOG)을 열어 해당 메시지를 수신하면, 커널 힙에 남아 있던 이전 데이터가 노출됩니다. 이 과정은 권한이 낮은 계정(Low Privilege)에서도 수행 가능하며, 별도의 사용자 입력 없이 자동으로 발생합니다.

악용 가능성: 이 취약점은 CVSS AV:L/AC:L/PR:L/UI:N 로 평가되어 공격자는 로컬에서 복잡도 낮게 시도할 수 있지만, 실제로는 nfnetlink_log Netlink 소켓에 접근해야 하며 이는 일반 사용자 계정이라도 CAP_NET_ADMIN 권한이 필요하거나 동일 네임스페이스 내 프로세스여야 하는 제약을 가집니다.
공격자는 NFLOG 소켓을 열어 NFULA_PAYLOAD 속성을 통해 전송되는 패킷 데이터를 수신해야 하며, 이때 누수되는 바이트는 1~3 byte 로 매우 제한적이어서 의미 있는 정보를 추출하려면 힙 레이아웃에 대한 상세한 사전 지식이 요구됩니다.
따

• 정보 유출 – 초기화되지 않은 패딩에 포함된 커널 힙 내용(예: 이전 패킷 버퍼, 암호키, 인증 토큰 등)이 그대로 NFLOG 메시지에 포함되어 사용자 공간에 노출됩니다.
• 추가 공격 경로 – 누출된 메모리 정보를 이용해 커널 구조체 주소를 추정하거나, 향후 메모리 오버플로우·권한 상승 취약점의 사전 조사 단계로 활용될 수 있습니다.
• 가용성 영향 – 대량의 비정상적인 NFLOG 메시지가 발생하면 로그 파이프라인이 포화되어 시스템 전반에 서비스 지연을 초래할 가능성이 있습니다.

• 추정: 메모리 초기화 누락은 CWE‑457 (초기화되지 않은 변수 사용) 혹은 CWE‑125 (버퍼 오버플로우/읽기 오류) 와 연계될 수 있으며, 동일한 패턴을 가진 커널 네트워킹 스택 취약점과 체이닝될 가능성이 있습니다.
• 추정: NFLOG 를 이용한 로그 전송 과정에서 발생하는 메모리 누수는 CWE‑20 (입력 검증 부재) 와 결합되어 악성 프로세스가 의도적으로 비정렬된 패킷을 생성함으로써 정보 유출을 확대시킬 수 있습니다.

• 로그 소스
  • auditd : recvmsg 시스템 콜에 대한 netlink 필터링 (키워드: AF_NETLINK, NETLINK_NFLOG)
  • kernel dmesg / tracepoint : nfnetlink_log_packet 또는 netlink_recv_msg 트레이스포인트
  • syslog 혹은 journald : iptables LOG/NFLOG 규칙에 의해 생성된 로그 메시지
• SIEM 쿼리 예시 (Elastic Kibana Query DSL)
  text복사

   1{
   2  "bool": {
   3    "must": [
   4      { "match_phrase": { "event.module": "auditd" } },
   5      { "match": { "audit.syscall": "recvmsg" } },
   6      { "wildcard": { "audit.exe": "*nfnetlink_log*" } },
   7      { "script": {
   8          "script": {
   9            "source": "doc['audit.msg'].value.length() % 4 != 0",
  10            "lang": "painless"
  11          }
  12        }
  13      }
  14    ]
  15  }
  16}

• 정규식 패턴 (로그 파일에 직접 적용)
  text복사

   1^.*recvmsg\([^)]*AF_NETLINK[^)]*\).*payload_len=\d+,\s*pad_len=(1|2|3).*

• 오탐 튜닝
  • 정상적인 NFLOG 사용에서도 비정렬 패딩이 존재할 수 있으므로, “패딩 크기 > 0 && 동일 프로세스에서 연속 5회 이상 발생”을 임계값으로 설정합니다.
  • 특정 시스템 서비스

• 즉시(긴급 차단)

  • modprobe -r nfnetlink_log 로 NFLOG 커널 모듈을 언로드하거나, /etc/modprobe.d/disable-nflog.conf에 install nfnetlink_log /bin/false 를 추가해 재로드를 방지한다.
    구현 난이도: 낮음 → 단일 명령 실행 및 재부팅 필요 없음.
    운영 영향: NFLOG 기반 로깅이 중단되므로, 기존 보안 로그 정책을 임시로 다른 메커니즘(예: iptables LOG)으로 전환해야 함.
    검증: lsmod | grep nfnetlink_log 결과가 없고, dmesg에 “nfnetlink_log: module not found” 메시지가 표시되는지 확인한다.

• 단기(패치 전 완화)

  • Seccomp 프로파일을 적용해 비특권 컨테이너/프로세스에서 NETLINK_NFLOG 소켓 생성(socket(AF_NETLINK, *, NETLINK_NFLOG))을 차단한다.

 1{
 2  "syscalls": [
 3    {"name":"socket","action":"SCMP_ACT_ALLOW",
 4     "args":[{"index":0,"value":AF_NETLINK},
 5             {"index":2,"value":NETLINK_NFLOG}]}
 6  ]
 7}

 1*구현 난이도*: 중간 → 컨테이너 런타임(예: Docker, containerd) 설정 수정 필요.  
 2*운영 영향*: NFLOG를 활용한 정상적인 로깅/모니터링 기능이 제한되지만, 서비스 가용성에는 큰 영향을 주지 않음.  
 3*검증*: `docker run --security-opt seccomp=seccomp-profile.json alpine` 환경에서 `nc -U /var/run/nflog.sock` 시도 시 “Operation not permitted” 오류 확인.  

• 커널 파라미터 net.netfilter.nf_log_all_netns=0 (가능한 경우) 로 전체 네임스페이스의 NFLOG를 비활성화한다.
  구현 난이도: 낮음 → sysctl 적용 후 재부팅 없이 즉시 반영 (sysctl -w net.netfilter.nf_log_all_netns=0).

• 근본(해결)

  • 취약점이 수정된 커널 버전으로 업그레이드한다. 현재 영향을 받는 범위는 linux_kernel 2.6.24‑5.10.253, 5.11‑5.15.203, 5.16‑6.1.168, 6.2‑6.6.131, 6.7‑6.12.80, 6.13‑6.18.21, 6.19‑6.19.11 이다. 최신 LTS 커널(예: 6.10.x 이상)으로 업데이트하면 패치가 포함된다.
    구현 난이도: 높음 → 배포 파이프라인에 커널 교체, 재부팅 및 서비스 검증 필요.
    운영 영향: 커널 교체 시 호스트와 컨테이너 모두 재시작 필요, 일부 드라이버/모듈 호환성 점검 필수.
    검증: grep -i nfnetlink_log /boot/config-$(uname -r) 로 해당 모듈 유무 확인 후, dmesg | grep "NFLOG" 에 패치 적용 로그(예: “nfnetlink_log: padding leak fixed”)가 표시되는지 확인한다.

• 잔여 리스크

  • 패치를 적용해도 NFLOG 자체는 여전히 사용 가능하므로, 로깅 정책이 필요하다면 별도의 무결성 검증(예: 로그 서명)과 최소 권한 원칙을 유지해야 함.
  • EPSS 0.00131·hard 난이도 평가에 따라 공격이 구현되려면 추가적인 LPE 취약점이 결합되어야 하므로, 현재 환경에서 다른 특권 상승 경로가 존재하는지 지속적으로 모니터링한다.

• 인시던트 대응 플레이북

  1. 알림 발생 → NFLOG 모듈 로드 여부 확인 (lsmod).
  2. 비정상적인 NETLINK_NFLOG 소켓 열기 기록이 있으면 해당 프로세스 PID, 사용자, 컨테이너 ID 추출.
  3. 즉시 해당 프로세스 차단(kill -9 <pid>), 필요 시 컨테이너 재시작.
  4. 로그 수집 시스템에 누수된 힙 데이터 샘플을 저장하고, 민감한 주소/키가 포함됐는지 분석.
  5. 패치 적용 일정 수립 및 커널 업그레이드 진행 후 정상화 검증.

• 조치: monitor (모니터링)
• 근거: CVSS=5.5 · non-KEV · EPSS=0.00131 · exploit=hard · in_scope=None