파일이 거부했지만, Cloud Files는 대체(supersede)했다.

CVE-2026-83991 은 Windows Cloud Files 변조 취약점으로, 공개된 영향 범위는 Windows 10 버전 1809부터 시작되며, 이는 2026년 9월 패치보다 거의 8년 앞선 시점입니다.

Windows에 파일을 쓰기 위해 열어 달라고 요청했습니다. 응답은 ERROR_ACCESS_DENIED였습니다.

같은 파일을 삭제해 달라고 요청했습니다. 역시 ERROR_ACCESS_DENIED였습니다.

그런 다음 Cloud Files 스택에 해당 파일 이름을 대체(supersede)하도록 요청했습니다. S_OK를 반환하며 기존 파일을 Cloud Files 자리 표시자(placeholder)로 변경했습니다.

파일은 두 번이나 거부했습니다. 대체 경로는 "계속 진행해 주세요"에 가까운 응답을 들은 셈입니다.

그 인증 분할(authorization split)이 CVE-2026-83991입니다. Microsoft는 이를 Windows Cloud Files 미니 필터 드라이버 변조 취약점(Windows Cloud Files Mini Filter Driver Tampering Vulnerability) 이라고 부르며, 심각도를 Important(중요) 로 평가하고 CVSS 3.1 기본 점수 5.5 Medium(중간) 을 부여했습니다. 공식 벡터는 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N/E:U/RL:O/RC:C입니다.

요약

개념 증명(PoC)은 새 디렉터리와 일반 파일을 생성합니다. 호출자에게 디렉터리에 대한 쓰기 권한을 부여한 다음, 파일에 보호된 DACL을 적용하여 호출자에게 일반적인 쓰기 또는 삭제 권한 없이 읽기 권한만 부여합니다.

제한된 중간 무결성(medium-integrity) 스레드 토큰 하나를 사용하여 다음 순서를 증명합니다:

호출은 하나의 항목을 처리했고, 0이 아닌 생성 USN을 반환했으며, 파일에 IO_REPARSE_TAG_CLOUD 태그(값 0x9000001A)를 부여했습니다. 재현 실행에서 파일 ID는 호출 전후로 동일했습니다. 동일한 NTFS 파일이 Cloud 자리 표시자 상태로 변경되는 동안 유지되었습니다.

Cloud Files 간단 지도

Windows 10 버전 1709에서 Cloud Files API가 도입되었습니다. 데스크톱 동기화 엔진이 디렉터리 트리를 등록하고, 자리 표시자 항목을 만들고, 필요할 때 콘텐츠를 하이드레이션(hydrate)할 수 있는 지원되는 방법을 제공합니다.

여기서 중요한 세 가지 요소:

• CldApi.dll은 사용자 모드 Cloud Filter API를 노출합니다.
• cldflt.sys는 스토리지 경로의 중심에 있는 파일 시스템 미니필터입니다.
• 동기화 루트(sync root) 는 동기화 공급자가 관리하는 등록된 디렉터리 트리입니다.

Cloud 자리 표시자는 재분석 지점을 사용합니다. 재분석 지점은 태그와 관련 데이터가 있는 파일 시스템 메커니즘입니다. 심볼릭 링크보다 더 넓은 개념이며, 둘을 동의어로 취급해서는 안 됩니다.

관련 API는 CfCreatePlaceholders입니다. 등록된 동기화 루트 아래에 하나 이상의 자리 표시자 파일 또는 디렉터리를 생성합니다. Microsoft 문서에 따르면 호출자는 기본 디렉터리에 대한 WRITE_DATA 또는 WRITE_DAC 액세스 권한이 있어야 합니다.

항목별 플래그 CF_PLACEHOLDER_CREATE_FLAG_SUPERSEDE(값 0x4)는 기존 자리 표시자에 대한 덮어쓰기 의미론을 제공합니다. 이 CVE의 흥미로운 세부 사항은 취약한 경로가 일반 기존 파일도 수용하여 자리 표시자로 변환했다는 점입니다.

부모 권한은 리프(leaf) 권한이 아님

이 실험은 디렉터리에 대한 권한과 기존 파일에 대한 권한을 분리합니다.

부모 디렉터리는 현재 사용자에게 다음을 부여합니다:

FILE_GENERIC_READ
FILE_GENERIC_WRITE
FILE_GENERIC_EXECUTE
DELETE

디렉터리의 경우 FILE_GENERIC_WRITE에는 FILE_WRITE_DATA(또는 FILE_ADD_FILE)가 포함됩니다. 이는 CfRegisterSyncRoot 및 CfCreatePlaceholders에서 사용하는 문서화된 기본 디렉터리 요구 사항을 충족하기에 충분합니다.

