https://arxiv.org/pdf/2001.09592.pdf

주의

지극히 개인적인 의견만 들어가 있습니다. (본인도 뭘 썼는지 모르겠음)

Problem Statement

네트워크 프로토콜을 하는데에는 많은 어려움이 있다. 첫째, 네트워크 프로토콜은 사이즈가 크고 복잡하다. 둘째, 테스트와 검증을 통해 에러를 얻는데까지 걸리는 시간이 길다. 셋째, 실제 환경에서 테스트하는 것과 가상의 환경에서 테스트 하는 것과 상황이 다르다.
네트워크 프로토콜을 퍼징하는데 많은 시도가 있었다. 퍼징만 사용하여 네트워크를 테스트하거나 symbolic execution만을 사용하여 네트워크를 테스트하려는 시도들이 있었지만 low coverage 문제나 path explosion 문제가 있었다. 따라서 둘을 섞어 네트워크를 퍼징하려 한다.

Summary

FuSeBMC는 퍼징만으로 탐색하기 어려웠던 부분들을 symbolic execution과 BMC(Bounded Model Checking) 엔진으로 해결한다. 총 다섯단계로 퍼징이 진행되는데, 아래와 같다.

  1. Protocol specification analyzer가 concrete packet을 만든다.
  2. AFL을 통해 테스트 케이스를 생성한다. 그 뒤 function coverage를 측정한다.
  3. 너무 많은 경로들을 지나면서 해당 경로들이 code coverage를 늘린다면 (i.e invalid packet) 이들을 symbolic packet으로 마킹한다.
  4. Path-based symbolic execution과 BMC를 통해 path들을 개척한다.
  5. Concrete packet에 symbol 들을 붙여서 symbolic packet으로 바꾼다.

아래 두 기준을 이용하여 퍼저를 평가하였다.

  1. Protocol specification에 대해 버그를 찾는 능력
  2. 버그를 찾기까지 걸리는 시간

또한, 실험적 목표는 아래와 같다.

  1. EG1 (취약점 감지) : Real-world network protocol 구현들에서 취약점을 찾을 수 있는가
  2. EG2 (witness validation) : 감지된 취약점에서 좀 더 많은 정보를 얻을 수 있는가 (취약점에 대한 정보)

ESBMC, KLEE, Map2Check, SPIKE를 간단한 FTP 서버에 적용시킨 뒤 실험한 결과 ESBMC만 EG1을 달성할 수 있었다. 또한 ESBMC를 적용하였을 때 bad state까지 도달하는 경로를 얻을 수 있었고, 이는 EG2를 달성한 것과 동치이다.

Strengths

퍼징과 Symbolic execution의 한계를 깨며, 단시간에 취약점을 찾을 수 있다는 것에서 장점을 보이고 있다.

Weaknesses

아래와 같은 부분이 애매하거나 잘 서술되어 있지 않다.

  1. Protocol specification을 어떻게 읽었는지
  2. Fuzzing exploration 전략이 무엇인지
  3. Concrete packet, symbolic packet의 정의가 무엇인지
  4. Symbolic marking의 과정이 무엇인지
  5. Coverage를 측정하기 위한 instrumentation 방법은 무엇인지 (AFL을 사용했다고 서술되어 있지만 정확하지 않다)
  6. Symbolic execution을 어떤 방식으로 수행했으며, input validation을 어떤 프레임워크로 수행했는지
  7. Driller와 차이가 무엇인지
  8. 네트워크 프로토콜에서 symbolic execution과 기존 퍼징 방법을 섞어야 되는 이유가 정확히 무엇인지 (프로토콜의 특성이 사유가 될 수 있는지)

또한 평가 방법에도 문제가 많다.

  1. FTP 서버에 대해 퍼징을 수행했는데 다른 퍼저들은 얼마나 빨리 취약점을 찾는지
  2. 테스트를 몇회 수행했는지 (시드 생성 등에 랜덤한 요소가 있기 때문에)
  3. FTP 서버와 서버를 하나 새롭게 만들어서 테스트를 수행했는데 이렇게 했을 때 리얼월드에서 평가를 진행했다고 할 수 있는지

Further Discussions

네트워크 프로토콜의 특성에 따른 퍼징 기법으로 무엇이 적절할지 더 논의가 필요해 보인다. 또한, 리얼월드에 가까운 방법으로 퍼저를 평가할 수 있는 방법이 무엇일지도 논의가 필요해 보인다.

https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-eckert.pdf

