Date: Mon, 26 Aug 2013 09:15:22 -0600
From: James Lay <jlay@...ve-tothe-box.net>
To: <bugtraq@...urityfocus.com>
Subject: Re: [Full-disclosure] Defense in depth -- the Microsoft way (part  8): execute everywhere!

On 2013-08-24 16:33, Jeffrey Walton wrote:
> Hi Stefan,
>
>> ... administrative rights for every user account
> Hmmm... XP/x64 appears to have a bug such that the second user also
> needs to be admin (perhaps XP/x86, too). XP does not recognize the
> first account as admin, so the second account cannot be limited (at
> least on my test box).
>
> Vista and above make the first user admin, but others users default
> to standard.
>
> Jeff
>
> On Sat, Aug 24, 2013 at 5:32 PM, Stefan Kanthak
> <stefan.kanthak@...go.de> wrote:
>> Hi,
>>
>> since it's start about 20 years ago Windows NT supports (fine 
>> grained)
>> 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 
>> this
>> decision might have looked reasonable ... BUT: it was NOT!
>>
>>
>> Windows NT introduced the Win32-API, which is/was INCOMPATIBLE to 
>> the
>> existing DOS- and Win16-API. To run existing applications written 
>> for
>> 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
>> applications).
>>
>> 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% 
>> and/or
>> %ProgramFiles% to write their *.INI files, for example, or to run 
>> their
>> 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 
>> example:
>>
>> * <http://support.microsoft.com/kb/269049> alias
>>   <http://technet.microsoft.com/security/bulletin/ms00-052>
>>
>> * <http://support.microsoft.com/kb/306850>
>>
>> * <http://support.microsoft.com/kb/905890>
>>
>> * <http://support.microsoft.com/kb/953818> alias
>>   <http://technet.microsoft.com/security/advisory/953818>
>>
>> * <http://support.microsoft.com/kb/959426> alias
>>   <http://technet.microsoft.com/security/bulletin/ms09-015>
>>
>> * <http://support.microsoft.com/kb/2264107>
>>
>> * <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" 
>> elevation
>> for about 70 of Microsoft own programs...
>>
>>
>> stay tuned
>> Stefan Kanthak
>>
>>
>> PS: if you want to mitigate the wrong design decision that every 
>> file
>>     is "executable": add and propagate an inheritable-only "deny" 
>> ACE
>>     with "execute file" permission for the user group 
>> "WORLD\Everyone"
>>     alias "S-1-1-0", "(D;OIIO;WP;;;WD)" in SDDL notation, at least 
>> for
>>     "%USERPROFILE%" and "%ALLUSERSPROFILE%" alias "%ProgramData%".
>>
>>     On Windows NT 6.x, consider to add another "deny" ACE which 
>> prevents
>>     the directories/objects owner from changing/removing that 
>> permission:
>>     "(D;;WDAC;;;OW)" in SDDL notation.
>>
>>     Since this mitigation will stop "Administrators" and 
>> "LocalSystem"
>>     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 
>> will
>>     typically unpack and execute their payload) you'll have to 
>> remove
>>     the user environment variables TEMP and TMP of these user 
>> accounts
>>     (setting the system environment variables TEMP and TMP which 
>> point
>>     to %SystemRoot%\TEMP into effect).
>>
>>
>>     See the script 
>> <http://home.arcor.de/skanthak/download/~EXECUTE.INF>
>>     for a POC (targetting Windows NT 5.x). It sets the "deny" ACE 
>> also
>>     on subordinate directories which are exempt from ACL 
>> inheritance,
>>     as well as some of the user-writable subdirectories of 
>> %SystemRoot%
>>     which dont host executable files.
>>
>>     WARNING: unfortunately the (only) Microsoft utility which allows 
>> to
>>     add the specific ACEs, ICACLS.EXE, used in this script has but a
>>     serious bug; cf. 
>> <http://seclists.org/fulldisclosure/2012/May/109>

Powered by blists - more mailing lists