bypassTrustedAppStrongNames 옵션 설명
프로그램을 실행했을 때 다음과 같은 예외가 발생할 수 있습니다.
Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'ClassLibrary1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=90aac46759611727' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A) ---> System.Security.SecurityException: Strong name validation failed. (Exception from HRESULT: 0x8013141A)
--- End of inner exception stack trace ---
at ClassLibrary1.Class1.Do()
at ConsoleApp1.Program.Main(String[] args) in C:\ConsoleApp1\Program.cs:line 11
원인은 간단합니다. 강력한 이름(Strong-named)으로 서명된 어셈블리를 로드하려고 했지만 해당 어셈블리의 내용이 임의로 변경된 경우 서명된 내용과 달라 로딩 시 예외가 발생한 것입니다.
재현을 한번 해볼까요? ^^
우선 다음과 같은 코드를 가진 라이브러리를 생성하고 서명을 한 후,
// ClassLibrary1.dll 프로젝트
using System;
namespace ClassLibrary1
{
public class Class1
{
public void Do()
{
Console.WriteLine("TEST IS GOOD");
}
}
}
콘솔 EXE에서 이렇게 사용합니다.
// .NET 4.0 이상의 ConsoleApp1.exe 프로젝트
using System;
namespace ConsoleApp1
{
class Program
{
static void Main(string[] args)
{
ClassLibrary1.Class1 cl = new ClassLibrary1.Class1();
cl.Do();
Console.WriteLine("Press...");
Console.ReadLine();
}
}
}
빌드한 결과물에서, dnSpy.exe 등을 이용해 Class1.Do 메서드의 내용을 임의로 수정하거나 다음의 글에 따라,
닷넷의 어셈블리 서명 데이터 확인 방법
; https://www.sysnet.pe.kr/2/0/10816
서명 데이터를 임의로 바꿔주면 됩니다.
그런데, 이렇게 변조된 DLL을 사용함에도 불구하고 여전히 정상적으로 실행될 것입니다. 왜냐하면, .NET 3.5 SP1부터는 "Full Trust" 상태의 AppDomain에 어셈블리가 로딩될 때는 서명을 검증하지 않기 때문입니다. 이에 대해서는 다음의 글들이 자세하게 설명하고 있습니다.
How to: Disable the Strong-Name Bypass Feature
; https://learn.microsoft.com/en-us/dotnet/framework/app-domains/how-to-disable-the-strong-name-bypass-feature
Strong Name Bypass
; https://learn.microsoft.com/ko-kr/archive/blogs/shawnfa/strong-name-bypass
정리하면 다음의 조건인데요.
- Fully signed (delay signed assemblies still require a skip verification entry)
- Fully trusted (without considering its strong name evidence)
- Loaded into a Fully trusted AppDomain
- Loaded from a location under the AppDomain's ApplicationBase
따라서 "Fully trusted"로 실행되는 ConsoleApp.exe 내의 "Fully trusted AppDomain" 내에 (변조되었지만) ClassLibrary1.dll이 로드되기 때문에 서명 확인 절차가 생략되므로 Class1.Do 메서드의 내용을 임의로 수정했어도 별다른 영향 없이 잘 실행이 된 것입니다.
만약 이전처럼 무조건 서명 데이터를 검증하도록 만들고 싶다면 app.config 파일에 bypassTrustedAppStrongNames 옵션을 다음과 같이 설정해 주면 됩니다.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
<bypassTrustedAppStrongNames enabled="false" />
</runtime>
</configuration>
즉, .NET 3.5 SP1 이후부터는 bypassTrustedAppStrongNames 옵션의 기본 값이 true인 체로 실행되고 있는 것입니다.
반면, 변조된 ClassLibrary1.dll을 ASP.NET 웹 애플리케이션에서 참조하는 경우에는 상황이 달라집니다. 로컬에서 IIS 또는 IIS Express에 상관없이 다음과 같은 예외가 발생합니다.
System.IO.FileLoadException: 'Could not load file or assembly 'file:///C:\WebApplication1\bin\ClassLibrary1.dll' or one of its dependencies. Strong name signature could not be verified. The assembly may have been tampered with, or it was delay signed but not fully signed with the correct private key. (Exception from HRESULT: 0x80131045)'
재미있는 것은, 검증이 이뤄지는 DLL의 위치가 ASP.NET의 "/bin" 폴더 및 그 하위인 경우로만 제한된다는 것입니다. 즉, 그 이외의 위치에 있는 DLL인 경우는 검증 대상이 아니라는 것인데, 가령 ClassLibrary1.dll 파일을 몇몇 폴더에 복사해 다음과 같은 식으로 직접 테스트해 볼 수 있습니다.
protected void Page_Load(object sender, EventArgs e)
{
string path = AppDomain.CurrentDomain.BaseDirectory; // "C:\\WebApplication1"
{
string filePath = Path.Combine(path, "ClassLibrary1.dll");
Assembly asm = Assembly.LoadFrom(filePath, null); // OK - c:\WebApplication1\ClassLibrary1.dll
}
{
string filePath = Path.Combine(path, "Test", "ClassLibrary1.dll");
Assembly asm = Assembly.LoadFrom(filePath, null); // OK - c:\WebApplication1\Test\ClassLibrary1.dll
}
{
string filePath = Path.Combine(path, "bin", "Test", "ClassLibrary1.dll");
Assembly asm = Assembly.LoadFrom(filePath, null); // 검증 실패 - c:\WebApplication1\bin\Test\ClassLibrary1.dll
}
}
더욱 재미있는 것은, ASP.NET의 경우 bypassTrustedAppStrongNames 조건을 false로 주어도 여전히 bin 폴더(및 그 하위) 이외에 배포된 DLL은 검증 과정 없이 직접 로딩이 가능하다는 점입니다. 또한 그 반대로 bypassTrustedAppStrongNames 조건을 true로 주어도 bin 폴더(및 그 하위)의 경우에는 검증 작업이 생략되지 않습니다. (아쉽게도 그 이유는 아직 모르겠습니다. ASP.NET이 특별 대우인 것인지, 아니면 bypassTrustedAppStrongNames를 타기 위한 4가지 조건에 안 맞는 것이 있는지!)
(
첨부 파일은 이 글의 예제 코드를 포함합니다.)
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]