실행 파일 수정으로 발생할 수 있는 보안 위험성

1. 실행 파일 구조

이미 다음 주제를 통하여 실행 파일의 구조에 대하여 살펴보았다.

문서 파일이 정해진 형식으로 구성되어 있는 것처럼 실행 파일도 문서 파일과 크게 다르지 않은 구조를 가지고 있으며, 구성 요소 중 .text 섹션의 기계어 코드가 로드되어 동작하게 된다.



2. 실행 파일 수정

  • 그렇다면 .text 섹션에 저장된 기계어 코드를 직접 수정함으로써 프로그램의 실행 동작을 변경할 수 있다는 것을 의미한다.
  • 이러한 특성을 활용하면, 프로그램의 소스를 수정하지 않고도 실행 결과를 변경할 수 있다.

2.1. bin to hex

xxd 명령어를 사용하여 실행 파일을 텍스트 형식의 hex 파일로 변환한다.


$ objdump -d -M intel add
Disassembly of section .text:
0000000000401000 <_start>:
  401000: b0 02    mov al,0x2    ; Load the value 2 into the AL register
  401002: 04 03    add al,0x3    ; Add the immediate value 3 to AL (AL = 2 + 3)

$ ./add
result: 5

$ xxd add > add.hex

2.2. edit hex

텍스트 편집기로 생성된 "add.hex" 파일을 열어 offset 0x00001003 위치의 값 "03"을 "01"로 수정하고 저장한다.


  • offset은 실행 파일 내에서 수정할 바이트의 위치를 의미한다.
  • 해당 위치의 값 03은 add al, 명령어의 연산 대상이 되는 값 으로, 이를 `01`로 변경함으로써 연산 결과를 조정할 수 있다.

2.3. hex to bin

xxd 명령어로 텍스트 형식의 hex 파일을 다시 이진형식의 파일로 변환한다.


$ xxd -r add.hex > add
$ chmod +x add

$ objdump -d -M intel add
Disassembly of section .text:
0000000000401000 <_start>:
  401000: b0 02    mov al,0x2    ; Load the value 2 into the AL register
  401002: 04 01    add al,0x1    ; Add the immediate value 1 to AL (AL = 2 + 1)

$ ./add
result: 3

∴ 실행 결과를 확인해 보면 기존 출력 값 "result: 5"이 "result: 3"으로 변경된 것을 확인할 수 있다.

3. 실행 파일 수정 방지

  • 앞에서 본 예와 같이 실행 파일은 코드 영역뿐만 아니라 데이터 영역을 포함한 모든 구성 요소가 수정 가능하다.
  • 이는 프로그램 소스를 수정하지 않고도 실행 파일의 동작을 변경할 수 있다는 장점을 제공한다.
  • 반면, 실행 파일이 임의로 수정될 수 있다는 보안상의 위험성도 함께 존재한다.

  • 그렇다면 이러한 위험성을 어떻게 막을 수 있을까?
  • 이러한 위험성을 방지하기 위해 현재 운영체제에서는 다양한 보호 기법과 보안 방법들이 사용되고 있다.

3.1. 해시 기반 무결성 검증

  • 해시 기반 무결성 검증은 실행 파일의 내용을 해시 함수(Hash Function)를 이용해 고정 길이의 값으로 계산하는 방식이다.
  • 실행 시점에 계산된 해시 값이 원본과 다를 경우, 실행 파일이 변조되었음을 탐지할 수 있다.
  • 대표적인 해시 알고리즘으로는 SHA-256, SHA-1, MD5 등이 있다.

3.2. 디지털 서명 및 코드 서명

  • 디지털 서명 및 코드 서명은 공개 키 암호화 기반의 서명을 실행 파일에 포함시키는 방식이다.
  • 운영체제는 실행 전에 서명 검증(Signature Verification)을 수행하여, 실행 파일이 신뢰된 발급자에 의해 생성되었고 이후 변경되지 않았음을 확인한다.
    • Windows의 Authenticode와 macOS의 Code Signing이 대표적인 예이다.

3.3. 파일 권한 및 접근 제어

  • 운영체제는 파일 시스템 수준에서 읽기(Read), 쓰기(Write), 실행(Execute) 권한을 분리하여 관리한다.
  • 이를 통해 특정 사용자나 프로세스만 실행 파일을 수정할 수 있도록 제한함으로써 비인가된 변경을 방지한다.

3.4. 메모리 보호 기법

  • W^X (Write XOR Execute)
    • 코드가 실행되는 메모리 영역에서는 쓰기를 허용하지 않아 코드 수정을 방지한다.
    • 이 기술은 주로 버퍼 오버플로우(Buffer Overflow)와 같은 메모리 취약점 공격을 방어하기 위해 설계되었다.
  • DEP (Data Execution Prevention)
    • 데이터 영역에서 코드 실행을 차단한다.
  • ASLR (Address Space Layout Randomization)
    • 프로그램이 실행될 때마다 코드와 데이터가 메모리에 배치되는 주소를 다르게 한다.

메모리 보호 기법은 실행 중인 프로그램의 메모리에 대해 권한 기반 보호를 적용하는 방식이다.

용어 방법 역할
DEP 데이터 영역은 실행을 금지한다. 실행 영역을 제한한다.
W^X 실행 중인 코드는 수정하지 못하게 한다. 코드 수정을 차단한다.
ASLR 메모리 위치를 실행할 때마다 다르게 배치한다. 주소 예측을 방지한다.