DismHost.exe and Software Restriction Policy

Discussion in 'other anti-malware software' started by Quango, Oct 15, 2017.

  1. Quango

    Quango Registered Member

    Joined:
    Oct 10, 2017
    Posts:
    10
    Location:
    Norway
    I'm using a software restriction policy set up with gpedit.msc where no software can run if it or the path it is in can be modified by a non-administrator. This seems like only sane way to go about things, because what happens if something sneeks in through a browser hole and modifies .exe files?

    However, Windows 10's anti malware protections seems determined to create a bunch of DismHost.exe and related executables in %Temp%, which is C:\Users\johndoe\AppData\Local\Temp.

    I have kept blocking the various DismHost.exe's but that compromises my malware protection.

    How can I move the directory where Windows 10 keeps putting DismHost.exe's so that they run from a secure path?
     
  2. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    One of the bigger problems here that is making this more difficult is the fact that SRP does not allow wildcards (such as * or ?) to account for the changing characters within the Temp directory. That would make it much easier. You may have to consider solutions other than SRP if you want that functionality.

    It has been a while since I last messed with the DISM commands, but I believe there may be an option to change the location of the Temp directory (something like [/ScratchDir:<path_to_scratch_directory>]) but my experience with it is very limited. Try searching Google for "change dism scratch directory" and see if that turns up anything worthwhile. That may have the option to change to a custom location.
     
  3. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
    I usually create hash rules and not path rules for executables that are run from user space. If you create a hash rule for dismhost.exe it wouldn't mater where it is run from. Of course you would have to update rule each time the file is updated.
     
    Last edited: Oct 15, 2017
  4. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,591
    Location:
    U.S.A.
    I solved the dismhost.exe problem by creating a HIPS rule to allow system32\cleanmgr.exe to run it from %AppData%\Temp directory. Never been a fan of SRP.
     
  5. Zorak

    Zorak Registered Member

    Joined:
    Jan 2, 2010
    Posts:
    182
    Location:
    Australian Capital Territory
    I use Excubits Bouncer to restrict software running from userland. It does everything my old SRP did but it allows the use of wildcards as mentioned by @WildByDesign. The only drawback I've found is you can't bypass the restrictions by running as an administrator, but you can turn the protection off when required - I just keep forgetting to do so :oops:
     
  6. Quango

    Quango Registered Member

    Joined:
    Oct 10, 2017
    Posts:
    10
    Location:
    Norway
    Your suggestions don't sound sound.

    Let's say you've got a browser exploit where a badguy manages to start a local process. He sets this up to scan %Temp% and modify any executable files. Now DismHost.exe comes along and now you're running the badguy's process with administrator privileges = game over.
     
  7. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
    Not if you use hash rules. If a process tempers with DismHost.exe it changes it's hash and DismHost.exe is blocked by SRP.
     
  8. Zorak

    Zorak Registered Member

    Joined:
    Jan 2, 2010
    Posts:
    182
    Location:
    Australian Capital Territory
    I also use Excubits Pumpernickel (FIDES) to whitelist the programs which are allowed write access to the DismHost.exe temp folder.

    There are separate threads discussing Bouncer and Pumpernickel elsewhere in this section of the forum if you are interested. They take a bit of getting used to, but IMHO are hidden gems for implementing SRPs.
     
  9. Quango

    Quango Registered Member

    Joined:
    Oct 10, 2017
    Posts:
    10
    Location:
    Norway
    But the whole point of DismHost.exe seems to be that it gets updated very frequently, obviously you shouldn't have to keep track of hashes several times a day. Besides, those hashes are not published anywhere so how can you know it's the right hash?

    The proper solution would be to not run it from a user writable directory, and it's not like that is some crazy black magic. I'm extremely surprised it isn't the default to write Administrator temp files to an Administrator-only folder!
     
  10. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,591
    Location:
    U.S.A.
    For those not familiar with this issue, there is a serious vulnerability with cleanmgr.exe execution of dismhost.exe in Win 10 that you can read about here: https://enigma0x3.net/2016/07/22/bypassing-uac-on-windows-10-using-disk-cleanup/ . Also unlike other Windows utility process abuses, this one will bypass using UAC set to the highest level setting. There are a few mitigations noted below. I monitor WMI event script execution:
     
    Last edited: Oct 18, 2017
  11. Martin_C

    Martin_C Registered Member

    Joined:
    Dec 4, 2014
    Posts:
    525
    Microsoft fixed that a long time ago in build 15031.
    We are now on build 16299.19 :)
     
  12. Quango

    Quango Registered Member

    Joined:
    Oct 10, 2017
    Posts:
    10
    Location:
    Norway
    But if they fixed it, why is cleanmgr.exe still creating and trying to start a bunch of DismHost.exe files in the user's %TEMP% ? And how can that be considered safe if it has previously been exploited?
     
  13. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,591
    Location:
    U.S.A.
    The vulnerability is not "fixed."

    I ran the scheduled task manually and it ran as "High" integrity level. I have UAC set to max.level. "Not a peep" from it. Per the Enigma article:
    Disk Cleanup scheduled task is still set to run with "highest privledges" in Win 10 CU 1703.
     
  14. Quango

    Quango Registered Member

    Joined:
    Oct 10, 2017
    Posts:
    10
    Location:
    Norway
    Pardon my ignorance, I'm just an average user and don't know much about computer security beyond the basics, but am I correct in thinking that my SRP that disallows all executables from %TEMP% will prevent that exploit?

    I've manually run DISM as Administrator with /ScratchDir set to an Admin-only dir from time to time, and never let cleanmgr.exe run.

    Why does Microsoft want to create dismhost executables in the user temp directory to begin with? Why not use C:\Windows\ServiceProfiles\LocalService\AppData\Local\Temp ?
     
    Last edited: Oct 18, 2017
  15. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
    Yes if DismHost.exe si compiled each time it's run then maintaining hash would be cumbersome. Though I always thought that file is copied from c:\Windows\System32\Dism\DismHost.exe or c:\Windows\SysWOW64\Dism\DismHost.exe and it doesn't change at each run.

    Personally I always disabled SRP when performing disk cleanup - similar as when I installed software.

    Yes proper solution would be to run it from system space, but IMO there's not much you can do about it.
     
  16. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,591
    Location:
    U.S.A.
    Loosely speaking, what Martin_C previously posted is correct. Microsoft attempted to fix this vulnerability by:
    http://www.kernelmode.info/forum/viewtopic.php?f=11&t=3643&start=130

    And this does work as far as the scheduled DiskCleanup task under Task Manager's control. If you open up scheduled tasks in Win 10 ver. 15031+ and view the history for DiskCleanup, you will see that the task fails to run due to permissions issues.

    -EDIT- Also inexplicably, I saw in my scheduled task history that a scheduled DiskCleanup ran successfully 15 mins. after the below manual scan I ran. However, another scheduled scan that ran 6 hours later failed for permissions issues.o_O

    -EDIT 2- Realized what happened in regards to above scheduled DiskCleanup scan running 15 mins. after the forced manual scan. DiskCleanup task will not run if the system in an "active" state. It will reschedule itself to run when the system is idle.

    The problem is this solution is the typical "half-baked" security mitigation one expects from Microsoft. All the attacker has to do is first manually run via command shell, script, registry run key, whatever the following command:

    schtasks /run /I /TN "\Microsoft\Windows\DiskCleanup\SilentCleanup"
    and the UAC bypass works just fine for anyone signed on with limited admin privileges.
     
    Last edited: Oct 20, 2017
  17. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,591
    Location:
    U.S.A.
    As to why the registry key based named folder that contains dismhost.exe periodically appears in the %AppData%/Temp directory, it appears that other Windows maintenance procedures also use dismhost.exe for cleanup activities. Unlike cleanmgr.exe that deletes the registry key based named folder after use, these maintenance procedures just leave the directory in place to use up your disk space. It is also possible that scheduled DiskCleanup via cleanmgr.exe is designed to delete any like named folders. Since it is blocked from executing as noted previously, these registry key based named folders never get deleted.
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.