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

Home NTFSD

Before Posting...

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

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/


Best strategy to determine if a binary file is being executed from a "user writable" location

Marco_Peretti-2Marco_Peretti-2 Member Posts: 2

I am working on yet-another app control PoC and am pretty happy with the results so far.

I am however not sure about the best way to go when it comes to detecting if the PE image is being mapped for execution from a location where non-admin user have write access. It seems I can check the security descriptor in IRP_MJ_CREATE but there i can't really (or easily) tell whether the file is a PE file and whether it will be loaded for exec.

In my mini-filter driver, I also have pre/post for IRP_MJ_CREATE and IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION, plus process and image callbacks. Is checking the SD against the user token when its image gets mapped (for section sync) correct?

my needs:

. Apply policy X if exe is run from user-writable location. policy could be evaluated during process creation or image load callbacks
. Apply policy Y if DLL is loaded from user-writable location. policy could be evaluated during callbacks, or perhaps even during IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION

thank you in advance for any tip/suggestion.

Marco

Comments

  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,266

    My feeling is that you are going to have problems with "Apps". IIRC These can be installed by anyone and are installed to the users' programdata.
     
    Knowing enough to know that the NT security model is pretty complicated I would BF&I it - on every open for execute I would (in post create) try to open for write with the "don't check sharing" and the "force security check" bits set (checking for non elevated users only if you wish). If it succeeds then mark the StreamContext appropriately.
     
    Then do a lookup wherever you feel like it. You could even detect that the file **had **been opened for execute.

    But that really is brute force and ignorance

  • Marco_Peretti-2Marco_Peretti-2 Member Posts: 2

    Thanks Rod,

    using a stream context would indeed work well but I need to see how it would affect the current design.

    I am also thinking about TOCTOU scenarios where the attacker could write a file to disk, change the SD and then run it. I may also have to check the file owner and who knows what else.

    anyway, thanks for the suggestion.

    Marco

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!
Kernel Debugging 13-17 May 2024 Live, Online
Developing Minifilters 1-5 Apr 2024 Live, Online
Internals & Software Drivers 11-15 Mar 2024 Live, Online
Writing WDF Drivers 20-24 May 2024 Live, Online