부모 ACE는 FILE_DELETE_CHILD를 부여하지 않습니다. 해당 DELETE 비트는 부모 개체 자체에 적용됩니다. 이 구분은 DeleteFileW가 대상 파일에 대한 DELETE 또는 부모에 대한 FILE_DELETE_CHILD를 요구하기 때문에 중요합니다.

기존 리프는 현재 사용자에게 FILE_GENERIC_READ만 부여합니다. 해당 DACL은 PROTECTED_DACL_SECURITY_INFORMATION으로 보호 표시되어 있으므로 부모의 ACE를 상속하지 않습니다.

이로 인해 핵심 질문이 생깁니다:

디렉터리에 새 자식을 생성할 권한이, 이미 존재하는 더 제한적인 자식에 대한 상태 변경 대체 작업도 승인합니까?

일반 파일 액세스는 아니오라고 답합니다. 취약한 Cloud Files 경로는 예라고 답했습니다.

Microsoft의 파일 보안 문서는 이러한 구분이 예상되는 이유를 설명합니다. 파일에 대한 액세스는 일반적으로 해당 파일의 보안 설명자에 의해 제어됩니다. 부모의 설명자는 상속 및 FILE_DELETE_CHILD와 같은 특정 규칙을 제외하고 일반적으로 자식의 액세스 검사를 대체하지 않습니다.

토큰은 그대로 유지됨

액세스 제어 시연은 설정이 한 ID로 실행되고 흥미로운 작업이 다른 ID로 실행될 때 설득력을 잃습니다. 이 PoC는 그 문제를 피합니다.

현재 프로세스 토큰에서 제한된 토큰을 파생하고, Administrators SID를 없거나 거부 전용(deny-only)으로 만들고, 중간 무결성을 설정하고, SecurityImpersonation에서 가장(impersonation) 토큰을 복제한 다음, SetThreadToken으로 현재 스레드에 설치합니다.

정확한 권한 표현은 주의가 필요합니다. DISABLE_MAX_PRIVILEGE와 함께 CreateRestrictedToken은 SeChangeNotifyPrivilege를 제외한 모든 권한을 비활성화합니다. 남은 권한은 일부 디렉터리 탐색 검사를 우회합니다. 파일 데이터 쓰기 또는 삭제 권한을 부여하지는 않습니다.

그런 다음 PoC는 동일한 스레드 가장 토큰이 활성 상태인 동안 설정, 제어 검사, 동기화 루트 등록, 연결 및 대체 호출을 수행합니다. "액세스 거부"와 S_OK 사이에 편리한 ID 전환이 없습니다.

PoC 살펴보기

전체 소스는 main_poc.c에 있으며, GCC 또는 Microsoft C 컴파일러용 build.bat이 포함되어 있습니다.

1. 새 네임스페이스로 시작

프로그램은 현재 사용자의 로컬 애플리케이션 데이터 디렉터리 아래에 GUID 이름의 새 테스트 디렉터리를 생성합니다. 선택적 경로를 제공할 수 있지만, 이미 존재하는 경로는 사용을 거부합니다.

이 제한은 의도적입니다. PoC는 자체적으로 생성한 데이터에 대해 버그를 시연합니다. 설치된 타사 동기화 공급자가 필요하지 않으며 기존 동기화 루트를 대상으로 하지 않습니다.

2. 일반 파일 생성

프로그램은 protected_existing.bin을 생성하고, 알려진 테스트 데이터를 쓰고, 일반 파일 특성을 부여합니다. 파일의 기본 메타데이터, 논리적 크기, 특성 및 파일 ID를 기록합니다.

Cloud Files 호출 전에 파일은 재분석 지점이 아닙니다.

3. DACL 적용 및 확인

프로그램은 리프 DACL을 상속되지 않는 세 개의 허용 ACE로 대체합니다:

유효 토큰의 Administrators SID가 없거나 거부 전용이므로 Administrators 허용 ACE는 스레드에 관리자 액세스를 부여할 수 없습니다.

그런 다음 PoC는 세 가지 제어를 수행합니다. GENERIC_WRITE는 오류 5로 실패하고, DeleteFileW는 오류 5로 실패하며, GENERIC_READ는 성공합니다. 또한 DACL이 보호되었는지 확인합니다.

이러한 제어는 두 일반 작업에 사용된 권한을 증명합니다. PoC는 WRITE_DAC 또는 합성 테스트 파일의 소유자가 해당 파일에 영향을 줄 수 있는 모든 가능한 방법을 테스트하지 않습니다. 입증된 불일치는 거부된 쓰기 및 삭제 작업과 성공적인 Cloud Files 대체 작업 사이에 구체적으로 존재합니다.

