FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION.md

Organizations who cannot take advantage of these protections can set the FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION registry key to avoid exploitation. Please note that while these registry settings would mitigate exploitation of this issue, it could affect regular functionality for certain use cases related to these applications.

MS Documentation for the referenced registry settings:

• https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/general-info/ee330731(v=vs.85)#file-protocol-navigation (Thank you @johnmccash)

$registryPath = "HKLM:\SOFTWARE\Policies\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION"
$applications = @("Excel.exe", "Graph.exe", "MSAccess.exe", "MSPub.exe", "PowerPnt.exe", "Visio.exe", "WinProj.exe", "WinWord.exe", "Wordpad.exe")

if (!(Test-Path -Path $registryPath)) {
    New-Item -Path $registryPath -Force | Out-Null
}
foreach ($app in $applications) {
    Set-ItemProperty -Path $registryPath -Name $app -Value 1 -Type DWord
}

MS Documentation for the referenced registry settings:
[(https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/general-info/ee330731(v=vs.85)#file-protocol-navigation)]

great! What about teams.exe?

Organizations who cannot take advantage of these protections can set the FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION registry key to avoid exploitation. No OS restart is required, but restarting the applications that have had the registry key added for them is recommended in case the value was already queried and is cached. Please note that while these registry settings would mitigate exploitation of this issue, it could affect regular functionality for certain use cases related to these applications. For this reason, we suggest testing. To disable the mitigation, delete the registry key or set it to “0”.
Add the following application names to this registry key as values of type REG_DWORD with data 1.:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION

Excel.exe
Graph.exe
MSAccess.exe
MSPub.exe
Powerpnt.exe
Visio.exe
WinProj.exe
WinWord.exe
Wordpad.exe

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36884

@MHaggis

Looks like there is a typo in the list of application exe names.

Per https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36884, the PowerPoint.exe filename should instead be Powerpnt.exe:

-PowerPoint.exe
+Powerpnt.exe

Thank you, @atc0005 ! Updated.

Do you know of a way to verify whether this setting is actually working, e.g. using a test document?
A simple word document containing a URL to file:///C:/Windows/System32/calc.exe, downloaded from the internet, doesn't seem to do the trick. calc.exe is still executed in spite of the registry setting (after clicking on "Enable editing" of course, and after two more confirmation dialogs).

Thanks!

I too am looking for a quick easy way to test this. I tried a shared .xlsm doc from onedrive and was able to execute a macro that had a child ping child process from explorer.exe and it was not blocked like I anticipated it would be.