How to prevent time-of-check-to-time-of-use bug when recursively deleting directories in Windows - Stack Overflow

admin管理员组

文章数量:1356808

Recursive deletion of directories can suffer from a time-of-check to time-of-use (TOCTTOU) vulnerability when the algorithm takes the form (pseudocode):

function removeRecursively(dirname) {
    for filename in dirname {
        if isDir(dirname + "/" + filename)
            removeRecursively(dirname + "/" + filename);
        else
            unlink(dirname + "/" + filename);
    }
    unlink(dirname);
}

Assuming isDir returns false for symlinks, the problem is that an attacker may be able to change the meaning of either dirname or filename after isDir returns true, resulting in some component in the path dirname + "/" + filename becoming a symlink. The process is therefore tricked by the attacker into removing files at some location determined by the attacker.

On Unix-like systems, the fix is to change the algorithm to something resembling

function removeRecursively(dirname) {
    removeContents(open(dirname, O_NOFOLLOW));
    unlink(dirname);
}

function removeContents(dirfd) {
    dirstream = fdopendir(dirfd);
    while (filename = readdir(dirstream)) {
        entryfd = openat(dirfd, filename, O_NOFOLLOW);
        if isDir(entryfd) removeContents(entryfd);
        unlinkat(dirfd, filename);
    }       
}

I've glossed over a bunch of details on purpose, so please don't criticize the above pseudocode.

I'm trying to figure out whether there's any similar way to harden a Windows implementation. On Windows, symlinks can ordinarily be created only by a process with administrative privileges, but it is possible for unprivileged users to create symlinks if Developer Mode is enabled. This suggests that a Windows box with Developer Mode enabled is vulnerable to CVE-2022-21658; please tell me if this is not true for some reason.

I have not been able to find a way to fix it. While this answer states that Windows has its own equivalent of openat, and perhaps doesn't require fdopendir (because Windows doesn't seem to have a separate concept of "directory streams"), Windows appears to lack a function that, given a handle to a directory (and not a path), returns the next entry in that directory. Instead it seems we only have FindFirstFile* and FindNextFile*, which operate on path strings and therefore cannot avoid the TOCTTOU problem. I couldn't find a Windows equivalent of unlinkat either.

Recursive deletion of directories can suffer from a time-of-check to time-of-use (TOCTTOU) vulnerability when the algorithm takes the form (pseudocode):

function removeRecursively(dirname) {
    for filename in dirname {
        if isDir(dirname + "/" + filename)
            removeRecursively(dirname + "/" + filename);
        else
            unlink(dirname + "/" + filename);
    }
    unlink(dirname);
}

Assuming isDir returns false for symlinks, the problem is that an attacker may be able to change the meaning of either dirname or filename after isDir returns true, resulting in some component in the path dirname + "/" + filename becoming a symlink. The process is therefore tricked by the attacker into removing files at some location determined by the attacker.

On Unix-like systems, the fix is to change the algorithm to something resembling

function removeRecursively(dirname) {
    removeContents(open(dirname, O_NOFOLLOW));
    unlink(dirname);
}

function removeContents(dirfd) {
    dirstream = fdopendir(dirfd);
    while (filename = readdir(dirstream)) {
        entryfd = openat(dirfd, filename, O_NOFOLLOW);
        if isDir(entryfd) removeContents(entryfd);
        unlinkat(dirfd, filename);
    }       
}

I've glossed over a bunch of details on purpose, so please don't criticize the above pseudocode.

I'm trying to figure out whether there's any similar way to harden a Windows implementation. On Windows, symlinks can ordinarily be created only by a process with administrative privileges, but it is possible for unprivileged users to create symlinks if Developer Mode is enabled. This suggests that a Windows box with Developer Mode enabled is vulnerable to CVE-2022-21658; please tell me if this is not true for some reason.

I have not been able to find a way to fix it. While this answer states that Windows has its own equivalent of openat, and perhaps doesn't require fdopendir (because Windows doesn't seem to have a separate concept of "directory streams"), Windows appears to lack a function that, given a handle to a directory (and not a path), returns the next entry in that directory. Instead it seems we only have FindFirstFile* and FindNextFile*, which operate on path strings and therefore cannot avoid the TOCTTOU problem. I couldn't find a Windows equivalent of unlinkat either.

• windows

Share Improve this question Follow asked Mar 27 at 19:43 Brian BiBrian Bi 120k1111 gold badges191191 silver badges346346 bronze badges 3

• you always need open file with FILE_OPEN_REPARSE_POINT option ( if use NtOpenFile) or FILE_FLAG_OPEN_REPARSE_POINT ( if use CreateFileW) as result you always create link by self, not it target – RbMm Commented Mar 27 at 20:02
• only have FindFirstFile and FindNextFile - it never must be used. also have FindFirstFileEx and NtQueryDirectoryFile which is most ower option – RbMm Commented Mar 27 at 20:06
• @RbMm I didn't know about NtQueryDirectoryFile. That seems like it could be part of a solution. Perhaps you could write an answer that shows how to use it? – Brian Bi Commented Mar 27 at 20:09

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 0

need use NtQueryDirectoryFile and always use option FILE_OPEN_REPARSE_POINT in call NtOpenFile

demo code:

NTSTATUS DeleteFile(POBJECT_ATTRIBUTES poa, ULONG FileAttributes, PCWSTR prefix)
{
    UNICODE_STRING relativeName;
    OBJECT_ATTRIBUTES oa = { sizeof (oa), 0, &relativeName };
    IO_STATUS_BLOCK iosb;

    if (FileAttributes & FILE_ATTRIBUTE_READONLY)
    {
        if (0 <= NtOpenFile(&oa.RootDirectory, FILE_WRITE_ATTRIBUTES, poa, &iosb, FILE_SHARE_VALID_FLAGS, FILE_OPEN_FOR_BACKUP_INTENT|FILE_OPEN_REPARSE_POINT))
        {
            static FILE_BASIC_INFORMATION fbi = { {}, {}, {}, {}, FILE_ATTRIBUTE_NORMAL };
            ZwSetInformationFile(oa.RootDirectory, &iosb, &fbi, sizeof(fbi), FileBasicInformation);
            NtClose(oa.RootDirectory);
        }
    }

    NTSTATUS status = NtOpenFile(&oa.RootDirectory, 
        SYNCHRONIZE|DELETE|FILE_LIST_DIRECTORY,
        poa, &iosb, FILE_SHARE_VALID_FLAGS, 
        FILE_OPEN_FOR_BACKUP_INTENT|FILE_SYNCHRONOUS_IO_NONALERT|FILE_DELETE_ON_CLOSE|FILE_OPEN_REPARSE_POINT);

    DbgPrint("%s<%wZ> [%08x]=%x\n", prefix, poa->ObjectName, FileAttributes, status);

    if (0 <= status)
    {
        if ((FileAttributes & (FILE_ATTRIBUTE_DIRECTORY|FILE_ATTRIBUTE_REPARSE_POINT)) == FILE_ATTRIBUTE_DIRECTORY)
        {
            if (*--prefix)
            {
                enum { eBufSize = 0x10000 };

                if (PBYTE buf = new BYTE[eBufSize])
                {
                    PFILE_DIRECTORY_INFORMATION pfdi = 0;

                    while (0 <= NtQueryDirectoryFile(oa.RootDirectory, 0, 0, 0,
                        &iosb, buf, eBufSize, FileDirectoryInformation, FALSE, 0, FALSE))
                    {
                        pfdi = (PFILE_DIRECTORY_INFORMATION)buf;

                        ULONG NextEntryOffset = 0;

                        do 
                        {
                            (ULONG_PTR&)pfdi += NextEntryOffset;

                            relativeName.MaximumLength = relativeName.Length = (WORD)pfdi->FileNameLength;
                            relativeName.Buffer = pfdi->FileName;

                            switch(relativeName.Length)
                            {
                            case 2 * sizeof(WCHAR):
                                if (relativeName.Buffer[1] != L'.') break;
                            case sizeof(WCHAR):
                                if (relativeName.Buffer[0] == L'.') continue;
                                break;
                            }

                            DeleteFile(&oa, pfdi->FileAttributes, prefix);

                        } while(NextEntryOffset = pfdi->NextEntryOffset);
                    }

                    delete [] buf;
                }

                ++prefix;
            }
        }

        NtClose(oa.RootDirectory);
    }

    return status;
}

NTSTATUS DeleteFolder(PCWSTR pszRoot)
{
    UNICODE_STRING ObjectName;
    OBJECT_ATTRIBUTES oa = { sizeof(oa), 0, &ObjectName, OBJ_CASE_INSENSITIVE };

    NTSTATUS status = RtlDosPathNameToNtPathName_U_WithStatus(pszRoot, &ObjectName, 0, 0);

    if (0 <= status)
    {
        AdjustPrivileges(&tp_br); 

        WCHAR prefix[MAXUCHAR + 1];
        __stosw((PUSHORT)prefix, '\t', MAXUCHAR);
        prefix[0] = 0, prefix[MAXUCHAR] = 0;

        status = DeleteFile(&oa, FILE_ATTRIBUTE_DIRECTORY|FILE_ATTRIBUTE_READONLY, prefix + MAXUCHAR);
        RtlFreeUnicodeString(&ObjectName);
 
    }
    return status;
}

always better have backup-restore privilege ( AdjustPrivileges(&tp_br); ) while we do this:

#define echo(x) x 
#define label(x) echo(x)##__LINE__ 
 
#define BEGIN_PRIVILEGES(name, n) static const union { TOKEN_PRIVILEGES name;\ 
struct { ULONG PrivilegeCount; LUID_AND_ATTRIBUTES Privileges[n];} label(_) = { n, { 
 
#define LAA(se) {{se}, SE_PRIVILEGE_ENABLED } 
 
#define END_PRIVILEGES }};}; 
 
NTSTATUS WINAPI AdjustPrivilegesP(_In_ const TOKEN_PRIVILEGES* ptp) 
{ 
    NTSTATUS status; 
    HANDLE hToken; 
 
    if (0 <= (status = NtOpenProcessToken(NtCurrentProcess(), TOKEN_ADJUST_PRIVILEGES, &hToken))) 
    { 
        status = NtAdjustPrivilegesToken(hToken, FALSE, const_cast<PTOKEN_PRIVILEGES>(ptp), 0, 0, 0); 
        NtClose(hToken); 
    } 
 
    return status; 
}; 
 
BEGIN_PRIVILEGES(tp_br, 2) 
    LAA(SE_BACKUP_PRIVILEGE), 
    LAA(SE_RESTORE_PRIVILEGE), 
END_PRIVILEGES

also possible even asynchronous delete folder , this can be visible faster for huge folder ( example )

本文标签： How to prevent timeofchecktotimeofuse bug when recursively deleting directories in WindowsStack Overflow