afl-fuzz for javascript

Naver Labs 인턴 기간동안, afl-fuzz 의 javascript engine 최적화 버전을 만들어보았다.

https://github.com/tunz/afl-fuzz-js

우선 afl-fuzz에 대해서 간략하게 얘기하자면, 다른 일반적인 fuzzer 들과 마찬가지로 브루트포싱 기반이다.

다만 다른게 있다면, flow coverage 를 maximizing 하려고 한다.

무슨 말이냐면, 컴파일 하는 과정에 개입해서, jmp, call 등의 program의 path가 갈라지는 부분에 logging을 하는 어셈을 삽입한다.

그리고 fuzzer가 프로그램을 실행하면서, path 를 얼마나 커버했는지를 확인한다.

그리고, 브루트포싱으로 인풋을 넣다가, 새로운 path 를 찾으면 (한번도 로깅하지 못했던 곳이 실행되면) 그 인풋의 우선순위를 높인다.

예를 들어, 실행 포맷이 안맞아서 에러만 계속 내다가

어느 순간 포맷이 맞는 인풋이 들어가게되면, 갑자기 그동안 실행되지 않았던 부분들이 실행될것이다.

그러면 이제 afl-fuzz는 그 포맷이 맞는 인풋을 위주로 변형을 하게 된다.

정말 간단한 아이디어인데, 효과가 상당히 좋다.

이전에 post-shellshock 취약점이 afl-fuzz 로 찾아졌다는 말을 듣고 그때부터 주의깊게 보고 있었는데,

그 후로도 Google project zero에서도 사용하는게 보였고,

그 외에 보안 관련뿐 아니라 LLVM, sqlite 등 여러 오픈소스에서에서 단순한 크래시도 많이 내면서 많은 오픈소스 프로젝트에서 채용하고 있는듯 하다.

근데 이게, 애초에 자바스크립트만을 위해 만들어진것이 아니고, general 한.. 모든 프로그램에 사용될수 있도록 만들어졌다.

그래서 사실 grammar 가 있는 자바스크립트의 경우는 그렇게 효과적이지는 않다.

그리고 grammar가 있는 경우, security 관련 크래시보다는 parsing 을 하는 과정에서 많이 죽는다.

여튼 afl-fuzz는 이렇고, 내가 인턴기간동안 한것은 자바스크립트만을 위한 afl-fuzz를 만드는 것이었다.

쓸데 없는 부분은 다 없애고, 자바스크립트만에서 효과가 있을만한 것들을 생각해보았다.

크게보면 3가지를 했다.

첫번째는 comment를 이용해서 사전(token)을 추출해냈다.

afl-fuzz는 아무래도 브루트포싱 방식이다보니, 시드의 영향을 많이 받는다.

아무것도 없이 시작할경우도 되기야 하겠지만, 브루트포싱을 하면서 path 가 크게 바뀔때까지 기다려야하니 시간이 오래걸린다.

그와 마찬가지로 사전이 있는것도 중요하다.

if else function new 등의 키워드는 미리 입력해두면 많은 시간을 절약해준다

추가로, fuzzer 를 돌리면서, 자동으로 사전을 만들기도 한다.

원래 인풋을 한글자씩 변경하면서 flow 가 바뀌는걸 관찰하면, 해당 글자가 뭔가 의미있는 부분이라는걸 알 수 있고, 저장해서 사전으로 활용할 수 있다.

여기까지는 원래 있던 기능이고, 원래 방식은 bit를 하나씩 뒤집으면서 flow의 변화를 측정했다.

나는 JS에만 맞추면 되기때문에, 원래 방식에 추가로, 앞뒤로 코멘트를 덧붙여서, flow의 변화를 봤다.

(예제는 github README 참고..)

효과는 뭐 꽤 좋았는데.. 아무래도 시간이 지나면 지날수록 이상한 토큰으로 쌓이는건 어쩔수 없었다.

