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

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

• 로컬 사용자가 조작된 erofs 이미지를 마운트하면, 커널 내부에서 겹치는 pcluster(physical cluster)를 처리하는 과정에서 folio lock 순서가 뒤바뀌어 데드락이 발생한다.
• 데드락이 일어나면 해당 I/O 작업을 기다리는 태스크가 영원히 대기하게 되고, 시스템 전반에 걸쳐 서비스 가용성(A:H) 이 상실된다.
• 공격자는 일반 사용자 권한만으로 이미지 파일을 생성·마운트할 수 있으므로, 특권 상승은 없지만 서비스 중단(DoS) 효과가 있다.

악용 가능성: 이 취약점은 AV:L(Local) · AC:L(Low) · PR:L(Low) · UI:N(None) 로 평가되므로, 공격자는 시스템에 직접 접근할 수 있는 권한만 있으면 복잡한 사전 준비 없이도 악용이 가능합니다. 실제로는 로컬에서 eROFS 이미지 파일을 마운트하거나 열어 해당 겹쳐진 pcluster 구조를 포함하도록 조작된 이미지를 제공하면, 커널의 erofs 드라이버가 Folio 락을 획득하려다 교착 상태에 빠지는 상황이 발생합니다. 이 과정에서 요구되는 전제조건은 ① 로컬 계정(일반 사용자 수준) ② 악성 이미지 파일을 마운트하거나 읽는 권한이며, 별도의 네트워크 접근이나 추가적인 권한 상승 단계가 필요하지 않습니다. EPSS 값 0.00182 은 실제 공격이 매우 드물지만 존재함을 의미하고, KEV에 등재되지 않은 점은 현재까지 보고된 실증 사례가 거의 없음을 반영합니다. 따라서 이 취약점의 공격 표면은 mount, open, read 시스템 콜을 통해 접근되는 eROFS 파일시스템 엔드포인트와 해당 이미지 내부에 존재하는 겹쳐진 pcluster 메타데이터이며, 이러한 파라미터가 조작될 경우 커널 레벨 교착 상태가 유발됩니다. 공격 난이도는 낮지만, 로컬 사용자가 악성 이미지를 실행할 수 있는 환경에서는 실제 서비스 중단(DoS) 위험이 존재합니다.

• Availability: 커널 내부 데드락 → 시스템 응답 정지 또는 재부팅 필요.
• Confidentiality / Integrity: CVSS 벡터에 C:N/I:N 로 표시된 바와 같이 직접적인 정보 유출·변조는 발생하지 않는다.

• 동일 파일시스템 이미지 파싱 과정에서 발생하는 메모리‑코어오버플로우(CVE‑2023‑xxxx) 등과 연계될 경우, 초기 DoS 후 추가적인 권한 상승 모듈을 로드해 공격을 확장할 수 있다. (구체적 CVE 번호는 확인되지 않음)

• 로그 지표

  • kernel 로그(dmesg, /var/log/kern.log)에 erofs: 와 deadlock 혹은 task hung 문자열이 동시에 나타나는 경우.
  • syslog 에서 foliowait·folio lock 관련 WARN/ERROR 메시지.
  • mount 시스템 콜 로그(auditd type=CONFIG_CHANGE)에서 파일시스템 타입이 erofs 로 지정된 이벤트.

• SIEM 탐지 규칙 예시 (예: Elastic Kibana Query)

  text복사

   1(event.module:"kernel" AND message:*erofs* AND (message:*deadlock* OR message:*task hung*)) 
   2OR (event.category:"process" AND process.name:"mount" AND process.args:*type=erofs*)

• 정규식 예시

  • (?i)erofs.*(deadlock|task\s+hung) – 대소문자 구분 없이 erofs와 데드락/태스크 정지 키워드 매칭.

• 오탐 튜닝

  • 다른 파일시스템(e.g., ext4)에서도 deadlock 메시지가 발생할 수 있으므로, 위 규칙에 message:*erofs* 조건을 반드시 포함한다.
  • 정상적인 이미지 검증 작업에서 일시적 lock‑wait 로그가 기록될 경우, 해당 이벤트를 시간 제한(예: 5 초 이내)과 프로세스 UID가 비특권 사용자인 경우에만 알림으로 억제한다.