4. 최소 동기화 공급자 되기

PoC는 새 디렉터리를 점진적 하이드레이션 정책과 전체 채우기 정책으로 등록합니다. 공급자 및 루트 ID로 새 GUID를 제공합니다.

그런 다음 종료 CF_CALLBACK_NONE 항목만 포함하는 콜백 테이블로 CfConnectSyncRoot를 호출합니다. 테스트 중인 메타데이터 전환에는 하이드레이션 콜백이 필요하지 않습니다.

5. 대체 요청

자리 표시자 항목은 원본 파일의 타임스탬프와 논리적 크기를 보존하고, GUID 파일 ID를 제공하며, 공식 대체 플래그에 매핑되는 로컬 상수를 설정합니다:

#define CF_CREATE_SUPERSEDE 0x00000004UL

placeholder.RelativeFileName = leaf_name;
placeholder.FsMetadata.BasicInfo = basic_info;
placeholder.FsMetadata.FileSize = standard_info.EndOfFile;
placeholder.FileIdentity = &run_id;
placeholder.FileIdentityLength = sizeof(run_id);
placeholder.Flags = CF_CREATE_SUPERSEDE;

create_hr = cf.Create(root, &placeholder, 1, 0, &processed);

소스는 CldApi.dll을 동적으로 로드하고 런타임에 공용 함수를 해석합니다. 수동 선언된 구조체는 이 테스트에 필요한 ABI만 포함합니다.

6. 너무 일찍 축하하지 않기

배치 API는 실패한 항목을 처리할 수 있습니다. Microsoft 문서는 EntriesProcessed에 실패한 항목이 포함된다고 명시적으로 말하므로 값 1만으로는 성공을 입증할 수 없습니다.

따라서 PoC는 CONFIRMED를 출력하고 코드 0으로 종료하기 전에 다음 모든 조건을 요구합니다:

• CfCreatePlaceholders가 정확히 S_OK를 반환합니다.
• 개별 항목 결과가 정확히 S_OK입니다.
• 하나의 항목이 처리되었습니다.
• 생성 USN이 0이 아닙니다.
• 결과 파일이 존재하고 FILE_ATTRIBUTE_REPARSE_POINT를 가집니다.
• FSCTL_GET_REPARSE_POINT가 IO_REPARSE_TAG_CLOUD를 반환합니다.

직접 쓰기, 삭제, 읽기, DACL 및 기존 파일 검사도 프로그램 초기에 통과해야 하며, 그렇지 않으면 Cloud Files 작업 전에 실행이 중지됩니다.

디스크에서 변경된 사항

재현된 상태 전환:

0x00000020은 FILE_ATTRIBUTE_ARCHIVE입니다. 결과 0x00401600 마스크에는 FILE_ATTRIBUTE_SPARSE_FILE, FILE_ATTRIBUTE_REPARSE_POINT, FILE_ATTRIBUTE_OFFLINE 및 FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS가 포함됩니다.

변경되지 않은 파일 ID는 특히 유용합니다. 이 실행에서 결과가 단순히 동일한 경로 이름에 나타난 다른 파일이 아님을 보여줍니다. 기존 파일 개체는 Cloud Files 상태를 획득하면서 유지되었습니다.

프로그램은 논리적 파일 크기를 보존하지만 변환 후 원본 바이트를 검증하지는 않습니다. 이 PoC에서 임의 콘텐츠 제어에 대한 주장은 나오지 않습니다.

인증 실패가 위치한 곳

관찰 가능한 실패는 내부 호출 스택을 발명하지 않고도 설명할 수 있습니다:

1. 호출자는 기본 디렉터리를 등록하고 자식을 생성할 수 있는 충분한 권한을 가집니다.
2. 기존 리프의 현재 DACL은 테스트된 쓰기 및 삭제 작업을 거부합니다.
3. CfCreatePlaceholders는 해당 리프에 대한 대체 요청을 수용합니다.
4. CldFlt는 리프를 Cloud Files 자리 표시자로 변경합니다.

이 동작은 대체 경로에서 기존 리프에 대한 검사가 없거나 불완전한 것과 일치합니다. 책임이 있는 정확한 내부 함수, 분기, IRP 또는 커널 콜백을 식별하지는 않습니다. PoC에는 커널 디버깅이나 바이너리 차이 분석이 포함되어 있지 않으므로 설명은 외부적으로 검증된 경계에서 멈춥니다.