주의

지극히 개인적인 의견만 들어가 있습니다. (본인도 대체 뭘 썼는지 모르겠음)

선정 이유

CVE-2019-6778 을 분석하다 보니 heap과 유사한 점들을 찾았다.

  1. malloc, free와 같은 transaction에 의해 내부 state가 변하는 것이 동일하고 (패킷이 들어왔을 때 state가 변한다)
  2. 패킷이 들어왔을 때 발생하는 특정 메모리 시퀀스가 존재한다.

이런 상황에서 오버플로우와 같이 명확한 취약점이 존재하지 않더라도 동적 메모리 부분에서 버그를 찾을 수 있지 않을까라는 생각에 해당 논문을 선정하였다. 해당 논문을 통해 transaction에 의한 state transition이 있는 모델에서 취약점을 찾는 방법을 배우고자 한다.

요약

모델

모델은 (Heap Interaction Model) 3요소로 구성되어 있다.

  1. Heap-state : 현재 힙 상태를 말한다. mmaped memory, allocated chunks, freed chunks 로 구성된다.
  2. Transactions : malloc, free, overflow등으로 state transition이 일어날 수 있는 행동들을 정의한다.
  3. New heap-state : transaction에 의해 변한 heap state다.

모델은 위와 같이 주어져 있지만 실제 바이너리에서 분석을 진행한다고 할 때 transaction만 API로써 정의되어 있을 뿐 정확한 heap-state는 dynamic allocator의 버전마다 다르기 때문에 사실상 알려져 있지 않다고 보면 된다.

마지막으로, transaction 수를 제한하여 symbolic execution의 문제인 path explosion과 constraint complexity를 어느정도 해소한다.

Transactions

Transaction을 usage와 mis-usage로 분류할 수 있다.

  • Usage : malloc, free와 같이 정상적으로 처리되는 경우이다.
  • Mis-Usage : overflow, UAF, Double Free, Fake Free와 같이 정상적이지 않은 행동들이다.

이들에 대한 간단한 예시를 들면 아래와 같다.

malloc

size에 해당하는 symbolic value가 주어졌을 때 아래 3가지가 발생한다.

  1. Return : addr, actual size에 해당하는 symbolic value들이 발생한다.
  2. Constrains : 주어진 size에 대해 actual size가 달라지기 때문에 이에 대한 constrain들이 주어지게 된다.
  3. Modifies : heap-state의 변화가 정의된다.

UAF

Freed chunk에 해당하는 addr와 actual value가 주어지고 특정 symbolic data가 주어지면 UAF에 의해 symbolic byte들로 metadata overwrite가 발생하거나 heap state가 변화한다.

Interaction Model

주어진 transaction sequence를 가지고 permutation을 만들고, permutation을 소스코드로 변환한다. (PoC가 될 수도 있는 후보들) Permutation에는 무조건 하나 이상의 mis-use가 포함되어 버그가 발생할 수 있어야 한다. 그 뒤 소스코드를 컴파일해서 바이너리로 변환한다. 단, 이 과정에서 symbolic memory를 사용할 수 있도록 instrumentation 과정을 거쳐야 한다.

Model Checking

Symbolic execution을 사용하여 앞 단계에서 생성한 바이너리를 실행한다. (Shared library도 같이 실행됨) 이 과정에서 mmap이나 brk와 같은 system call도 시뮬레이팅하며 (angr 프레임워크를 사용하기 때문) DFS를 통해 속도를 향상한다. (하나의 path를 하나의 contraint set에 대응시킨다)

Security Violation Identification

Symbolic execution을 통해 아래 4개의 state들을 검색한다.

  1. OA (Overlapping Allocation)
  2. NHA (Non-Heap Allocation)
  3. AW (Arbitrary Write)
  4. AWC (Arbitrary Write Constraint) : AW가 가증하지만 특정 content가 존재하는 부분만 쓰기 가능

PoC Generation

Symbolic data를 concrete data로 바꿔서 PoC 코드를 생성한다.

전체 아키텍쳐

총평

Symbolic execution을 통해 transaction based model을 테스트한다는 것이 인상적이었다. 하지만 네트워크에 넣어서 적용시키는데에는 한계점이 있다. 만약에 네트워크에서 mis-use를 정의할 수 있고 해당 mis-use를 통해 익스플로잇을 하는데 어려움이 많다면 해당 프레임워크를 수정해서 사용하는 것도 나쁘지 않은 것 같다.

+ Recent posts