lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <eab1453426e0888e1e0040a600fb3f22@localhost> 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