두번째는 threshold를 이용해서 작은 flow들을 무시했다.

js가 아무래도 grammar가 있는 프로그램이다보니.. 같은 에러라도 flow가 다를 수 있다.

'a' 만 넣어서 undefined가 뜨는거랑 'ab'를 넣어서 undefined가 뜨는게 flow가 다르다던가..

그에반해 error와 error가 없는경우의 flow차이를 비교하니, 그 값이 컸고

flow차이가 내가 지정한 threshold 이상인 경우만 comment로 auto dictionary를 뽑아내도록 했다.

threshold도 자동으로 잡아주면 괜찮지 않을까 싶기도 했는데.. 그냥 패스했다.

시간대비 효과가 확실하지가 않은것 같아서

세번째는 fork server를 개선했다.

afl-fuzz에서는 상당히 흥미로운 방법으로 fuzzing속도를 빠르게 하고 있었다. (link)

그냥 단순히, 퍼징할때마다 새로 실행하는게 아니고,

맨처음 컴파일하는 과정에서 어셈을 껴넣을때, fork server에 관련된 어셈도 껴넣는데.

afl-fuzz가 프로그램을 맨처음에 실행했을 경우에는, fuzzing 당하는 프로그램에서 fork server를 하나 만든다.

그리고 fuzzer와 그 fork server 가 통신을 하면서, fork server 에서 계속 fork로 child를 만들고, 그 child에서 fuzzing을 한다.

그러면, 프로그램 로딩시간이 없어지기때문에, 약 2배정도의 속도개선이 있었다고 한다.

여기에 추가로, fork server를 프로그램 맨 처음 부분이 아니고, 적당히 뒷부분에 넣으면

인풋과 관련없는 쓸데없는 부분을 퍼징과정에서 제외함으로써, 많은 시간을 절약할수 있지 않을까 라고 말하는 글을 보았다.

나는 js에만 최적화한 fuzzer 를 만드는거니까, 소스코드를 변형해서라도 좀 가능하지 않을까 싶어서 바로 진행했다.

내가 생각한 방법은, 프로그램에서 내 입력을 open이나 read를 하기 전까지 쭉 진행하고, 그 직전에 fork server 를 만드는 것이다.

ptrace로 쭉 tracing 하다가, read 난 open syscall을 관찰하고, 내 입력을 읽으면 그 위치를 기억해둔다.

그리고 프로그램을 재실행하여, 그 직전 부분에서 fork server를 만들었다.

Webkit의 JavaScriptCore에서는 상당히 효과가 좋았다. 속도가 2~3배 증가하고, 아무런 문제도 없었다.

근데 v8에서는 잘 되지 않았다. 이유는 정확히는 모르지만, v8의 isolate 관련이나, 쓰레드관련으로 보인다.

직접 세팅해서, 어디까지 fork server가 가능한지 봤는데 프로그램 거의 첫부분에만 세팅이 가능해서, 내 구현은 거의 효과가 없었다.

(애초에 v8 같은 경우는, fork server 위치 재지정으로 속도개선이 불가능한듯)

뭐 이렇듯, general 하게 구현하기 위해서는, 생각해야할게 너무 많다.

그치만, 무거운 프로그램일수록 효과가 상당히 좋은만큼 계속 파볼만한 주제이긴 한 것 같다.

여튼 이렇게 구현후 퍼징을 돌렸고, 짧은시간동안 6개? 정도의 v8, JSC의 크래시를 찾았고, 전부 exploit은 불가능한 크래시였다.

난생 처음으로 직접 패치도 올려 보았다.

요즘은 보안보다는 소프트웨어 테스팅쪽으로 관심범위를 넓히고 있어서, 이정도도 만족스러웠다.

시드 교체후 한번만 더 돌려보고, 이제 afl은 여기까지만 해야겠다.

해보면서, fuzzing이나 testing에 관한 여러가지 아이디어들을 알아볼 수 있어서 좋았다.