Windows – Powershell systemroot in $env:path different when AC elevated

administratorenvironment-variablespowershellwindows 7

I have a strange behavior with the environment variables at my Windows XP SP3.

When I logon as Administrator, the %SystemRoot% strings in PATH are substituted to C:\WINDOWS, the value of the variable 'SystemRoot' is C:\WINDOWS.

But when I logon as any non-administrative user, the %SystemRoot% literally remains in the PATH, although the variable 'SystemRoot' has the same value as with Administrator's account.

Running PowerShell as a normal user:

PS C:\Users\vic> $env:path (Enter)

%SystemRoot%\system32\WindowsPowerShell\v1.0\;C:\Program Files\AMD APP\bin\x86;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files\ATI Technologies\ATI.ACE\Core-Static

Running PowerShell elevated (I right click, run as admin):

PS C:\Windows\system32> $env:path

C:\Windows\system32\WindowsPowerShell\v1.0\;C:\Program Files\AMD APP\bin\x86;C:\Windows\system32;C:\Windows;C:\Windows\
System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files\ATI Technologies\ATI.ACE\Core-Static

Env path in Windows:

C:\Program Files\AMD APP\bin\x86;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SystemRoot%\System32\WindowsPowerShell\v1.0;C:\Program Files\ATI Technologies\ATI.ACE\Core-Static

Why?

Best Answer

This is probably related to a known bug in Windows XP, Windows 7, and several others. (Based on available documentation, it either does not affect or has not been seen in Windows 8 or later.)

The bug is documented in Microsoft KB Article #329308 (Environment variable may not expand %APPDATA% to the Application folder). It is also documented as a Medium vulnerability in the NIST National Vulnerability Database, as CVE-2007-6753. One of the cited references in the CVE entry, an article on the ACROS Security Blog, claims the issue may be as old as, or even older than, 2003.

Though the referenced KB article specifically mentions %APPDATA%, the bug affects all "variables-within-variables", and particularly becomes a security concern when it shows up in the %PATH% variable.

I don't know why elevated privileges would make a difference in how this bug is expressed. In my experience, reproduction of the issue is typically pretty flaky anyway. But the general case of variables-within-variables not being properly expanded is a known bug, so I would not spend much time trying to actually troubleshoot it.

The only workaround I'm aware of is to edit the affected variables so that paths are explicitly defined, instead of reliant upon other variables. Anywhere you see "%SystemRoot%" in %PATH%, replace it with the exact value of %SystemRoot%. Do the same for any other nested variables in your environment where possible - especially where those variables define file/folder paths.

Related Question