From b95ca061fc3b4342eecb571e45c085072e80e42b Mon Sep 17 00:00:00 2001 From: Dominik Viererbe Date: Thu, 28 Nov 2024 12:28:13 +0200 Subject: [PATCH] feat: disable wait for debugger in release builds This may be used by an attacker to elevate privileges. The `install` and `remove` commands are executed with effective superuser privileges. If an attacker is able to attach a debugger they could execute arbitrary code with superuser privileges. note: I tried to create a proof of concept for this attack, but failed with my naive attempts. It seems that the .NET debugger does not attach, because our release builds are compiled with `-p:DebugType=none`. Trying to attach the LLDB debugger also did not work because of Yama protections. Read more about it here: https://www.kernel.org/doc/Documentation/security/Yama.txt I am not sure if the above-mentioned protections are sufficient or if it is just a skill issue on my side to exploit this feature. I am not aware that we use the debugger wait feature in release builds and therefore simply remove it to not risk having a potential vulnerability. --- src/Dotnet.Installer.Console/Program.cs | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/Dotnet.Installer.Console/Program.cs b/src/Dotnet.Installer.Console/Program.cs index efa0383..49cbce0 100644 --- a/src/Dotnet.Installer.Console/Program.cs +++ b/src/Dotnet.Installer.Console/Program.cs @@ -14,6 +14,7 @@ class Program { private static async Task Main(string[] args) { +#if DEBUG var debugEnabled = Environment.GetEnvironmentVariable("DOTNET_INSTALLER_DEBUG")?.Equals("1") ?? false; if (debugEnabled) { @@ -25,7 +26,7 @@ private static async Task Main(string[] args) } Log.Debug("Debugger attached"); } - +#endif var fileService = new FileService(); var manifestService = new ManifestService(); var snapService = new SnapService();