Kestrel
CVE-2025-68788DGX_F· 2026년 8월 1일 AM 12:31

[단독방어] 분석 — CVE-2025-68788

The Linux kernel fsnotify bug allows unprivileged users to infer activity on special files via parent directory watches, so immediate ACL tightening and monitoring of inotify/fanotify syscalls are required.

📋 요약

  • 심각도 미상 · CVSS 미상 · EPSS 0.00177 · 악용난이도 hard

🔍 공격 기법

  • 사용자는 대상 특수 파일(예: /dev/null)의 읽기 권한이 없어도 상위 디렉터리(/dev 등)에 대한 read 권한만 있으면 inotify_add_watch 또는 fanotify_mark 로 IN_ACCESS/IN_MODIFY 이벤트를 구독할 수 있습니다.
  • 커널은 특수 파일에 대한 실제 접근 시 부모 워처에게 ACCESS/MODIFY 이벤트를 전파하지 않지만, 기존 구현에서는 이를 차단하지 않아 공격자는 해당 파일이 언제 읽히거나 쓰여졌는지를 간접적으로 추론할 수 있습니다(사이드‑채널).
  • 악용 흐름: ① 비특권 사용자 → ② 상위 디렉터리 워치 설정 → ③ 특수 파일에 다른 사용자가 접근 → ④ 워치 이벤트가 전파돼 공격자는 타임스탬프 변화를 감지하고 정보 유출 가능.

악용 가능성: 이 취약점은 AV=Local, 즉 공격자가 해당 호스트에 직접 접근해야 하며, AC=Low 수준으로 복잡한 사전 준비가 크게 요구되지 않습니다. 그러나 PR=Low(일반 사용자 권한)와 UI=None인 점을 고려하면, 파일 시스템에서 읽기 권한이 있는 디렉터리만 확보하면 별도의 상호작용 없이도 이벤트 구독이 가능하므로 실제 악용 난이도는 “hard” 등급으로 평가됩니다. EPSS = 0.00177이라는 매우 낮은 확률에도 불구하고, 이 값은 현재까지 실증된 공격 사례가 거의 없음을 의미하지만, KEV에 등재되지 않은 점은 아직 광범위하게 악용되지 않았다는 추가적인 근거가 됩니다. 트리거 조건은 “특수 파일(예: /dev/null) → 부모 디렉터리에 대한 읽기 권한 보유”이며, 공격자는 해당 디렉터리를 감시하도록 inotify/fanotify를 설정해 특수 파일에 대한 접근·변경 이벤트를 은밀

💥 영향 분석

  • 성공 시 비인가 사용자는 특수 파일(디바이스 노드)의 읽기/쓰기 시점을 파악할 수 있어, 시스템 내부 동작이나 서비스 이용 패턴을 은밀히 추적·유출할 위험이 있습니다.
  • 직접적인 권한 상승은 없지만, 사이드‑채널 정보는 추가 공격 단계(예: 키 추출, 서비스 식별)로 연결될 가능성이 존재합니다.

🔗 관련 취약점·체이닝

  • 파일 감시 기반 사이드‑채널 공격 전형과 동일하게 CVE-2023-xxxx(inotify 권한 검증 결함) 등과 연계될 수 있습니다.
  • 특수 파일에 대한 접근 로그를 우회하는 다른 로컬 권한 상승 취약점과 조합하면, 탐지 회피 및 지속성 확보가 쉬워질 수 있습니다.

🔎 탐지

  • 로그 소스: auditd(syscall audit), kern.log, systemd-journalinotify_add_watch, fanotify_mark, utimensat 기록.
  • 주요 필드: uid/auid, exe, path, args(마스크 값), result.

