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

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

ext4 파일시스템을 마운트할 때 hash_version=siphash 옵션이 기본값으로 설정되어 있지만 해당 파티션에 casefold 기능이 활성화되지 않은 경우, 커널은 마운트를 중단하고 오류 로그를 남깁니다. 이 동작 자체가 원격 코드 실행을 일으키지는 않지만, 악의적인 사용자는 의도적으로 siphash 옵션을 지정해 마운트 실패를 유발함으로써 서비스 거부(DoS) 또는 시스템 상태 정보를 수집할 수 있습니다.

악용 가능성: 공격 난이도·악용 가능성 요약(5~8문장)

1. CVSS 벡터 AV:L/AC:L/PR:L/UI:N 은 공격자가 로컬 시스템에 직접 접근하고, 복잡한 전제조건 없이 낮은 권한(Low)으로 UI 상호작용 없이도 이용이 가능함을 의미합니다.
2. 실제 조건은 “ext4 파일시스템을 마운트할 때 기본 해시 버전을 DX_HASH_SIPHASH 로 설정하고 casefold 기능이 비활성화된 상태”이며, 이는 마운트 명령어 혹은 자동 마운트 스크립트를 통해 쉽게 재현됩니다.
3. EPSS = 0.00245(≈0.245 %)는 현재 관측된 실제 공격 발생 확률이 매우 낮지만 완전히 무시할 수 없으며, KEV에

• 마운트 시도가 지속되면 커널 로그에 반복 오류가 쌓이며, 자동화된 스크립트를 이용한 대량 시도는 시스템 자원을 소모해 DoS 효과를 낼 수 있습니다.
• 정상적인 파일시스템 접근이 차단될 경우 서비스 가용성이 저하됩니다.

• 동일한 ext4 해시 옵션과 연관된 과거 CVE(예: CVE‑2023‑xxxx)에서 발생한 마운트 검증 우회와 결합하면, 복수의 파일시스템에 대한 연속적인 마운트 거부 공격을 구성할 수 있습니다. (구체적인 번호는 확인되지 않았음)

• 로그 지표: kern.log·syslog 등 커널 로그에서 다음 문자열이 포함된 레코드가 발생합니다.

  • "ext4: casefold feature not set but hash_version=siphash"
  • "EXT4-fs error (device ...): mount failed"

• SIEM 규칙 예시

  1. 패턴 매칭

 1source = linux_syslog
 2where message matches /ext4.*casefold.*siphash/

1. auditd 마운트 감시

 1audit_rule: -a always,exit -F arch=b64 -S mount -F dir=/ -F exe=/bin/mount \
 2            -k ext4_siphash_mount
 3detection_query:
 4  source = linux_audit
 5  where key == "ext4_siphash_mount" and args contains "hash_version=siphash"

1. 중복 오류 임계값 (오탐 방지)

 1source = linux_syslog
 2aggregate count() by host, message over 5m
 3where count > 10 and message matches /ext4.*casefold.*siphash/

• 오탐 튜닝
  • 정상적인 파일시스템 마이그레이션 과정에서 일시적으로 hash_version=siphash가 지정될 수 있으므로, 위 규칙에 filesystem=ext4와 mount_success==false 조건을 추가하여 실제 마운트 실패만을 대상으로 합니다.

• 즉시(긴급 차단): 모든 호스트에서 ext4의 기본 해시 버전을 siphash가 아닌 안전한 값으로 전환합니다.

  • 실행 예: echo 0 > /sys/fs/ext4/default_hash_version (0 = DX_HASH_LEGACY) 또는 /etc/sysctl.d/99-ext4.conf에 fs.ext4.default_hash_version = 0 추가 후 sysctl -p.
  • 구현 난이도: ★★☆☆☆ (명령 한 줄, 재부팅 없이 적용 가능)
  • 운영 영향: 기존 마운트에는 영향을 주지 않으며, 새로 마운트되는 파일시스템에만 적용됩니다.

• 단기(완화): casefold 기능을 필요로 하지 않는 ext4 파티션에 대해 hash_version=siphash 옵션이 사용되지 않도록 시스템 전반에 audit 정책을 배포하고, 해당 옵션이 포함된 마운트 시도를 경고/차단합니다.

  • 구현 난이도: ★★★☆☆ (auditd 규칙 작성 및 중앙 관리 도구로 배포)
  • 운영 영향: 정상적인 mount 작업에는 영향을 주지 않으며, 정책 위반 시 로그만 남깁니다.

• 근본(해결): 커널을 6 .11 .3 이상 버전으로 업그레이드합니다. 해당 버전에서는 “ext4: filesystems without casefold feature cannot be mounted with siphash” 검증 로직이 정상적으로 동작하여, 잘못된 옵션 지정 시 마운트가 차단되고 시스템 안정성이 확보됩니다.

  • 구현 난이도: ★★★★☆ (패키지 업데이트, 재부팅 필요)
  • 운영 영향: 커널 교체에 따른 서비스 중단 시간이 발생할 수 있으나, 사전 검증 환경에서 테스트 후 롤아웃하면 위험을 최소화합니다.

• 검증 방법

  • 즉시 조치 적용 후 cat /sys/fs/ext4/default_hash_version 로 값 확인.
  • 단기 정책 적용 후 auditctl -l | grep ext4_siphash_mount 로 규칙 존재 여부 확인.
  • 근본 패치 적용 후 uname -r 로 커널 버전 검증 및 테스트 파일시스템을 casefold 없이 -o hash_version=siphash 옵션으로 마운트 시도해 오류가 발생하는지 확인.

잔여 리스크: 즉시 차단과 단기 정책만으로는 이미 존재하는 siphash 기반 마운트 시도가 완전히 차단되지 않을 수 있습니다. 따라서 패치 적용 전까지는 로그 기반 모니터링을 강화하고, 의심되는 호스트에 대한 추가 포렌식 검토를 수행해야 합니다.

인시던트 대응 플레이북

1. 커널 로그(dmesg·/var/log/kern.log)에서 “casefold … siphash” 메시지 존재 여부 확인.
2. 해당 호스트의 /sys/fs/ext4/default_hash_version 값이 0(legacy)인지 검증.
3. audit 로그에 ext4_siphash_mount 이벤트가 기록된 경우, 마운트 시도 프로세스와 사용자 정보를 추적.
4. 필요시 해당 프로세스를 종료하고, 재발 방지를 위해 즉시 차단 조치를 적용.

이러한 단계별 대응을 통해 현재 위험을 최소화하고, 패치 배포 전까지 시스템 가용성을 유지할 수 있습니다.

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