Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTFSD

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

Protection against TOCTOU attacks for win32 API

AlbertAlbert Member - All Emails Posts: 504

Recently a security researcher sent us a CVE in our code where we are trying to use windows DeleteFileW and MoveFileW APIS and the researcher claims that they have scripts/code which can hijack the path sent to these APIs and replace them with symbolic links to windows system32 files or other sensitive files causing us to delete or move them. Our code runs as a privileged service and hence we need to prevent this kind of attack.

Since we are using Win32 APIs what is the best way forward? Our service needs to work on Win7 and above.

Comments

  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,210

    I'm not sure I understand your problem.

    If your program is being attacked such that a path is being corrupted, isn't the correct course of action to stop the name being changed? If the problem is that DeleteFileW is deleting the wrong file then I think the WIN32 development team need to know...

    If you have a problem which is "I get a file name - I establish that this file name is one I am interested in, but when I delete the name isn't correct" then I do not understand how this can happen: if it is a hard link then it is the link that is removed, if it is a soft link (of any sort) then ditto.

    But regardless you could consider getting a HANDLE to the file, do all the tests on the HANDLE and then if its what you want issue a NtSetFileInformation to FileDispositionInformation.

  • AlbertAlbert Member - All Emails Posts: 504

    @rod_widdowson said:

    But regardless you could consider getting a HANDLE to the file, do all the tests on the HANDLE and then if its what you want issue a NtSetFileInformation to FileDispositionInformation.

    This is what we now intend to do now, and drop using DeleteFile, which takes a path, and not a handle to the file name. However, rolling our own MoveFile is more complex than DeleteFileW.

  • Pavel_APavel_A Member Posts: 2,798

    the researcher claims that they have scripts/code which can hijack the path sent to these APIs and replace them with symbolic links to windows system32 files or other sensitive files causing us to delete or move them.

    The question is, can they do this from non-privileged context or not? If they can create a link to a privileged file and you use it to write/delete thing, maybe keep all your data in places protected by proper ACLs.
    If you write or delete files in places writable by non-privileged users, double check the filename/path after opening, as rod_widdowson advises.

    For example after you open c:\users\dodo\foo.txt, call GetFinalPathNameByHandle and see if the path still is c:\users\dodo rather than in \windows\system32.

    --pa

  • senninsennin Member Posts: 6

    @Albert said:
    Recently a security researcher sent us a CVE in our code where we are trying to use windows DeleteFileW and MoveFileW APIS and the researcher claims that they have scripts/code which can hijack the path sent to these APIs and replace them with symbolic links to windows system32 files or other sensitive files causing us to delete or move them. Our code runs as a privileged service and hence we need to prevent this kind of attack.

    Since we are using Win32 APIs what is the best way forward? Our service needs to work on Win7 and above.

    hi,
    did you mean Dll Hijack happen?

  • AlbertAlbert Member - All Emails Posts: 504

    @Pavel_A said:

    the researcher claims that they have scripts/code which can hijack the path sent to these APIs and replace them with symbolic links to windows system32 files or other sensitive files causing us to delete or move them.

    The question is, can they do this from non-privileged context or not? If they can create a link to a privileged file and you use it to write/delete thing, maybe keep all your data in places protected by proper ACLs.
    If you write or delete files in places writable by non-privileged users, double check the filename/path after opening, as rod_widdowson advises.

    For example after you open c:\users\dodo\foo.txt, call GetFinalPathNameByHandle and see if the path still is c:\users\dodo rather than in \windows\system32.

    --pa

    Yes, we are now moving towards hybrid approach something similar to what you and Rod suggested. These are generic files, not our files, so we can not ACL protect them. The botheration is about having to roll our own APIs, which I really wanted to avoid.

  • AlbertAlbert Member - All Emails Posts: 504

    @sennin said:

    @Albert said:
    Recently a security researcher sent us a CVE in our code where we are trying to use windows DeleteFileW and MoveFileW APIS and the researcher claims that they have scripts/code which can hijack the path sent to these APIs and replace them with symbolic links to windows system32 files or other sensitive files causing us to delete or move them. Our code runs as a privileged service and hence we need to prevent this kind of attack.

    Since we are using Win32 APIs what is the best way forward? Our service needs to work on Win7 and above.

    hi,
    did you mean Dll Hijack happen?

    in our case, not specifically DLLs, but yes, that happen also happen.

  • Martin_DrábMartin_Dráb Member - All Emails Posts: 86

    GetFinalPathNameByHandle

    Yeah, Windows uses this approach when a privileged service is trying to verify that it opened (and is preparing to work with) the intended file. You may also find checking of file hard link count (which is now kinda obsolete because it is no longer possible to create hardl inks without the FILE_WRITE_ATTRIBUTES access right).

    Also, you may consider taking advantage of user impersonation. For example, if your service receives input from an unprivileged process, it may impersonate its user (e.g. ImpersonateNamedPipeClient) in order not to operate with higher privileges. In that case, the service will not be able to delete system files simply because the user has no rights to do so.

    Martin Dráb

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Internals & Software Drivers 15 November 2021 Live, Online
Writing WDF Drivers TBD Live, Online
Developing Minifilters 7 February 2022 Live, Online
Kernel Debugging 21 March 2022 Live, Online