BugTraq
Defense in depth -- the Microsoft way (part 8): execute everywhere! Aug 24 2013 09:32PM
Stefan Kanthak (stefan kanthak nexgo de) (1 replies)
Re: [Full-disclosure] Defense in depth -- the Microsoft way (part 8): execute everywhere! Aug 24 2013 10:33PM
Jeffrey Walton (noloader gmail com) (3 replies)
Re: [Full-disclosure] Defense in depth -- the Microsoft way (part 8): execute everywhere! Aug 26 2013 03:16PM
James Lay (jlay slave-tothe-box net) (1 replies)
Re: [Full-disclosure] Defense in depth -- the Microsoft way (part 8): execute everywhere! Aug 26 2013 03:15PM
James Lay (jlay slave-tothe-box net)
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 (at) nexgo (dot) de [email concealed]> 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>

[ reply ]
Re: [Full-disclosure] Defense in depth -- the Microsoft way (part 8): execute everywhere! Aug 25 2013 12:07AM
Stefan Kanthak (stefan kanthak nexgo de)


 

Privacy Statement
Copyright 2010, SecurityFocus