Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

GetTempPath known issues documentation #9462

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
+39 −0
Open

GetTempPath known issues documentation #9462

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
b83db5a
GetTempPath known issues documentation
rbhanda Aug 14, 2024
9140d44
Update known-issues.md
rbhanda Aug 14, 2024
7eeb244
Update known-issues.md
rbhanda Aug 14, 2024
dca310d
Apply suggestions from code review
rbhanda Sep 16, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 18 additions & 0 deletions release-notes/6.0/known-issues.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,24 @@

You may encounter the following known issues, which may include workarounds, mitigations or expected resolution timeframes.

## .NET Servicing July 2024 update
The .NET Servicing updated released on [July](https://github.com/dotnet/announcements/issues/311) contains a security fix addressed an elevation of privilege vulnerability detailed in CVE [2024-38081](https://msrc.microsoft.com/update-guide/vulnerability/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](https://learn.microsoft.com/windows/win32/api/fileapi/nf-fileapi-gettemppath2w#remarks) of the [GetTempPath2](https://learn.microsoft.com/windows/win32/api/fileapi/nf-fileapi-gettemppath2w) 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. 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. For non-SYSTEM processes, GetTempPath2 will behave the same as GetTempPath, respecting the same environment variables to override the return value.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

@TaraOverfield TaraOverfield Aug 19, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


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](https://learn.microsoft.com/windows/win32/api/fileapi/nf-fileapi-gettemppatha) Win32 API for the most up to date information on this behavior.

Please reference to the [System.IO.Path.GetTempPath API](https://learn.microsoft.com/dotnet/api/system.io.path.gettemppath?view=netframework-4.8.1&tabs=windows) for more information.

**Temporary Workaround**

Warning: The opt-out will disable the security fix for the elevation of privilege vulnerability detailed in [CVE 2024-38081](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38081). The opt-out is only for temporary workaround if you're sure that the software is running in secure environments. Microsoft does not recommend applying this temporary workaround.

To apply the opt-out, set the `COMPlus_Disable_GetTempPath2` environment variable to `true` in the necessary context. System-wide environment variables can be set by running `sysdm.cpl` and navigating to "Advanced -> Environment variables -> System variables -> New".

**Resolution**
The API behavior change is by design to address the elevation of privilege vulnerability. Any affected software or application is expected to make code change to adapt to this new design change.
Copy link
Member

@GrabYourPitchforks GrabYourPitchforks Aug 15, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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."

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


## Failure to install the .NET 6.0.1 update via Microsoft Update

### Summary
Expand Down
21 changes: 21 additions & 0 deletions release-notes/8.0/known-issues.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,26 @@

You may encounter the following known issues, which may include workarounds, mitigations, or expected resolution timeframes.

## .NET Servicing July 2024 update
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

The .NET Servicing updated released on [July](https://github.com/dotnet/announcements/issues/311) contains a security fix addressed an elevation of privilege vulnerability detailed in CVE [2024-38081](https://msrc.microsoft.com/update-guide/vulnerability/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](https://learn.microsoft.com/windows/win32/api/fileapi/nf-fileapi-gettemppath2w#remarks) of the [GetTempPath2](https://learn.microsoft.com/windows/win32/api/fileapi/nf-fileapi-gettemppath2w) 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. 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. 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](https://learn.microsoft.com/windows/win32/api/fileapi/nf-fileapi-gettemppatha) Win32 API for the most up to date information on this behavior.

Please reference to the [System.IO.Path.GetTempPath API](https://learn.microsoft.com/dotnet/api/system.io.path.gettemppath?view=netframework-4.8.1&tabs=windows) for more information.

**Temporary Workaround**

Warning: The opt-out will disable the security fix for the elevation of privilege vulnerability detailed in [CVE 2024-38081](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38081). The opt-out is only for temporary workaround if you're sure that the software is running in secure environments. Microsoft does not recommend applying this temporary workaround.
- Option#1: Opt out in a command window by setting the environment variable
-- COMPlus_Disable_GetTempPath2=true
- Opiton#2: [Opt out globally on the machine by creating a system-wide environment variable and rebooting to ensure all processes observe the change](https://stackoverflow.com/questions/2365307/what-determines-the-return-value-of-path-gettemppath).
-- System-wide environment variables can be set by running “sysdm.cpl” from a cmd window, and then navigating to “Advanced -> Environment variables -> System variables -> New”.

**Resolution**
The API behavior change is by design to address the elevation of privilege vulnerability. Any affected software or application is expected to make code change to adapt to this new design change.

## .NET SDK

### 8.0.2xx SDK is not compatible with 17.8 for some scenarios
Expand All @@ -15,3 +35,4 @@ Some analyzers and source generators that ship with the SDK took a dependency on
1. Use 17.10 which matches the 8.0.2xx SDK
2. Install the 8.0.1xx SDK and use global.json to pin to it if you have multiple SDKs installed
3. Set BuildWithNetFrameworkHostedCompiler=true in your build. This configures the build to use a matching version of the compiler to your SDK version rather than to your VS version so in this case, it'll use a 4.10 version of Roslyn.

Loading