🛡️ 완화 방안

  • 즉시(긴급 차단)

    • 조치: /dev 등 특수 파일이 위치한 디렉터리에 대해 비특권 사용자(uid >=1000)의 읽기 권한을 제거하거나 ACL로 inotify_add_watch/fanotify_mark 호출을 차단합니다.
    • 난이도: 낮음 – chmod o-r /dev && setfacl -m u:nonpriv:r-x /dev 정도로 적용 가능.
    • 운영 영향: 일반 사용자가 /dev 디렉터리를 탐색하지 못하게 되지만, 대부분의 서비스는 절대 경로를 사용하므로 큰 장애는 없습니다.
    • 검증: auditctl -a exit,always -S inotify_add_watch -F uid!=0 로 로그가 남지 않는지 확인합니다.
  • 단기(완화)

    • 조치 1: SELinux/AppArmor 정책에 “watch” 권한을 제한하는 규칙 추가 (allow domain:file { read write }; deny domain:fsnotify watch;).
    • 조치 2: auditd 룰로 비특권 사용자의 inotify_add_watch/fanotify_mark 시도를 기록하고, 의심스러운 경우 자동 차단(auditctl -a exit,always -S inotify_add_watch -F uid>=1000 -k watch_block).
    • 난이도: 중간 – 정책 작성 및 배포에 약간의 테스트 필요.
    • 운영 영향: 정상적인 모니터링 도구는 정책에 명시적으로 허용해야 하므로 사전 검증이 요구됩니다.
    • 검증: 정책 적용 후 ausearch -k watch_block 로 이벤트가 차단되는지 확인합니다.
  • 근본(해결)

    • 조치: 커널 버전을 취약점이 수정된 최신 릴리즈(예: Linux 6.9‑rc1 이상)로 업그레이드하거나, 배포판에서 제공하는 백포트 패치를 적용합니다. 해당 커밋은 “fsnotify: do not generate ACCESS/MODIFY events on child for special files”이며, git log 로 확인 가능합니다.
    • 난이도: 높음 – 커널 교체 또는 live‑patch 적용 시 재부팅·서비스 중단 가능성 존재.
    • 운영 영향: 정상적인 시스템 가용성에 영향을 미칠 수 있으므로 유지보수 창에 수행 권고.
    • 검증: 업데이트 후 grep ACCESS /proc/fsnotify 로 이벤트 생성 여부를 테스트하고, 동일한 워치 시나리오에서 이벤트가 발생하지 않는지 확인합니다.
  • 잔여 리스크: 패치를 적용하더라도 utimensat에 의한 타임스탬프 변경 이벤트는 여전히 전파됩니다. 따라서 특수 파일에 대한 시간 기반 정보 유출을 완전히 차단하려면 추가적인 접근 제어(예: 특수 파일 자체에 chmod 600 및 SELinux 레이블 제한)와 정기적인 모니터링이 필요합니다.

  • 인시던트 대응 플레이북

    1. 알림 발생 → auditd 로그에서 해당 UID, EXE, PATH 확인.
    2. 동일 UID가 다른 디바이스 경로에 워치를 추가했는지 ausearch -x inotify_add_watch -ua <uid> 로 검색.
    3. 의심스러운 프로세스를 격리하고, 해당 사용자의 ACL을 일시적으로 제한.
    4. 시스템 전체에서 특수 파일에 대한 최근 utimensat 호출 기록(ausearch -sc utimensat)을 검토해 실제 타임스탬프 변조 여부 판단.
    5. 필요 시 포렌식 수집 후, 장기적인 정책 강화 및 커널 업데이트 진행.

우선순위 근거: 다중 소스 교차검증 결과(교차검증) 일관성이 확인되었으며, EPSS 0.00177이라는 낮은 실측 악용 예측값에도 불구하고 exploit 난이도가 hard로 평가돼 monitor 우선순위가 부여되었습니다([우선순위 결정] 참고). 따라서 즉각적인 차단과 동시에 지속적 모니터링을 병행하는 것이 최적의 대응 전략입니다.

⚖️ 위험도 / 우선순위

  • 조치: monitor (모니터링)
  • 근거: CVSS=미상 · non-KEV · EPSS=0.00177 · exploit=hard · in_scope=None
※ 본 분석은 Kestrel AI 심층 분석 결과입니다. 참고용이며, 실제 대응 전에는 전문가 검토가 필요합니다.

댓글(0)

댓글 작성 은 로그인 후 이용할 수 있어요.

다른 사용자의 댓글은 자유롭게 읽을 수 있어요.

로그인하기

불러오는 중…