• 즉시(긴급 차단)
  • erofs 모듈을 로드하지 않도록 시스템 전역에서 비활성화한다.

 1sudo modprobe -r erofs               # 현재 메모리 상에 로드된 경우 언로드
 2echo "install erofs /bin/true" | sudo tee /etc/modprobe.d/erofs.conf

• 구현 난이도: 낮음; 단일 명령어와 파일 편집으로 적용 가능.

• 운영 영향: erofs를 사용하지 않는 환경에서는 가용성·성능에 영향 없음.

• 검증 방법: lsmod | grep erofs 로 모듈이 비활성화된 것을 확인하고, mount -t erofs … 시 “unknown filesystem type” 오류가 발생하는지 테스트한다.

• 단기(완화)

  • SELinux/AppArmor 정책을 강화해 신뢰되지 않은 경로에서 erofs 마운트를 차단한다.
    • AppArmor 프로파일 예시: mount, deny /path/to/untrusted/** type=erofs.
  • 커널 파라미터 fs.erofs.enabled=0 (커널 컴파일 옵션이 지원되는 경우) 로 부팅 시 비활성화.
  • 구현 난이도: 중간; 정책 작성·배포 필요.
  • 운영 영향: 기존에 erofs를 활용하는 서비스가 있다면 마운트 실패 → 사전 검증 필수.
  • 검증 방법: 정책 적용 후 auditctl -l | grep erofs 로 차단 규칙 확인, 정상 이미지 마운트 테스트.

• 근본(해결)

  • 취약이 수정된 커널 버전으로 업그레이드한다. 영향을 받는 범위는 5.13‑6.10.13 및 6.11‑6.11.2; 따라서 최소 6.10.14 혹은 6.11.3 이상을 적용해야 한다.
  • 배포판별 패키지 매니저(예: yum update kernel, apt-get install --install-recommends linux-image-<ver>)를 이용해 최신 보안 업데이트를 적용한다.
  • 구현 난이도: 높음; 재부팅 필요 및 호환성 테스트 요구.
  • 운영 영향: 커널 교체 시 서비스 중단(재부팅) 발생, 사전 검증 절차 권장.
  • 검증 방법: uname -r 로 커널 버전 확인 후, 동일 이미지로 마운트 테스트하여 데드락 재현 여부를 점검한다.

• 잔여 리스크

  • 패치 적용 전까지는 위 즉시·단기 조치를 유지해야 하며, 모듈 비활성화가 불가능한 경우(특정 제품에서 erofs 필수)에는 모니터링 중심 대응을 지속한다.
  • EPSS = 0.00182 로 실제 악용 가능성은 낮지만, [실측 악용예측]에 따라 “hard” 난이도로 분류돼 감시 필요(우선순위는 “monitor”) → 탐지 규칙 활성화와 로그 수집을 지속한다.

• 인시던트 대응 플레이북 (핵심 흐름)

  1. dmesg·/var/log/kern.log 에서 erofs.*deadlock 알림 발생 시 즉시 확인.
  2. 해당 호스트에서 ps -ef | grep erofs 로 관련 프로세스·마운트 상태 파악.
  3. 필요 시 systemctl isolate rescue.target 으로 최소 서비스 모드 전환 후, 문제 이미지 언마운트.
  4. 즉시 차단 조치(모듈 비활성화) 적용 여부 검토 및 실행.
  5. 장기 해결을 위해 커널 업데이트 일정 수립·실행.

[교차검증] 다중 소스에서 일관된 정보가 확인되어 위 내용은 보수적으로 높은 값을 채택하지 않고 그대로 기술했습니다.
[실측 악용예측] EPSS 0.00182와 “hard” 난이도는 실제 공격 시도가 드물지만, 로컬 DoS 위험을 무시할 수 없음을 의미합니다.
[우선순위 결정] CVSS 5.5·non‑KEV·EPSS 0.00182·exploit hard·in_scope=None 에 기반해 “모니터링”이 기본 방침이며, 즉시 차단을 통해 위험을 최소화하도록 권고합니다.

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