[방어] 분석 — CVE-2024-49968

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

ext4 파일시스템을 마운트할 때 커널 기본 해시 버전이 DX_HASH_SIPHASH 로 설정되어 있지만 해당 파티션에 casefold 기능이 비활성화된 경우, ext4 코드는 마운트를 중단하고 커널 로그에 오류를 남깁니다. 이 동작은 로컬 사용자가 mount 명령을 실행하거나 자동 마운트 서비스가 호출될 때 발생하며, 특권이 낮은 사용자라도 PR:L 조건을 만족하므로 추가 인증 없이 트리거됩니다. 성공 시 커널은 -EINVAL 반환값과 함께 마운트를 거부하고, 시스템에 따라 커널 패닉(DoS)까지 유발될 수 있습니다.

악용 가능성: 이 취약점은 AV:L (로컬) 벡터를 갖고 있어 공격자는 대상 시스템에 직접 접근하거나 로컬 계정을 확보해야만 악용할 수 있습니다. AC:L (낮은 복잡도)와 PR:L (저권한) 조건이 결합되어, 루트가 아닌 일반 사용자라도 mount 시스템 콜을 호출할 수 있는 권한이면 트리거가 가능합니다. UI:N (사용자 상호작용 없음)으로 인해 공격자는 별도의 피싱이나 클릭 유도 없이 자동화된 스크립트만으로도 조건을 만족시킬 수 있습니다. EPSS 0.00245 는 현재까지 실제 악용 사례가 드물

• 가용성(A): ext4 파티션이 정상적으로 마운트되지 않아 해당 파일시스템을 사용하는 서비스 및 애플리케이션이 접근 오류를 반환합니다. 최악의 경우 커널 패닉으로 전체 시스템 가용성이 손상될 수 있습니다.
• 무결성/기밀성(C/I): 직접적인 영향을 주지 않으며, 데이터 손실은 마운트 실패에 따른 서비스 중단 정도에 국한됩니다.

ext4 마운트 옵션 검증 결함과 연계될 경우, 기존 로컬 권한 상승(LPE) 취약점이나 SUID 바이너리 악용과 조합하여 공격자가 먼저 루트 권한을 획득한 뒤 이 취약점을 이용해 서비스 거부를 실행할 수 있습니다. 현재 동일한 해시‑casefold 조합을 이용하는 다른 CVE는 보고되지 않았습니다.

• 로그 지표

  • 로그 소스: kernel, syslog, journald (dmesg 포함)
  • 주요 필드: MESSAGE(또는 msg)에 다음 문자열이 포함됩니다.
    text복사

     1ext4: filesystems without casefold feature cannot be mounted with siphash
     2EXT4-fs (.*): mount failed: Invalid argument

  • 추가 조건: 커널 버전 < 6.11.3인 호스트에서만 유효합니다.

• SIEM 탐지 규칙 예시

  1. Splunk Query

     text복사

      1index=linux host=* source="kernel" 
      2  ("casefold feature cannot be mounted with siphash" OR "DX_HASH_SIPHASH")
      3| eval kv=split(kernel_version,".")
      4| where tonumber(kv[1])<6 OR (tonumber(kv[1])==6 AND tonumber(kv[2])<11) OR (tonumber(kv[1])==6 AND tonumber(kv[2])==11 AND tonumber(kv[3])<3)

  2. ElasticSearch DSL

     text복사

      1{
      2  "bool": {
      3    "must": [
      4      {"match_phrase": {"message": "casefold feature cannot be mounted with siphash"}},
      5      {"range": {"kernel.version.major": {"lt": 6}}},
      6      {"range": {"kernel.version.minor": {"lt": 11}}},
      7      {"range": {"kernel.version.patch": {"lt": 3}}}
      8    ]
      9  }
     10}

  3. auditd 규칙 (mount syscall 감시)

     text복사

      1-a always,exit -F arch=b64 -S mount -F exe=/usr/bin/mount -F key=ext4_siphash
      2-F path=/dev/* -F auid>=1000 -F uid!=0 -k ext4_mount_attempt

     이후 ausearch -k ext4_siphash 로 검색하고, args 필드에 hash=siphash 문자열이 포함된 경우 경보를 발생시킵니다.

• 오탐 튜닝

  • 커널 버전 ≥ 6.11.3에서는 해당 메시지가 출력되지 않으므로 반드시 버전 필터를 적용하십시오.
  • 디버그 빌드에서 동일 문자열이 개발용 로그로 남을 가능성이 있으나, 실제 운영 환경에서는 드물어 오탐 위험은 낮습니다. 필요 시 kernel_version 조건 외에 msgid=EXT4_FSMOUNT_FAIL 등 고유 ID를 추가하여 정확성을 높일 수 있습니다.

• 즉시(긴급 차단)

  • 모든 ext4 파티션에 대해 /etc/fstab 또는 자동 마운트 스크립트에 hash=legacy 옵션을 명시합니다. 예: UUID=xxxx /data ext4 defaults,hash=legacy 0 2.
  • 구현 난이도: 낮음 – 파일 수정 후 재부팅 혹은 mount -o remount,hash=legacy /data 로 적용 가능.
  • 운영 영향: 마운트 옵션 변경으로 서비스 중단 없이 적용할 수 있으나, 기존에 siphash를 의존하던 애플리케이션이 있다면 성능 차이가 미미하게 나타날 수 있습니다.
  • 검증 방법: mount | grep hash=legacy 로 확인하고, dmesg | grep casefold 가 더 이상 출력되지 않는지 점검합니다.

• 단기(완화)

  • auditd 규칙을 활성화하여 siphash 사용 시도 자체를 기록하고, 필요 시 auditctl -D 로 차단 정책(-a always,exit ... -F key=ext4_siphash -k block)을 적용합니다.
  • AppArmor 혹은 seccomp 프로파일에 mount 시스템콜을 제한하고, hash=siphash 옵션이 포함된 마운트 호출을 거부하도록 설정합니다.
  • 구현 난이도: 중간 – auditd 및 보안 프로파일 업데이트가 필요하지만 기존 관리 체계와 연동 가능.
  • 운영 영향: 정상적인 siphash 사용이 없는 환경에서는 서비스에 영향을 주지 않으며, 차단 정책 적용 시 로그량이 증가할 수 있습니다.
  • 검증 방법: ausearch -k ext4_siphash 로 이벤트가 기록되는지 확인하고, 차단된 마운트 시도에 대해 rc=EACCES 반환값을 관찰합니다.

• 근본(해결)

  • 커널을 6.11.3 이상 버전으로 업그레이드합니다. 최신 패키지를 배포하고 재부팅 후 uname -r 로 버전을 확인하십시오.
  • 구현 난이도: 높음 – 운영 환경에 따라 롤링 업데이트, 테스트, 서비스 중단 계획이 필요합니다.
  • 운영 영향: 커널 교체 시 전체 시스템 재시작이 요구되며, 호환성 검증이 선행되어야 합니다.
  • 검증 방법: 업그레이드 후 동일 마운트 시도 시 dmesg 에 오류 메시지가 사라지는지 확인하고, CVE‑2024‑49968 관련 커밋(ext4: reject siphash without casefold)이 포함된 커널 바이너리임을 패키지 매니저 로그로 검증합니다.

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