[방어] 분석 — CVE-2025-71097

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

IPv4 네임스페이스에서 ip nexthop add 로 생성한 nexthop 객체를 ip route add blackhole … nhid <id> 와 연결 후, 해당 nexthop 를 ip nexthop del 로 삭제한다. 삭제 시 nexthop 가 “dead” 상태가 되지만 fib_table_flush() 가 에러 라우트(blackhole)를 플러시하지 않아 남아 있는 라우트가 여전히 dead‑nexthop 을 참조한다. 이로 인해 nexthop 객체와 연관된 네트워크 디바이스의 레퍼런스 카운트가 감소되지 않아 unregister_netdevice 가 무한 대기 상태에 빠지고, 결국 커널 패닉 또는 서비스 중단(DoS)으로 이어진다. 공격자는 로컬에서 CAP_NET_ADMIN 권한만 있으면 재현 가능하다.

악용 가능성: 이 취약점은 CVSS 벡터 AV:L/AC:L/PR:L/UI:N 로 평가되므로 공격자는 로컬 시스템에 접근해 낮은 복잡도의 단순 명령(예: ip nexthop del)만 수행하면 되며, 최소 권한(Low Privileges)으로도 충분하고 사용자 개입이 필요 없습니다. 따라서 실제 공격 난이도는 “Low” 수준이며, 로컬 관리자 혹은 CAP_NET_ADMIN 권한을 가진 일반 계정이라면 쉽게 트리거할 수 있습니다. EPSS 값 0.00114 은 현재까지 관측된 악용 사례가 극히 드물지만 완전히 없지는 않음을 의미하고, KEV

• 레퍼런스 카운트 누수: dead‑nexthop 에 대한 참조가 해제되지 않아 디바이스 객체가 영구히 남아 커널 메모리 소모 증가.
• 디바이스 정리 실패: unregister_netdevice 가 “Usage count = 2” 등 높은 값으로 대기, 해당 인터페이스(예: dummy) 삭제 불가.
• 시스템 가용성 저하: 누적된 레퍼런스 카운트로 메모리 고갈·커널 패닉이 발생하면 호스트 전체가 다운될 수 있음. 특히 컨테이너 환경에서 하나의 악성 테넌트가 호스트 커널을 마비시킬 위험이 있다.
• 권한 상승 가능성(추정): 레퍼런스 누수가 메모리 파편화를 일으키면, 슬랩 캐시 조작을 통한 UAF(Use‑After‑Free) 전이가 이론적으로 가능하나 현재는 확인된 악용 사례가 없다.

• IPv4 라우팅 테이블에서 레퍼런스 카운트 관리 오류와 연관된 과거 커널 버그(CVE‑2015‑.... 등)와 유사한 메모리 누수 패턴.
• netlink 기반 라우팅 조작 권한 상승 시나리오와 결합될 경우, 기존의 로컬 특권 상승 취약점과 체이닝 가능성이 존재한다(예: CAP_NET_ADMIN 오용).

1. 커널 로그 지표

   • dmesg / syslog 에서 unregister_netdevice: waiting for <ifname> to become free. Usage count = \d+ 메시지가 기록될 때.
   • netlink 서브시스템에서 RTM_DELRULE 혹은 RTM_NEWROUTE 이벤트가 발생하면서 RTA_ENCAP_TYPE=BLACKHOLE 와 RTA_NEXTHOP_ID 가 존재하고, 직후 동일 nexthop id 에 대한 RTM_DELNEXTHOP 로그가 연속적으로 나타나는 경우.

2. SIEM 쿼리 예시 (Elastic/Kibana)

   text복사

    1// 1) 레퍼런스 카운트 대기 메시지 탐지
    2event.dataset:"kernel" and message:/unregister_netdevice: waiting for .* to become free\. Usage count = [2-9][0-9]*/
    3 
    4// 2) blackhole 라우트와 nexthop 삭제 연계 패턴
    5(event.dataset:"auditd" and audit.type:"NETLINK_ROUTE" and audit.msg:/RTM_NEWROUTE.*BLACKHOLE.*nhid \d+/)
    6| join (
    7    event.dataset:"auditd" and audit.type:"NETLINK_ROUTE" and audit.msg:/RTM_DELNEXTHOP id=\d+/
    8) on nhid

3. eBPF 트레이스포인트

   • tracepoint:net:ipv4_route_del 와 tracepoint:net:nexthop_delete 를 동시에 캡처하고, 삭제된 nexthop ID가 아직 라우트 테이블에 존재하는지 검사한다.

4. 오탐 튜닝

   • 정상적인 인터페이스 제거 과정에서도 unregister_netdevice 가 로그될 수 있다. 따라서 “Usage count > 1” 조건과 함께 최근 5분 이내에 동일 ifname 에 대한 RTM_DELNEXTHOP 이벤트가 있는 경우만 경보를 발생시킨다.
   • 컨테이너 오케스트레이션 시스템에서 네트워크 플러그인(예: CNI) 가 일괄적으로 인터페이스를 정리할 때도 위 로그가 나타날 수 있다. 해당 상황에서는 process.name:"cni-plugin" 필터를 추가해 제외한다.

• blackhole 라우트 생성 금지: /etc/sysctl.d/99-disable-blackhole.conf 에 net.ipv4.route.blackhole = 0 (가상의 sysctl 옵션, 실제 존재하지 않음) 대신 iptables -I OUTPUT -d <any> -j REJECT --reject-with icmp-host-unreachable 로 차단 정책 적용.

  • 난이도: 중간 – iptables 규칙 추가 및 기존 자동화 스크립트 수정 필요.
  • 운영 영향: 정상적인 트래픽에 영향을 주지 않으며, blackhole 라우트를 통한 패킷 드롭을 방지한다.
  • 검증: ip route add blackhole 198.51.100.2/32 nhid 1 명령이 성공해도 실제 트래픽은 차단되지 않는지 ping -c 1 198.51.100.2 로 확인.

• 모니터링 자동화: 위 탐지 쿼리를 SIEM에 배포하고, 경보 발생 시 자동으로 해당 nexthop ID 를 플러시하는 스크립트를 실행한다.

  • 난이도: 중간 – 간단한 bash/python 스크립트와 cron/systemd‑timer 연계.
  • 운영 영향: 약간의 CPU·메모리 오버헤드, 경보 시점에 일시적인 라우팅 재구성으로 짧은 지연 발생 가능.
  • 검증: 스크립트 실행 후 ip route show 에서 dead‑nexthop 을 포함한 blackhole 항목이 사라지는지 확인.

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