Park, Geon (re-st)

Abstract

네트워크 퍼징에서는 특정 변수들의 값을 커버리지와 함께 모니터링하는 방식이 활용된다. 이 방법을 적용한 CSFuzzer 연구는 20개가 넘는 프로토콜을 분석하여, 추적하기에 적합한 변수를 식별하는데 유용한 기준들을 도출해낸다.
이 연구의 구현 과정을 살펴보면, 관찰과 경험을 바탕으로 한 휴리스틱의 가치를 이해하게 된다.

본문

네트워크 프로토콜을 대상으로 하는 퍼징은 커버리지뿐 아니라 일부 변수의 상태도 함께 추적하는 방식이 인기이다. 이는 프로토콜의 여러 상태를 커버리지만으로 구별해낼 수는 없다는 판단에서 나왔다. 물론 모든 변수의 상태를 다 저장한다면 너무 많은 입력을 저장할 것이므로, 실행흐름에 중요한 영향을 미치는 변수만을 추적한다. 이를 상태 변수라 부른다.

CSFuzzer는 20개 이상의 프로토콜을 분석해서 상태 변수를 인식하는 법을 만들었는데, 이 과정이 아주 재미있는 휴리스틱의 연속이다. 하나만 보자면, 상태 변수를 분기문의 조건으로 사용할 때 개발자들이 취하는 행동을 관찰해 역으로 이를 만족하는 변수를 찾아내는 것이다. 분석된 행동은 분기문 사이 함수 이름이 서로 비슷하다거나, 분기문의 가지가 변수의 가능한 값의 수와 같다거나 등으로 완전한 개발자 휴리스틱이다. %% 이 조건을 사용하는 방식도 왠지 두루뭉실해, 세 조건 중 둘 이상을 만족할 때 상태 변수로 인식하도록 되어 있다. %%

이 연구는 처음에 볼 때는 찜찜했으나 읽을수록 제대로 되었다는 생각이 든다. 처음에는, 분기문 사이 함수 이름에서 맥락을 찾을 수 있다는 조건이 너무 ‘현실주의’적이거나 맹랑하게 느껴졌다. 그러나 곰곰이 생각하면 이는 내 지난 글의 ‘‘연구란 무엇인가’‘에 제시한 조건을 다 통과하는 좋은 연구이다. 휴리스틱을 제시하기에 앞서 충분한 맥락과 이유를 제시하고, 이를 효과적으로 이용하는 퍼징으로 좋은 결과까지 이어 나갔기 때문이다.

나는, 진득한 관찰이 뛰어난 연구를 만든다는 시사점을 얻었다. 좋은 아이디어가 있더라도, 휴리스틱으로 적절한 값을 찾지 못한다면 성능향상을 보지 못해, 폐기될 것이다. 그 휴리스틱은 다름아닌 연구자의 관찰과 경험에 의해 나온 것이다. 소개한 연구는 코드 분기문을 뜯어보지만, 나는 변수를 추적하지 않으므로 취약점의 특징을 관찰하고 또 실험 결과를 분석하는 게 좋겠다. 분석을 돕는 좋은 시각자료 (visualizer)를 만들고 싶다는 소망은 더 커져 간다.

#Essay