Microsoft는 CWE-306, 핵심 기능에 대한 인증 누락(Missing Authentication for Critical Function)을 지정했습니다. Windows 개체 수준에서 이 실험은 일관되지 않은 인증 시행을 노출합니다. 메타데이터에는 Microsoft의 공식 CWE를 사용하고 기술 분석에서는 관찰된 액세스 제어 동작을 설명합니다.

영향 — 형용사는 짧게 유지

PoC는 테스트된 직접 작업이 수행할 수 없었던 무결성 및 파일 상태 변경을 시연합니다. 필요한 기본 디렉터리 액세스 권한이 있는 로컬 저권한 호출자는 영향을 받는 경로를 통해 기존 읽기 전용 리프를 Cloud Files 자리 표시자로 만들 수 있습니다.

Microsoft의 권고는 더 넓은 제품 영향을 제공합니다: 공격자는 보호된 시스템 데이터에 무단 변경을 가하고 정상 권한을 넘어 시스템 상태 또는 구성을 변경할 수 있습니다. 이는 취약점에 대한 Microsoft의 평가입니다. 격리된 PoC는 보호된 시스템 대상을 선택하거나 완전한 사후 악용 체인을 시연하지 않습니다.

CVSS 벡터는 동일한 넓은 형태를 반영합니다:

• 로컬 공격 벡터
• 낮은 공격 복잡성
• 낮은 권한 필요
• 사용자 상호 작용 없음
• 높은 무결성 영향
• 기밀성 또는 가용성 영향 주장 없음

얼마나 오래 전부터인가?

신중한 답변은 Microsoft의 공개 영향 범위에서 거의 8년입니다.

공식 CVE 레코드는 가장 오래된 영향을 받는 분기를 Windows 10 버전 1809 및 Windows Server 2019의 10.0.17763.0으로 시작합니다. Microsoft의 Windows 10 릴리스 기록은 2018년 10월 2일의 첫 번째 버전 1809 빌드 17763.1을 나열합니다. Microsoft는 2026년 9월 8일에 패치를 게시했습니다.

이는 공개 범위에서 가장 이른 확인 지점이 패치보다 약 8년 전임을 의미합니다.

Cloud Files API 자체는 2017년 Windows 10 버전 1709와 함께 도입되었으며, API 문서는 1709를 최소 지원 클라이언트로 나열합니다. 이것이 이 취약점이 1709에 존재했음을 증명하지는 않습니다. Microsoft의 CVE 레코드는 1709를 나열하지 않으며, 이 연구는 이를 테스트하지 않았습니다. API의 생일이 자동으로 버그의 생일은 아닙니다. 헤드라인이 아무리 매력적이어도 말입니다.

재현

NTFS의 영향을 받는 테스트 시스템을 사용하십시오. 일반적인 비관리자 명령 프롬프트에서 PoC를 실행하십시오.

build.bat
main_poc.exe

빌드 스크립트는 사용 가능한 경우 MinGW-w64 GCC를 사용하고 그렇지 않으면 Microsoft C 컴파일러로 대체합니다. 프로그램은 자체 새 테스트 루트를 생성하고 등록합니다. 정리 중에 등록을 해제하고 연결을 끊은 다음 검사를 위해 테스트 디렉터리를 그대로 둡니다.

선택적 경로 형식:

main_poc.exe C:\path\to\a\new-test-directory

제공된 경로는 이미 존재해서는 안 됩니다. 테스트를 격리된 상태로 유지하고 결과를 수집한 후 디렉터리를 제거하십시오.

패치된 시스템에서는 전체 조건이 CONFIRMED에 도달하지 않아야 합니다. 한 줄의 콘솔 출력만으로 패치 상태를 추론하지 마십시오. 전체 결과, 종료 코드, 항목별 결과, USN, 특성 및 재분석 태그를 함께 확인하십시오.

파일 닫기

가장 흥미로운 Windows 취약점은 종종 액세스 검사가 실제로 어떤 개체에 관한 것이었는지에 대한 논쟁입니다.

여기서 디렉터리 아래에 생성할 권한이 내부에 이미 있는 더 제한적인 자식을 변환할 수 있는 경로에 도달했습니다. 일반 파일 API는 해당 자식의 현재 DACL을 존중했습니다. Cloud Files 대체는 동일한 경계를 보존하지 않았습니다.

화려한 메모리 손상은 필요하지 않았습니다. 한 개체가 아니오라고 말했고, 다른 개체가 계속할 충분한 권한을 제공했으며, 익숙한 파일 이름이 조용히 다른 것이 되었습니다.

그것이 전체 트릭입니다. 또한 그 트릭이 중요한 이유이기도 합니다.