Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A common pattern I recognized is admins placing applications in directories created in drive roots, e.g.:
Some installers also do this by default.
Since these folders inherit
AddDirectory
andAddFile
permissions for theBUILTIN\Users
group, any local user can place malicious DLL's inside these directories to hijack processes executed by other users of the same machine (think terminal servers):For now, a new check only enumerates modifiable folders in root directories, and doesn't check whether there are any executables inside (this seems to be problematic elsewhere too). It also doesn't care if subdirectory ACL's are customized. Since there are other venues for attack (e.g. add a script to a conf.d-like folder) I'd rather just highlight the potential problem and let the tester assess the actual risk depending on the environment.
I only use PowerShell when I really have to, so the code is mostly frankensteined from other places. Also I don't expect this to be merged right away (not sure about base risk, are descriptions good enough, ...), any feedback is welcome!