since it's start about 20 years ago Windows NT supports (fine
ACLs, including the permission "execute file".
In their very finite wisdom Microsoft but decided back then to have
this permission set on EVERY file a user creates (and assumes it is
set on local and remote file systems which dont support ACLs).
The result: on Windows, malware can run everywhere (and since CWD
alias "." is in the path, can be started everywhere)!
These fundamental errors, combined with two other fundamental errors
(NO ACLs on %SystemRoot% and %ProgramFiles% to prevent write access
for non-administrative user accounts, and administrative rights for
every user account) turned Windows NT into the same unsafe, insecure
and vulnerable system its predecessors MS-DOS and Windows 3.x were
and enabled miscreants to abuse internet-connected Windows systems
to distribute SPAM, launch DDoS attacks, spread malware, etc.
For a company that puts "compatibility" above all other criteria
decision might have looked reasonable ... BUT: it was NOT!
Windows NT introduced the Win32-API, which is/was INCOMPATIBLE to
existing DOS- and Win16-API. To run existing applications written
the old APIs Windows NT introduced NTVDM (the "Virtual DOS Machine")
and WoW (the "Windows on Windows" subsystem); only these Windows NT
components had to be made compatible (and "unsafe" enough to run old
There was ABSOLUTELY no need to sacrifice the safety and security of
Windows NT and the Win32-API for the sake of "compatibility": the
Win32-API was new, no existing applications had to be supported!
Then sloppy developers started to build their applications for the
Win32-API of this unsafe/insecure environment ... and expected their
unsuspecting victims^Wusers to have write access to %SystemRoot%
%ProgramFiles% to write their *.INI files, for example, or to run
crapware with administrative or power-user rights.
JFTR: since many years Microsoft makes many (almost futile) attempts
to mitigate the effect of their wrong design decision(s), for
* <http://support.microsoft.com/kb/269049> alias
* <http://support.microsoft.com/kb/953818> alias
* <http://support.microsoft.com/kb/959426> alias
* <http://support.microsoft.com/kb/2269637> alias
<http://technet.microsoft.com/security/advisory/2269637> PLUS the
28(!) security bulletins listed there
but NEVER tackled the source of the problem!
Instead they introduced things like the "security theatre" UAC: with
Windows 8 the user account(s) created during setup still have
administrative rights. And Windows 7 introduced the "silent"
for about 70 of Microsoft own programs...
PS: if you want to mitigate the wrong design decision that every
is "executable": add and propagate an inheritable-only "deny"
with "execute file" permission for the user group
alias "S-1-1-0", "(D;OIIO;WP;;;WD)" in SDDL notation, at least
"%USERPROFILE%" and "%ALLUSERSPROFILE%" alias "%ProgramData%".
On Windows NT 6.x, consider to add another "deny" ACE which
the directories/objects owner from changing/removing that
"(D;;WDAC;;;OW)" in SDDL notation.
Since this mitigation will stop "Administrators" and
to run files in their user profiles (to be precise: in "%TEMP%"
alias "%USERPROFILE%\Local Settings\Application Data\TEMP" resp.
"%USERPROFILE%\AppData\TEMP" where self-extracting installers
typically unpack and execute their payload) you'll have to
the user environment variables TEMP and TMP of these user
(setting the system environment variables TEMP and TMP which
to %SystemRoot%\TEMP into effect).
See the script
for a POC (targetting Windows NT 5.x). It sets the "deny" ACE
on subordinate directories which are exempt from ACL
as well as some of the user-writable subdirectories of
which dont host executable files.
WARNING: unfortunately the (only) Microsoft utility which allows
add the specific ACEs, ICACLS.EXE, used in this script has but a
serious bug; cf.