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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Mon, 13 Apr 2020 17:42:01 +0200
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: <fulldisclosure@...lists.org>
Cc: bugtraq@...urityfocus.com
Subject: [FD] Defense in depth -- the Microsoft way (part 67): we maintain
	20 year old bugs since we don't care about our customers
	safety and security

Hi @ll,

poor implementation is one of the most notable^Wnotorious properties
of Windows, providing it with a HUGE attack surface -- and Microsoft
just doesn't care!

Case/issue 67: FOR NO GOOD REASON, ONLY privileged processes running
under the SYSTEM account share their TEMP directory since 20 years
with all (unprivileged) users, allowing local escalation of privilege.

At least the following CWEs apply:
<https://cwe.mitre.org/data/definitions/379.html>
<https://cwe.mitre.org/data/definitions/426.html>
<https://cwe.mitre.org/data/definitions/427.html>

For some of the resulting vulnerabilities see
<https://d4stiny.github.io/Several-Critical-Vulnerabilities-on-most-HP-machines-running-Windows/#local-privilege-escalation-3>,
<https://seclists.org/fulldisclosure/2020/Jan/51>,
<https://skanthak.homepage.t-online.de/skype.html>
alias <https://www.securityfocus.com/archive/1/541766>
or <https://seclists.org/fulldisclosure/2018/Feb/33>,
<https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV170017>
alias <https://www.securityfocus.com/archive/1/541997>
or <https://seclists.org/fulldisclosure/2018/May/23>,
<https://www.securityfocus.com/archive/1/539189> alias
<https://seclists.org/fulldisclosure/2016/Aug/51>, ...


Act 1 (History):
~~~~~~~~~~~~~~~~

With Windows 2000, Microsoft moved all user profiles from their previous
(original) location "%SystemRoot%\Profiles\" into the then new directory
"%SystemDrive%\Documents and Settings\"
They also introduced a user profile for the (privileged) user account
"NT AUTHORITY\SYSTEM" alias "LocalSystem" in the new directory
"%SystemRoot%\System32\Config\SystemProfile\"

Additionally the world-writable TEMP directory "%SystemRoot%\Temp\",
which was shared by all users in previous versions of Windows NT,
was replaced with private and separate TEMP directories
"%USERPROFILE%\Local Settings\Application Data\Temp\" alias
"%SystemDrive%\Documents and Settings\%USERNAME%\Local Settings\Application Data\Temp\"
located within the user profiles -- EXCEPT for the SYSTEM account,
which continued (and still continues) to use the (still world-writable)
directory "%SystemRoot%\Temp\"!

What (or who) but stopped them from moving the TEMP directory for the
SYSTEM account into its user profile?
First chance lost!


Act 2 (History):
~~~~~~~~~~~~~~~~

With Windows XP, Microsoft added the (unprivileged) user accounts
"NT AUTHORITY\LocalService" and "NT AUTHORITY\NetworkService", placed
their user profiles in the new directory "%SystemRoot%\ServiceProfiles\",
set their user environment variables TEMP and TMP to
%USERPROFILE%\Local Settings\Application Data\Temp, and created their
private TEMP directory within both user profiles.

What (or who) but stopped them from moving the TEMP directory for the
SYSTEM account into its user profile?
Second chance lost!


Act 3 (History):
~~~~~~~~~~~~~~~~

With Windows Vista, Microsoft relocated the "normal" user profiles into
the directories "%SystemDrive%\Users\%USERNAME%\", while the other user
profiles remained in the directories introduced with Windows 2000 and
Windows XP.
Also ALL user accounts except SYSTEM kept their private and separate
TEMP directory, now "%USERPROFILE%\AppData\Local\Temp\" alias
"%SystemDrive%\Users\%USERNAME%\AppData\Local\Temp\" for "normal" user
accounts and "%SystemRoot%\ServiceProfiles\%USERNAME%\AppData\Local\Temp\"
for the service user accounts.

What (or who) but stopped them from moving the TEMP directory for the
SYSTEM account into its user profile?
Third chance lost!


Act 4 (Today):
~~~~~~~~~~~~~~

And now the highlight: at least since Windows 7, Microsoft finally sets
the user environment variables TEMP and TMP of the SYSTEM account to
"%USERPROFILE%\AppData\Local\Temp\" too, despite the missing directory
"%SystemRoot%\System32\Config\SystemProfile\AppData\Local\Temp\" in its
user profile!


Start the registry editor and take a look into the registry keys

[HKEY_CURRENT_USER\Environment]
[HKEY_LOCAL_MACHINE\SOFTWARE\DefaultUserEnvironment]
[HKEY_USERS\.DEFAULT\Environment]
[HKEY_USERS\S-1-5-18\Environment] ; S-1-5-18 = LocalSystem
[HKEY_USERS\S-1-5-19\Environment] ; S-1-5-19 = LocalService
[HKEY_USERS\S-1-5-20\Environment] ; S-1-5-20 = NetworkService

They ALL contain at least the following two registry entries:

"TEMP"=expand:"%USERPROFILE%\\AppData\\Local\\Temp"
"TMP"=expand:"%USERPROFILE%\\AppData\\Local\\Temp"


"Thanks" to BRAINDEAD and UNDOCUMENTED behaviour, Windows but ignores
the TEMP and TMP user environment variables under the SYSTEM account;
processes started there use the system environment variables instead,
which are present in the registry key

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\Environment]
"TEMP"=expand:"%SystemRoot%\\TEMP"
"TMP"=expand:"%SystemRoot%\\TEMP"


Since unprivileged users can create files and subdirectories in the
directory "%SystemRoot%\TEMP", this constitutes a well-known and
well-documented weakness, allowing local escalation of privilege to
SYSTEM!


REMEDIATION:
~~~~~~~~~~~~

1. Interactive

   In an already and running installed system, create the directory
   "%SystemRoot%\System32\Config\SystemProfile\AppData\Local\Temp\",
   then run SystemPropertiesAdvanced.exe and set the environment
   variables per GUI to the value %USERPROFILE%\AppData\Local\Temp

2. Unattended

   Write a batch script that creates the missing directory with one
   of the following (equivalent) command lines

      MKDIR "%SystemRoot%\System32\Config\SystemProfile\AppData\Local\Temp"
      MKDIR "%USERPROFILE%\AppData\Local\Temp"
      MKDIR "%LOCALAPPDATA%\Temp"

   and sets the system environment variables TEMP and TMP, for example
   per

      SETX.exe /M TEMP ^%USERPROFILE^%\AppData\Local\Temp
      SETX.exe /M TMP ^%USERPROFILE^%\AppData\Local\Temp

   or per

      REG.exe ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\Environment" /V TEMP /T REG_EXPAND_SZ /D
^%USERPROFILE^%\AppData\Local\Temp /F
      REG.exe ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\Environment" /V TMP /T REG_EXPAND_SZ /D
^%USERPROFILE^%\AppData\Local\Temp /F

   Deploy this script on your Windows installation media as
   \sources\$OEM$\$$\Setup\Scripts\SetupComplete.cmd,
   or specify your $OEM$\ directory with this script in the
   command line of Windows' installation program:

       SETUP.exe /M="<path to $OEM$ directory>"


stay tuned, and far away from (not just Microsoft's) poorly implemented crap
Stefan Kanthak


_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