Microsoft MVP성태의 닷넷 이야기
.NET Framework: 667. bypassTrustedAppStrongNames 옵션 설명 [링크 복사], [링크+제목 복사],
조회: 12544
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 3개 있습니다.)

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://docs.microsoft.com/en-us/dotnet/framework/app-domains/how-to-disable-the-strong-name-bypass-feature

Strong Name Bypass
; https://blogs.msdn.microsoft.com/shawnfa/2008/05/14/strong-name-bypass/

정리하면 다음의 조건인데요.

  1. Fully signed (delay signed assemblies still require a skip verification entry)
  2. Fully trusted (without considering its strong name evidence)
  3. Loaded into a Fully trusted AppDomain
  4. 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가지 조건에 안 맞는 것이 있는지!)

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 7/31/2017]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 46  47  48  49  50  51  52  [53]  54  55  56  57  58  59  60  ...
NoWriterDateCnt.TitleFile(s)
12319정성태9/10/20209879오류 유형: 647. smigdeploy.exe를 Windows Server 2016에서 실행할 때 .NET Framework 미설치 오류 발생
12318정성태9/9/20209334오류 유형: 646. OpenVPN - "TAP-Windows Adapter V9" 어댑터의 "Network cable unplugged" 현상
12317정성태9/9/202011671개발 환경 구성: 511. Beats용 Kibana 기본 대시 보드 구성 방법
12316정성태9/8/202010095디버깅 기술: 170. WinDbg Preview 버전부터 닷넷 코어 3.0 이후의 메모리 덤프에 대해 sos.dll 자동 로드
12315정성태9/7/202012393개발 환경 구성: 510. Logstash - FileBeat을 이용한 IIS 로그 처리 [2]
12314정성태9/7/202011043오류 유형: 645. IIS HTTPERR - Timer_MinBytesPerSecond, Timer_ConnectionIdle 로그
12313정성태9/6/202012110개발 환경 구성: 509. Logstash - 사용자 정의 grok 패턴 추가를 이용한 IIS 로그 처리
12312정성태9/5/202015997개발 환경 구성: 508. Logstash 기본 사용법 [2]
12311정성태9/4/202011245.NET Framework: 937. C# - 간단하게 만들어 보는 리눅스의 nc(netcat), json_pp 프로그램 [1]
12310정성태9/3/202010514오류 유형: 644. Windows could not start the Elasticsearch 7.9.0 (elasticsearch-service-x64) service on Local Computer.
12309정성태9/3/202010259개발 환경 구성: 507. Elasticsearch 6.6부터 기본 추가된 한글 형태소 분석기 노리(nori) 사용법
12308정성태9/2/202011533개발 환경 구성: 506. Windows - 단일 머신에서 단일 바이너리로 여러 개의 ElasticSearch 노드를 실행하는 방법
12307정성태9/2/202012275오류 유형: 643. curl - json_parse_exception / Invalid UTF-8 start byte
12306정성태9/1/202010449오류 유형: 642. SQL Server 시작 오류 - error code 10013
12305정성태9/1/202011349Windows: 172. "Administered port exclusions"이 아닌 포트 범위 항목을 삭제하는 방법
12304정성태8/31/202010290개발 환경 구성: 505. 윈도우 - (네트워크 어댑터의 우선순위로 인한) 열거되는 IP 주소 순서를 조정하는 방법
12303정성태8/30/202010474개발 환경 구성: 504. ETW - 닷넷 프레임워크 기반의 응용 프로그램을 위한 명령행 도구 etrace 소개
12302정성태8/30/202010350.NET Framework: 936. C# - ETW 관련 Win32 API 사용 예제 코드 (5) - Private Logger파일 다운로드1
12301정성태8/30/202010673오류 유형: 641. error MSB4044: The "Fody.WeavingTask" task was not given a value for the required parameter "IntermediateDir".
12300정성태8/29/202010055.NET Framework: 935. C# - ETW 관련 Win32 API 사용 예제 코드 (4) CLR ETW Consumer파일 다운로드1
12299정성태8/27/202010990.NET Framework: 934. C# - ETW 관련 Win32 API 사용 예제 코드 (3) ETW Consumer 구현파일 다운로드1
12298정성태8/27/202010723오류 유형: 640. livekd - Could not resolve symbols for ntoskrnl.exe: MmPfnDatabase
12297정성태8/25/20209969개발 환경 구성: 503. SHA256 테스트 인증서 생성 방법
12296정성태8/24/202010327.NET Framework: 933. C# - ETW 관련 Win32 API 사용 예제 코드 (2) NT Kernel Logger파일 다운로드1
12295정성태8/24/20209767오류 유형: 639. Bitvise - Address is already in use; bind() in ListeningSocket::StartListening() failed: Windows error 10013: An attempt was made to access a socket ,,,
12293정성태8/24/202011104Windows: 171. "Administered port exclusions" 설명
... 46  47  48  49  50  51  52  [53]  54  55  56  57  58  59  60  ...