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

• 심각도 high · CVSS 8.0 · EPSS 0.00368 · 악용난이도 hard

NFSv4 클라이언트가 CREATE/SETATTR RPC에 POSIX ACL(명시된 프린시펄 포함) 정보를 포함하면, NFSD는 nfsd_create_setattr() → nfsd_attrs_valid() 흐름을 타지만 해당 함수는 ACL 변화를 검사하지 않는다. 결과적으로 nfsd_attrs_valid()가 false를 반환해 nfsd_setattr()이 호출되지 않아 ACL가 inode에 기록되지 않는다. 클라이언트가 이후 GETACL 요청을 하면, 서버는 파일 모드 비트 기반의 기본 ACL만 반환한다.

악용 가능성: 이 취약점은 AV:N(네트워크를 통한 원격 접근)이며, 공격자는 NFSv4 서버에 직접 TCP 2049 포트로 접속할 수 있어야 합니다. AC:L·PR:L 조합으로 보면, 공격자는 NFS 마운트를 수행하고 파일을 생성할 권한만 있으면 충분히 이용 가능하므로 특권 상승 없이도 시도가 가능합니다. 다만 UI:R가 요구되는데, 이는 피해자의 NFS 클라이언트에서 ACL 설정을 포함한 파일 생성 요청이 실행되어야 함을 의미합니다(예: 사용자가 공유 디렉터리에 파일을 저장할 때

• 의도한 접근 제어가 적용되지 않아 권한 상승 및 무단 읽·쓰기·삭제가 가능해짐.
• 민감 데이터가 저장된 디렉터리에서 ACL 누락 파일이 존재하면, 해당 파일에 대한 기밀성·무결성이 손상될 위험이 있음.
• 이미 생성된 파일 중 취약점으로 인해 ACL이 누락된 경우, 패치 적용 전까지 지속적인 권한 노출이 남는다 (잔여 리스크).

• 동일 커널 라인에서 보안 레이블 검증을 놓치는 nfsd_setattr() 호출 건너뛰기와 결합될 경우, 복수 속성(ACL + 보안 라벨) 누락으로 권한 상승 폭이 확대될 수 있다.

• 로그 소스

  • auditd syscall 로그: type=SYSCALL, exe=/usr/sbin/nfsd, syscall=nfsd_create_setattr, args에 "acl=" 문자열 포함 여부.
  • NFS 서버 데몬 로그 (/var/log/syslog 또는 /var/log/nfsd.log): RPC 호출 레코드에 proc=CREATE와 attrs 필드에 acl= 혹은 POSIX_ACL가 나타남.

• SIEM 탐지 규칙 예시

  1. Elastic/Kibana 쿼리:

 1event.category:"audit"
 2and process.name:"nfsd_create_setattr"
 3and auditd.syscall.args:*acl=*
 4and NOT (event.action:"setattr" and auditd.syscall.args:*acl=*)

1. Splunk 검색:

 1index=nfsd sourcetype=syslog "proc=CREATE" ("acl=" OR "POSIX_ACL")
 2| stats count by client_ip, export_path

1. 파일 시스템 정기 스캔 (스케줄러에 등록): find /export -type f ! -exec getfacl --skip-base {} + -print → 결과를 CSV로 SIEM에 적재하고 “ACL 없음” 알림 트리거.

• 오탐 튜닝
  • 정상적인 클라이언트가 ACL 없이 파일을 생성하는 경우는 auditd 로그에서 acl= 문자열이 실제 전송된 경우만 매칭하도록 조건 추가.
  • 스캔 시 백업·테스트 디렉터리를 -path /backup -prune 등으로 제외해 불필요한 경고 감소.

• 즉시(긴급 차단): NFSv4에서 POSIX ACL 적용을 비활성화한다.
  방법: 모든 NFS 마운트에 noacl 옵션을 추가하거나, 커널 파라미터 fs.posix_acl=0 로 설정하고 nfsd 재시작.
  검증: /proc/mounts에 noacl 플래그 확인 후, getfacl <파일>이 “default:”만 반환되는지 테스트.

• 단기(패치 전까지)

  1. 감사 로깅 강화 – auditd에 아래 규칙 추가: -a always,exit -F exe=/usr/sbin/nfsd -S all -k nfs_acl_audit. 수집된 로그를 위 SIEM 규칙으로 모니터링하고, 알림 발생 시 자동화 스크립트로 해당 파일에 기본 제한 ACL(chmod 700 또는 setfacl -m u::rw,g::---,o::---)을 적용한다.
  2. 취약 파일 정리 – 위 “파일 시스템 정기 스캔”을 4시간마다 실행하고, 누락된 ACL 리스트에 대해 즉시 권한 재설정 또는 격리 조치를 수행한다. 운영 영향은 I/O 부하가 일시적으로 증가하지만, 스케줄링으로 업무 시간 외에 진행 가능.
  3. 네트워크 접근 제한 – 방화벽에서 NFSv4 포트(2049) inbound를 신뢰된 내부 서브넷만 허용하고, 외부 IP는 차단한다. 이는 공격자가 원격에서 ACL 포함 CREATE 요청을 보내는 경로를 차단함.

• 근본(장기)

  • 공급업체가 제공하는 커널 패치를 적용한다 (CVE-2025-68803 수정 포함). 패치 전후에 nfsd_create_setattr 로직이 ACL 변화를 올바르게 검증하는지 테스트 환경에서 확인 후 프로덕션에 롤아웃.
  • 패치 적용 후 noacl 옵션을 제거하고 정상적인 POSIX ACL 기능을 복구한다. 검증 방법: 파일 생성 시 ACL 지정 → getfacl 결과가 요청한 ACL과 일치하는지 확인.

구현 난이도·운영 영향

• 긴급 차단(noacl) – 낮은 난이도, 서비스 재시작 필요하지만 가용성에 큰 영향을 주지 않음.
• 감사 로깅 및 정기 스캔 – 중간 난이도, 추가 I/O와 로그 저장소 사용; 검증은 로그 수집 여부와 스크립트 성공률 확인.
• 패치 적용 – 높은 난이도(커널 재부팅 필요)·가용성 일시 중단 위험; 사전 테스트와 롤백 플랜 필수.

검증 방법 요약: ① noacl 설정 여부 → /proc/mounts; ② audit 로그에 ACL 요청 기록 유무 → SIEM 대시보드; ③ 패치 후 파일 생성·GETACL 정상 동작 확인 → setfacl + getfacl.

잔여 리스크: noacl 상태에서는 모든 POSIX ACL 보호가 비활성화되므로, 기존에 ACL을 의존해 격리된 데이터는 일시적으로 무방어 상태가 된다. 따라서 패치 적용 시점까지 최소한 신뢰된 서브넷만 NFSv4를 허용하고, 정기적인 파일 권한 검증을 병행해야 한다.

• 조치: scheduled (이번 주 내)
• 근거: CVSS=8.0 · non-KEV · EPSS=0.00368 · exploit=hard · in_scope=None