AspnetCore application tries to load Microsoft.DiaSymReader.Native.amd64.dll at runtime on centos linux

[neyromant]

Description

I ran my aspnet core application on centos linux using the LL_DEBUG=libs command and found that it was unsuccessfully trying to load the Microsoft.DiaSymReader.Native.amd64.dll library. This does not lead to any visible consequences, but I would like to understand the reasons for this behavior.
After all, Microsoft.DiaSymReader.Native.amd64.dll is a windows-only library

Can someone tell me what is the reason for this behavior and how to avoid it?

Thanks in advance for any answer.

Reproduction Steps

Build self contained asp.net core app, run it on linux centos by LL_DEBUG=libs ./my-app

Expected behavior

An application does not try to load Microsoft.DiaSymReader.Native.amd64.dll on linux

Actual behavior

Application tries to load Microsoft.DiaSymReader.Native.amd64.dll on linux

Regression?

No response

Known Workarounds

No response

Configuration

.net 7
centos 9
x64

Other information

No response

[ghost]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

I ran my aspnet core application on centos linux using the LL_DEBUG=libs command and found that it was unsuccessfully trying to load the Microsoft.DiaSymReader.Native.amd64.dll library. This does not lead to any visible consequences, but I would like to understand the reasons for this behavior.
After all, Microsoft.DiaSymReader.Native.amd64.dll is a windows-only library

Can someone tell me what is the reason for this behavior and how to avoid it?

Thanks in advance for any answer.

Reproduction Steps

Build self contained asp.net core app, run it on linux centos by LL_DEBUG=libs ./my-app

Expected behavior

An application does not try to load Microsoft.DiaSymReader.Native.amd64.dll on linux

Actual behavior

Application tries to load Microsoft.DiaSymReader.Native.amd64.dll on linux

Regression?

No response

Known Workarounds

No response

Configuration

.net 7
centos 9
x64

Other information

No response

Author:	neyromant
Assignees:	-
Labels:	area-Diagnostics-coreclr, untriaged, needs-area-label
Milestone:	-

[tommcdon]

@neyromant thanks for reporting this issue! I completely agree we do not need to probe for Microsoft.DiaSymReader.Native.<arch>.dll on Linux. This is the code is used for displaying line numbers in exception callstacks. Here is the code that attempts to load the Windows DLL:

runtime/src/coreclr/vm/ceeload.cpp

Lines 2262 to 2273 in 034d27f

	PathString symbolReaderPath;
	hr = GetClrModuleDirectory(symbolReaderPath);
	if (FAILED(hr))
	{
	RETURN (NULL);
	}
	symbolReaderPath.Append(NATIVE_SYMBOL_READER_DLL);
	hr = FakeCoCreateInstanceEx(CLSID_CorSymBinder_SxS, symbolReaderPath.GetUnicode(), IID_ISymUnmanagedBinder, (void**)&pBinder, NULL);
	if (FAILED(hr))
	{
	RETURN (NULL);
	}

And if GetISymUnmanagedReaderNoThrow returns NULL (as it should on Linux), we will fall back to loading portable PDB's which is supported on all platforms:

runtime/src/coreclr/vm/debugdebugger.cpp

Lines 570 to 592 in 034d27f

	if (!fPortablePDB)
	{
	// We didn't see a portable PDB in the debug directory but to just make sure we defensively assume that is
	// portable and if the diasymreader doesn't exist or fails, we go down the portable PDB path.
	fPortablePDB = TRUE;
	BOOL fFileInfoSet = FALSE;
	ULONG32 sourceLine = 0;
	ULONG32 sourceColumn = 0;
	WCHAR wszFileName[MAX_LONGPATH];
	ULONG32 fileNameLength = 0;
	{
	// Note: we need to enable preemptive GC when accessing the unmanages symbol store.
	GCX_PREEMP();
	// Note: we use the NoThrow version of GetISymUnmanagedReader. If getting the unmanaged
	// reader fails, then just leave the pointer NULL and leave any symbol info off of the
	// stack trace.
	ReleaseHolder<ISymUnmanagedReader> pISymUnmanagedReader(
	pModule->GetISymUnmanagedReaderNoThrow());
	if (pISymUnmanagedReader != NULL)
	{

I feel we could #ifdef this code out on Linux as we do not support Windows PDB's on Linux. Feel free to open a PR for review otherwise we will leave it on the backlog for .NET 9.

[neyromant]

@tommcdon thanks for you answer! I made a draft pull request. Could you take a look to see if I understood your idea correctly?

[jkotas]

Fixed by #92492

[neyromant]

@tommcdon @jkotas Please tell me, is it possible to bring this fix to net7 or at least 8? What should I do for this?

[jkotas]

Backports require a strong justification. Why is this change important for you?

[neyromant]

@jkotas I'm concerned that it could be a potential local privilege escalation vulnerability via shared object hijaking.
This is just my guess. Unfortunately, I do not have sufficient knowledge in this area to provide any supporting facts.

[jkotas]

This case is “Scenario 2: Malicious binary planted in an untrusted application directory.” from https://msrc.microsoft.com/blog/2018/04/triaging-a-dll-planting-vulnerability/ . According to this guidance, a DLL planting issue that falls into this category is treated as Defense-in-Depth issue that will be considered for updates in future versions only.