GetTempPath known issues documentation

[rbhanda]

No description provided.

[GrabYourPitchforks]

Recommend striking these sentences. We discussed it offline, but the gist is that the statements are not 100% accurate, and we (.NET) should not make ourselves appear as the authoritative source of information for a Windows API.

When calling this function from a process running as SYSTEM it will return the path %WINDIR%\SystemTemp, which is inaccessible to non-SYSTEM processes. This return value for SYSTEM processes cannot be overridden by environment variables.

If you want to call attention to the specific problem people are having, you could couch it in point-in-time terms, like:

As of this writing (August 2024), when running as a SYSTEM-level process, environment variables like %TEMP% are not honored by the GetTempPath2 Win32 API. This could cause behavioral differences for applications which run as SYSTEM and which previously relied on the %TEMP% environment variable controlling the return value of the Path.GetTempPath API.

[TaraOverfield]

@GrabYourPitchforks - Are you suggesting that we add the extra call out in the beginning or the end of the known issues section? What do you think of something like this:

The .NET Framework servicing update released on July 2024 security and quality rollup - .NET Framework contains a security fix addressed an elevation of privilege vulnerability detailed in CVE 2024-38081. The fix changed System.IO.Path.GetTempPath method return value. If windows version exposes the GetTempPath2 Win32 API, this method invokes that API and returns the resolved path. See the Remarks section of the GetTempPath2 documentation for more information on how this resolution is performed, including how to control the return value through the use of environment variables. The GetTempPath2 API may not be available on all versions of Windows.

An observable difference between the GetTempPath and GetTempPath2 Win32 APIs is that they return different values for SYSTEM and non-SYSTEM processes. As of this publishing, in August 2024, when running as a SYSTEM-level process, environment variables like %TEMP% are not honored by the GetTempPath2 Win32 API. This could cause behavioral differences for applications which run as SYSTEM and which previously relied on the %TEMP% environment variable controlling the return value of the Path.GetTempPath API. For non-SYSTEM processes, GetTempPath2 will behave the same as GetTempPath, respecting the same environment variables to override the return value.

In some scenarios it may be possible to redirect the Temp folder to a different folder using environment variables or other means. Please refer to the official documentation for the GetTempPath2 Win32 API for the most up to date information on this behavior.

[jeffhandley]

Building on the suggestions from @TaraOverfield and @GrabYourPitchforks, here's my stab at it:

The .NET Framework servicing update released on July 2024 security and quality rollup - .NET Framework contains a security fix addressed an elevation of privilege vulnerability detailed in CVE 2024-38081. The fix changed System.IO.Path.GetTempPath method return value. If windows version exposes the GetTempPath2 Win32 API, this method invokes that API and returns the resolved path. See the Remarks section of the GetTempPath2 documentation for more information on how this resolution is performed. The GetTempPath2 API may not be available on all versions of Windows.

An intentional and observable difference between the GetTempPath and GetTempPath2 Win32 APIs is that they return different values for SYSTEM and non-SYSTEM processes. As of this publishing in August 2024, when running as a SYSTEM-level process, no environment variables are honored by the GetTempPath2 Win32 API. This will cause behavioral differences for applications which run as SYSTEM and previously relied on environment variables to control the drive or folder in the Path.GetTempPath return value. For non-SYSTEM processes, GetTempPath2 behavior is unchanged, respecting the same environment variables as the GetTempPath Win32 API to override the return value.

Please refer to the official documentation for the GetTempPath2 Win32 API for the most up to date information on this behavior.

[GrabYourPitchforks]

Any affected software or application is expected to make code change to adapt to this new design change.

This seems... hostile? Who needs to make a code change, and what type of code change are they expected to make?

Should we just strike this sentence entirely if it doesn't add value?

[TaraOverfield]

I agree the statement seems harsh. There was much discussion about the resolution prior to making the initial post. It seemed necessary to give customers a direction of what they need to do for a permanent fix other than opting out of the security changes.

Can you suggest a better way to inform customers that they should really make a code change? It seems a little light in content to leave the resolution as "The API behavior change is by design to address the elevation of privilege vulnerability."

[GrabYourPitchforks]

Yeah, I'm honestly not quite sure what to put here. The reason we made the code change is that we wanted customers to be secure without them needing to modify their own code. :)

If we felt compelled to write something, maybe something like "if you know your app depends on (some env var), query that specific env var"? That's generally good practice for limiting code fragility anyway. It makes the code more closely tied to the thing it cares about rather than bouncing through an indirection and all the implementation details that might come with it.

[jeffhandley]

Building on the suggestions from @TaraOverfield and @GrabYourPitchforks, here's my stab at it:

The .NET Framework servicing update released on July 2024 security and quality rollup - .NET Framework contains a security fix addressed an elevation of privilege vulnerability detailed in CVE 2024-38081. The fix changed System.IO.Path.GetTempPath method return value. If windows version exposes the GetTempPath2 Win32 API, this method invokes that API and returns the resolved path. See the Remarks section of the GetTempPath2 documentation for more information on how this resolution is performed. The GetTempPath2 API may not be available on all versions of Windows.

An intentional and observable difference between the GetTempPath and GetTempPath2 Win32 APIs is that they return different values for SYSTEM and non-SYSTEM processes. As of this publishing in August 2024, when running as a SYSTEM-level process, no environment variables are honored by the GetTempPath2 Win32 API. This will cause behavioral differences for applications which run as SYSTEM and previously relied on environment variables to control the drive or folder in the Path.GetTempPath return value. For non-SYSTEM processes, GetTempPath2 behavior is unchanged, respecting the same environment variables as the GetTempPath Win32 API to override the return value.

Please refer to the official documentation for the GetTempPath2 Win32 API for the most up to date information on this behavior.

[jeffhandley]

Once we settle on the text above, we'll of course need to replicate it into this file too.