From 683f42f8a4d8f4297b51fca1c0a7e7c1dfaa3a08 Mon Sep 17 00:00:00 2001 From: "Fedotov, Aleksei" Date: Thu, 14 Nov 2024 12:51:10 +0100 Subject: [PATCH 1/9] Add template for dependency loading RFC --- .../loading-dependencies-by-module-name.org | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org diff --git a/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org b/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org new file mode 100644 index 0000000000..a44d8cd367 --- /dev/null +++ b/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org @@ -0,0 +1,5 @@ +#+title: Loading Dependencies By Module Name + +* Introduction +* Proposal +* Open Questions From a585521549af55f137f63dca77138c7974c17f10 Mon Sep 17 00:00:00 2001 From: "Fedotov, Aleksei" Date: Mon, 18 Nov 2024 17:41:01 +0100 Subject: [PATCH 2/9] Add loading dependencies by module name only RFC --- .../loading-dependencies-by-module-name.org | 79 ++++++++++++++++++- 1 file changed, 78 insertions(+), 1 deletion(-) diff --git a/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org b/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org index a44d8cd367..45f565a142 100644 --- a/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org +++ b/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org @@ -1,5 +1,82 @@ #+title: Loading Dependencies By Module Name * Introduction +There is a well-known attack that implies loading of a malicious dependency +instead of the original one without notice to the party that does this loading. +In the industry it is usually called /DLL injection/ or /DLL preloading attack/ +and it is mostly associated with the Windows platform as it is known to be +particularly vulnerable to this kind of attack.[1] One of the recommendations +that safeguards against this type of attack is to specify fully qualified path +to a dependency.[2] + +Historically, oneTBB loads its optional dependencies during its initialization +process when these dependencies can be used for the first time. The way oneTBB +does this is by building full paths to their dependencies using the path where +oneTBB library resides by itself. It is the only sensible path which can be +obtained by oneTBB, whose usage conditions are not known at the time of +development. The purpose is to minimize the risk of a DLL injection attack issue +so that only certain paths are probed by the system loader. However, +dependencies of a dependency are still searched by their module names only.[3] +So, the risk is minimized only for a dependency itself and not for the libraries +it depends on, not to mention that the file of a dependency can be replaced in +the file system by an attacker, which breaks even that protection. Besides that, +loading of a dependency by specifying full path represents an inconvenience to +the developers who want to make use of their own variant of a dependency. Not +only they need to place their variant of a dependency to all of the places from +which it is going to be found and loaded by every client component that depends +on it, but also this makes problematic the implementation (if not impossible) of +some scenarios where being loaded dependency maintains single state shared among +all its clients. Such scenarios are hard to implement because copies of the same +DLL loaded from different paths are considered to be different DLLs and in +certain cases there is no support for filesystem linking mechanism to point to a +single file.[4, 5] + +So, what is the main problem due to which loading by a module name makes Windows +much more vulnerable to DLL injection than Linux? + +Besides difference in the order of accessing paths specified in the environment, +Windows also prioritizes searching in the directory from which the application +is loaded and current working directory.[2] Assuming that application is loaded +from the directory that requires administrative permission on write, which is +usually the case, it is the current working directory that forms the main DLL +preloading attack scenario.[1] + +There are approaches to exclude the current working directory from the search +order. However, for a library to avoid process-wide changes to the search order +the only viable solution for a run-time loading is to pass +~LOAD_LIBRARY_SAFE_CURRENT_DIRS~ flag to the ~LoadLibraryEx~ Windows API.[6] + +With the removal of the current working directory from loader's consideration, +the search order on Windows starts having little difference with the search +order on Linux. The difference includes the order in which directories specified +in the environment and system directories are considered, and the existence of +first step of looking into an application directory on Windows.[2, 7] + +Since the system environment variables and the environment of other processes +cannot be changed, the only vulnerable place is an application directory.[8, 9] +Because the application can be installed in a directory that does not require +administrative permissions on write, it still can be started by an account +having them. Unlike Linux systems, for the process started with administrative +permissions, the paths specified in the environment and the application +directory are still considered by the Windows system loader.[2, 7] Fortunately, +there is a signature verification process that helps validating the authenticity +of a binary before loading it into process address space and starting its +execution. + +- [1] [[https://support.microsoft.com/en-us/topic/secure-loading-of-libraries-to-prevent-dll-preloading-attacks-d41303ec-0748-9211-f317-2edc819682e1][Microsoft, "Secure loading of libraries to prevent DLL preloading attacks".]] +- [2] [[https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-security][Microsoft, "Dynamic-Link Library Security", 7 January 2021]] +- [3] [[https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#factors-that-affect-searching][Microsoft, "Dynamic-link library search order", 9 February 2023]]. +- [4] [[https://learn.microsoft.com/en-us/windows/win32/dlls/run-time-dynamic-linking][Microsoft, "Run-Time Dynamic Linking", 7 January 2021]] +- [5] [[https://github.com/NuGet/Home/issues/10734][NuGet project issue on GitHub, "NuGet packaging should support symlinks within packages", 7 April 2021]] +- [6] [[https://learn.microsoft.com/en-us/windows/win32/api/LibLoaderAPI/nf-libloaderapi-loadlibraryexa][Microsoft, "LoadLibraryExA function (libloaderapi.h)", 9 February 2023]] +- [7] [[https://www.man7.org/linux/man-pages/man8/ld.so.8.html][Linux man-pages 6.9.1, "ld.so(8) — Linux manual page", 8 May 2024]] +- [8] [[https://learn.microsoft.com/en-us/windows/win32/procthread/environment-variables][Microsoft, "Environment Variables", 7 January 2021]] +- [9] [[https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setenvironmentvariable][Microsoft, "SetEnvironmentVariable function (winbase.h)", 23 September 2022]] + * Proposal -* Open Questions +Based on the analysis in the "Introduction" section and to support versatile +distribution models of oneTBB this RFC proposes to: +1. Change loading of dependencies to load them by module names only. +2. Introduce signature verification step to the process of a dependency load. +3. Introduce the ~TBB_VERIFY_DEPENDENCY_SIGNATURE~ compilation option that would + enable signature verification process, and set it ~ON~ by default. From f887cf9b84513b37ad954aef0c27141ad37b628b Mon Sep 17 00:00:00 2001 From: "Fedotov, Aleksei" Date: Tue, 19 Nov 2024 12:56:01 +0100 Subject: [PATCH 3/9] Reorganize references Signed-off-by: Fedotov, Aleksei --- .../loading-dependencies-by-module-name.org | 21 ++++++++++--------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org b/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org index 45f565a142..69166c2e3d 100644 --- a/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org +++ b/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org @@ -63,16 +63,6 @@ there is a signature verification process that helps validating the authenticity of a binary before loading it into process address space and starting its execution. -- [1] [[https://support.microsoft.com/en-us/topic/secure-loading-of-libraries-to-prevent-dll-preloading-attacks-d41303ec-0748-9211-f317-2edc819682e1][Microsoft, "Secure loading of libraries to prevent DLL preloading attacks".]] -- [2] [[https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-security][Microsoft, "Dynamic-Link Library Security", 7 January 2021]] -- [3] [[https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#factors-that-affect-searching][Microsoft, "Dynamic-link library search order", 9 February 2023]]. -- [4] [[https://learn.microsoft.com/en-us/windows/win32/dlls/run-time-dynamic-linking][Microsoft, "Run-Time Dynamic Linking", 7 January 2021]] -- [5] [[https://github.com/NuGet/Home/issues/10734][NuGet project issue on GitHub, "NuGet packaging should support symlinks within packages", 7 April 2021]] -- [6] [[https://learn.microsoft.com/en-us/windows/win32/api/LibLoaderAPI/nf-libloaderapi-loadlibraryexa][Microsoft, "LoadLibraryExA function (libloaderapi.h)", 9 February 2023]] -- [7] [[https://www.man7.org/linux/man-pages/man8/ld.so.8.html][Linux man-pages 6.9.1, "ld.so(8) — Linux manual page", 8 May 2024]] -- [8] [[https://learn.microsoft.com/en-us/windows/win32/procthread/environment-variables][Microsoft, "Environment Variables", 7 January 2021]] -- [9] [[https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setenvironmentvariable][Microsoft, "SetEnvironmentVariable function (winbase.h)", 23 September 2022]] - * Proposal Based on the analysis in the "Introduction" section and to support versatile distribution models of oneTBB this RFC proposes to: @@ -80,3 +70,14 @@ distribution models of oneTBB this RFC proposes to: 2. Introduce signature verification step to the process of a dependency load. 3. Introduce the ~TBB_VERIFY_DEPENDENCY_SIGNATURE~ compilation option that would enable signature verification process, and set it ~ON~ by default. + +* References +1. [[https://support.microsoft.com/en-us/topic/secure-loading-of-libraries-to-prevent-dll-preloading-attacks-d41303ec-0748-9211-f317-2edc819682e1][Microsoft, "Secure loading of libraries to prevent DLL preloading attacks".]] +2. [[https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-security][Microsoft, "Dynamic-Link Library Security", 7 January 2021]] +3. [[https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#factors-that-affect-searching][Microsoft, "Dynamic-link library search order", 9 February 2023]]. +4. [[https://learn.microsoft.com/en-us/windows/win32/dlls/run-time-dynamic-linking][Microsoft, "Run-Time Dynamic Linking", 7 January 2021]] +5. [[https://github.com/NuGet/Home/issues/10734][NuGet project issue on GitHub, "NuGet packaging should support symlinks within packages", 7 April 2021]] +6. [[https://learn.microsoft.com/en-us/windows/win32/api/LibLoaderAPI/nf-libloaderapi-loadlibraryexa][Microsoft, "LoadLibraryExA function (libloaderapi.h)", 9 February 2023]] +7. [[https://www.man7.org/linux/man-pages/man8/ld.so.8.html][Linux man-pages 6.9.1, "ld.so(8) — Linux manual page", 8 May 2024]] +8. [[https://learn.microsoft.com/en-us/windows/win32/procthread/environment-variables][Microsoft, "Environment Variables", 7 January 2021]] +9. [[https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setenvironmentvariable][Microsoft, "SetEnvironmentVariable function (winbase.h)", 23 September 2022]] From 1cbd96d6cbc2e0b0be091bfdfd76eba9d8fcce99 Mon Sep 17 00:00:00 2001 From: "Fedotov, Aleksei" Date: Tue, 19 Nov 2024 12:57:03 +0100 Subject: [PATCH 4/9] Add documentation update into proposal Signed-off-by: Fedotov, Aleksei --- .../loading-dependencies-by-module-name.org | 2 ++ 1 file changed, 2 insertions(+) diff --git a/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org b/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org index 69166c2e3d..a5912738a1 100644 --- a/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org +++ b/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org @@ -70,6 +70,8 @@ distribution models of oneTBB this RFC proposes to: 2. Introduce signature verification step to the process of a dependency load. 3. Introduce the ~TBB_VERIFY_DEPENDENCY_SIGNATURE~ compilation option that would enable signature verification process, and set it ~ON~ by default. +4. Update documentation to include information about new + ~TBB_VERIFY_DEPENDENCY_SIGNATURE~ flag. * References 1. [[https://support.microsoft.com/en-us/topic/secure-loading-of-libraries-to-prevent-dll-preloading-attacks-d41303ec-0748-9211-f317-2edc819682e1][Microsoft, "Secure loading of libraries to prevent DLL preloading attacks".]] From f428b57dd1612aee4a2a1a3df8a60e1c7a16e471 Mon Sep 17 00:00:00 2001 From: "Fedotov, Aleksei" Date: Tue, 19 Nov 2024 18:03:38 +0100 Subject: [PATCH 5/9] Extend the part about signature verification --- .../loading-dependencies-by-module-name.org | 37 +++++++++++++------ 1 file changed, 26 insertions(+), 11 deletions(-) diff --git a/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org b/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org index a5912738a1..10e1cbc031 100644 --- a/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org +++ b/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org @@ -49,8 +49,8 @@ the only viable solution for a run-time loading is to pass With the removal of the current working directory from loader's consideration, the search order on Windows starts having little difference with the search order on Linux. The difference includes the order in which directories specified -in the environment and system directories are considered, and the existence of -first step of looking into an application directory on Windows.[2, 7] +in the environment and system directories are considered, and the presence of +the first step of looking into an application directory on Windows.[2, 7] Since the system environment variables and the environment of other processes cannot be changed, the only vulnerable place is an application directory.[8, 9] @@ -58,20 +58,35 @@ Because the application can be installed in a directory that does not require administrative permissions on write, it still can be started by an account having them. Unlike Linux systems, for the process started with administrative permissions, the paths specified in the environment and the application -directory are still considered by the Windows system loader.[2, 7] Fortunately, -there is a signature verification process that helps validating the authenticity -of a binary before loading it into process address space and starting its -execution. +directory are still considered by the Windows system loader.[2, 7] Therefore, an +attacker can update permissive installation directory with a malicious version +of a binary, hence making it loaded in a process with elevated permissions. Note +that specifying fully qualified path to the dependency does not help in this +case. + +Fortunately, there is a signature verification process that helps validating the +authenticity of a binary before loading it into process address space and +starting its execution. This allows making use of the established search order +while checking that genuine version of the dependency is used. However, not +loading the binary because of the failed signature verification might not be +always desired. Especially, during the development phase or for a software +distributor that does not have the signature with which to sign the binary. +Therefore, to preserve backward compatibility of such usage models, it is +essential to have possibility to disable signature verification. * Proposal Based on the analysis in the "Introduction" section and to support versatile distribution models of oneTBB this RFC proposes to: -1. Change loading of dependencies to load them by module names only. -2. Introduce signature verification step to the process of a dependency load. -3. Introduce the ~TBB_VERIFY_DEPENDENCY_SIGNATURE~ compilation option that would - enable signature verification process, and set it ~ON~ by default. -4. Update documentation to include information about new +1. Introduce signature verification step to the run-time dependency loading + process. +2. Introduce the ~TBB_VERIFY_DEPENDENCY_SIGNATURE~ compilation option that would + enable signature verification, and set it ~ON~ by default. +3. Update documentation to include information about new ~TBB_VERIFY_DEPENDENCY_SIGNATURE~ flag. +4. Pass ~LOAD_LIBRARY_SAFE_CURRENT_DIRS~ flag to the ~LoadLibraryEx~ calls so + that current working directory is excluded from the list of directories in + which the system loader looks when trying to find and resolve dependency. +5. Change dependency loading approach to load by module names only. * References 1. [[https://support.microsoft.com/en-us/topic/secure-loading-of-libraries-to-prevent-dll-preloading-attacks-d41303ec-0748-9211-f317-2edc819682e1][Microsoft, "Secure loading of libraries to prevent DLL preloading attacks".]] From e23a68058da73d5c4e51e50ddb59776090d3a2d5 Mon Sep 17 00:00:00 2001 From: "Fedotov, Aleksei" Date: Thu, 21 Nov 2024 14:40:20 +0100 Subject: [PATCH 6/9] Add small correction --- .../loading-dependencies-by-module-name.org | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org b/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org index 10e1cbc031..295254416c 100644 --- a/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org +++ b/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org @@ -70,7 +70,7 @@ starting its execution. This allows making use of the established search order while checking that genuine version of the dependency is used. However, not loading the binary because of the failed signature verification might not be always desired. Especially, during the development phase or for a software -distributor that does not have the signature with which to sign the binary. +distributor who does not have the signature with which to sign the binary. Therefore, to preserve backward compatibility of such usage models, it is essential to have possibility to disable signature verification. From c0b3a796b24d09afb1166d4541880ece9b461950 Mon Sep 17 00:00:00 2001 From: "Fedotov, Aleksei" Date: Tue, 26 Nov 2024 17:37:49 +0100 Subject: [PATCH 7/9] Clarify what changes are applied to what OSes --- .../loading-dependencies-by-module-name.org | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org b/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org index 295254416c..d89344812d 100644 --- a/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org +++ b/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org @@ -77,6 +77,8 @@ essential to have possibility to disable signature verification. * Proposal Based on the analysis in the "Introduction" section and to support versatile distribution models of oneTBB this RFC proposes to: + +On Windows only: 1. Introduce signature verification step to the run-time dependency loading process. 2. Introduce the ~TBB_VERIFY_DEPENDENCY_SIGNATURE~ compilation option that would @@ -86,7 +88,9 @@ distribution models of oneTBB this RFC proposes to: 4. Pass ~LOAD_LIBRARY_SAFE_CURRENT_DIRS~ flag to the ~LoadLibraryEx~ calls so that current working directory is excluded from the list of directories in which the system loader looks when trying to find and resolve dependency. -5. Change dependency loading approach to load by module names only. + +On all OSes: +- Change dependency loading approach to load by module names only. * References 1. [[https://support.microsoft.com/en-us/topic/secure-loading-of-libraries-to-prevent-dll-preloading-attacks-d41303ec-0748-9211-f317-2edc819682e1][Microsoft, "Secure loading of libraries to prevent DLL preloading attacks".]] From 9de496a5b4a837d816ff9f3d5ac304b76266ead4 Mon Sep 17 00:00:00 2001 From: Aleksei Fedotov Date: Tue, 10 Dec 2024 12:39:56 +0100 Subject: [PATCH 8/9] Apply suggestions from code review Co-authored-by: Mike Voss --- .../loading-dependencies-by-module-name.org | 34 +++++++++---------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org b/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org index d89344812d..5c5ae0181d 100644 --- a/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org +++ b/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org @@ -1,22 +1,22 @@ #+title: Loading Dependencies By Module Name * Introduction -There is a well-known attack that implies loading of a malicious dependency +There is a well-known attack that involves loading of a malicious dependency instead of the original one without notice to the party that does this loading. In the industry it is usually called /DLL injection/ or /DLL preloading attack/ and it is mostly associated with the Windows platform as it is known to be -particularly vulnerable to this kind of attack.[1] One of the recommendations +particularly vulnerable to this kind of attack [1]. One of the recommendations that safeguards against this type of attack is to specify fully qualified path -to a dependency.[2] +to a dependency [2]. Historically, oneTBB loads its optional dependencies during its initialization -process when these dependencies can be used for the first time. The way oneTBB +process when these dependencies are used for the first time. The way oneTBB does this is by building full paths to their dependencies using the path where -oneTBB library resides by itself. It is the only sensible path which can be +the oneTBB library itself resides. It is the only sensible path which can be obtained by oneTBB, whose usage conditions are not known at the time of development. The purpose is to minimize the risk of a DLL injection attack issue so that only certain paths are probed by the system loader. However, -dependencies of a dependency are still searched by their module names only.[3] +dependencies of a dependency are still searched by their module names only [3]. So, the risk is minimized only for a dependency itself and not for the libraries it depends on, not to mention that the file of a dependency can be replaced in the file system by an attacker, which breaks even that protection. Besides that, @@ -25,40 +25,40 @@ the developers who want to make use of their own variant of a dependency. Not only they need to place their variant of a dependency to all of the places from which it is going to be found and loaded by every client component that depends on it, but also this makes problematic the implementation (if not impossible) of -some scenarios where being loaded dependency maintains single state shared among +some scenarios where the dependency being loaded maintains single state shared among all its clients. Such scenarios are hard to implement because copies of the same DLL loaded from different paths are considered to be different DLLs and in certain cases there is no support for filesystem linking mechanism to point to a -single file.[4, 5] +single file [4, 5]. So, what is the main problem due to which loading by a module name makes Windows much more vulnerable to DLL injection than Linux? Besides difference in the order of accessing paths specified in the environment, Windows also prioritizes searching in the directory from which the application -is loaded and current working directory.[2] Assuming that application is loaded -from the directory that requires administrative permission on write, which is +is loaded and current working directory [2]. Assuming that application is loaded +from a directory that requires administrative permission on write, which is usually the case, it is the current working directory that forms the main DLL -preloading attack scenario.[1] +preloading attack scenario [1]. There are approaches to exclude the current working directory from the search order. However, for a library to avoid process-wide changes to the search order -the only viable solution for a run-time loading is to pass -~LOAD_LIBRARY_SAFE_CURRENT_DIRS~ flag to the ~LoadLibraryEx~ Windows API.[6] +the only viable solution for run-time loading is to pass +~LOAD_LIBRARY_SAFE_CURRENT_DIRS~ flag to the ~LoadLibraryEx~ Windows API [6]. With the removal of the current working directory from loader's consideration, the search order on Windows starts having little difference with the search order on Linux. The difference includes the order in which directories specified in the environment and system directories are considered, and the presence of -the first step of looking into an application directory on Windows.[2, 7] +the first step of looking into an application directory on Windows [2, 7]. Since the system environment variables and the environment of other processes -cannot be changed, the only vulnerable place is an application directory.[8, 9] +cannot be changed, the only vulnerable place is an application directory [8, 9]. Because the application can be installed in a directory that does not require administrative permissions on write, it still can be started by an account having them. Unlike Linux systems, for the process started with administrative permissions, the paths specified in the environment and the application -directory are still considered by the Windows system loader.[2, 7] Therefore, an +directory are still considered by the Windows system loader [2, 7]. Therefore, an attacker can update permissive installation directory with a malicious version of a binary, hence making it loaded in a process with elevated permissions. Note that specifying fully qualified path to the dependency does not help in this @@ -72,7 +72,7 @@ loading the binary because of the failed signature verification might not be always desired. Especially, during the development phase or for a software distributor who does not have the signature with which to sign the binary. Therefore, to preserve backward compatibility of such usage models, it is -essential to have possibility to disable signature verification. +essential to have the possibility to disable signature verification. * Proposal Based on the analysis in the "Introduction" section and to support versatile From 8cba89f9dcac4b154aa650d7278ccedb67ba3b63 Mon Sep 17 00:00:00 2001 From: "Fedotov, Aleksei" Date: Tue, 10 Dec 2024 12:42:59 +0100 Subject: [PATCH 9/9] Align formatting to be within 80 characters --- .../loading-dependencies-by-module-name.org | 26 +++++++++---------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org b/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org index 5c5ae0181d..c35db3309d 100644 --- a/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org +++ b/rfcs/proposed/loading-dependencies/loading-dependencies-by-module-name.org @@ -10,9 +10,9 @@ that safeguards against this type of attack is to specify fully qualified path to a dependency [2]. Historically, oneTBB loads its optional dependencies during its initialization -process when these dependencies are used for the first time. The way oneTBB -does this is by building full paths to their dependencies using the path where -the oneTBB library itself resides. It is the only sensible path which can be +process when these dependencies are used for the first time. The way oneTBB does +this is by building full paths to their dependencies using the path where the +oneTBB library itself resides. It is the only sensible path which can be obtained by oneTBB, whose usage conditions are not known at the time of development. The purpose is to minimize the risk of a DLL injection attack issue so that only certain paths are probed by the system loader. However, @@ -25,11 +25,11 @@ the developers who want to make use of their own variant of a dependency. Not only they need to place their variant of a dependency to all of the places from which it is going to be found and loaded by every client component that depends on it, but also this makes problematic the implementation (if not impossible) of -some scenarios where the dependency being loaded maintains single state shared among -all its clients. Such scenarios are hard to implement because copies of the same -DLL loaded from different paths are considered to be different DLLs and in -certain cases there is no support for filesystem linking mechanism to point to a -single file [4, 5]. +some scenarios where the dependency being loaded maintains single state shared +among all its clients. Such scenarios are hard to implement because copies of +the same DLL loaded from different paths are considered to be different DLLs and +in certain cases there is no support for filesystem linking mechanism to point +to a single file [4, 5]. So, what is the main problem due to which loading by a module name makes Windows much more vulnerable to DLL injection than Linux? @@ -58,11 +58,11 @@ Because the application can be installed in a directory that does not require administrative permissions on write, it still can be started by an account having them. Unlike Linux systems, for the process started with administrative permissions, the paths specified in the environment and the application -directory are still considered by the Windows system loader [2, 7]. Therefore, an -attacker can update permissive installation directory with a malicious version -of a binary, hence making it loaded in a process with elevated permissions. Note -that specifying fully qualified path to the dependency does not help in this -case. +directory are still considered by the Windows system loader [2, 7]. Therefore, +an attacker can update permissive installation directory with a malicious +version of a binary, hence making it loaded in a process with elevated +permissions. Note that specifying fully qualified path to the dependency does +not help in this case. Fortunately, there is a signature verification process that helps validating the authenticity of a binary before loading it into process address space and