평가
현존하는 수많은 static analysis 도구들을 일관된 기준에서 평가하기 위해 힘쓴 논문이다. 가장 뛰어나다고 평가받는 도구 3개를, 같은 configuration 내에서 비교하여 정확성(등)을 측정하였다. 총 3개의 질문을 서두에 던진 후에(Introduction) 이에 대한 답을 찾는 과정으로, 배경 지식을 자세하게 설명하고(Background), 실험 환경을 설명한 후에(Study Design), 실험하여 결과를 도출한다. 글의 구성이 좋았다.
또한 직접 개발하지 않은 각자의 도구를 이용하고, 서로 다른 벤치마크 애플리케이션들을 이용하다보니, 엄청나게 다양한 시행착오와 불가능한 점이 있었던 것으로 보인다. 이 부분을 합리적인 이유와 함께 기술해주어 오히려 좋았다. 예를 들어, 어떤 도구의 ~~ 부분은 hard-coded 되어있어 이를 수정하기에 상당한 노력이 들었기 때문에 배제한다든지. 어떤 도구의 ~~는 ~~한 환경에서는 사용하지 않는다고 개발자가 명시하였기 때문에 ~~에서는 배제한다든지.
한편 내가 읽기에는 2. Background에서의 정리가 static analysis 도구들이 어떤 challenge를 극복해야 하는지 자세히 명시되어 있어서 참 좋았다. 특히 어떤 블로그나 논문보다도 잘 정리되어 있어 다시 찾아볼 것 같다. 이 부분에 관심이 더 있었던지라 뒷 부분의 구체적인 실험에는 흥미가 가지 않았다. 챕터 3을 넘기지 못하고 읽기를 포기하였다.
0. Abstract
수많은 static taint analysis 테크닉이 제안되었다. 이것들은 인조적인 benchmark에 의해 평가되는데, 이것이 일반화에 어려움을 준다. 그런 테크닉들이 서로 다른 설정 환경에서 비교되어 비교를 부정확하게 한다. 이 연구에서는 대규모의, 통제된, 독립적인 비교를 3개의 가장 뛰어나다고 평가받는 static analysis 도구(FlowDroid, Amandroid, DroidSafe)에 대해 진행한다. 우리는 설정 환경을 가지런히 하고, 일반적인 benchmark를 통해 구글 플레이 앱 스토어 내부의 실제 애플리케이션에 대해 진행한다. 우리는 더 나아가서 DroidRA에서 제시한 additional reflection handling mechanism의 효과성에 대해서도 평가한다. 우리는 이 결과를 이전 연구들과 비교하여, 기존 도구에서의 부정확성을 확인하고 다음 연구를 위한 제안을 하였다.
1. Introduction
static taint analysis 도구들은 벤치마크로 평가하는데, 이 도구들이 서로 다른 환경에서 비교되는 경우가 있어, 연구를 부정확하게 한다. 이 도구들은 또한 인조적인 벤치마크들에서 비교되기도 하는데, 실제 앱에 대한 퍼포먼스를 측정하는 것을 어렵게 한다.
여러 연구들이 도구들을 비교했지만, 도구들의 세팅을 나란히하지 않았다. 또한 대부분이 detected flows, runtime failures에 집중하였지만, expected flows를 고려하지 않아, false negatives들과 reporting reason들을 분석하는 것이 false positive와 false negative를 만들었다.
우리는 이러한 한계들을 연구에 도입하여, 독립적이고, 통제되고, 대규모의 연구를, 가장 인기있는 오픈소스 static taint analysis 도구를 비교하여 진행하였다, FlowDroid, Amandroid, DroidSafe. 정확성, 실행 시간, 메모리 사용에 집중하여 도구의 성능을 비교하는 데에 초점을 맞추었다. 유사한 설정에서 도구를 사용하도록 설정하였고, 180개 이상의 벤치마크 애플리케이션과 25개의 구글 플레이 스토어 애플리케이션(특별히 expected flows에 신경씀)을 통해 평가하였다. 또한 각각의 도구를 reflective call에 대한 처리를 더 잘 지원하도록 solution을 만들었다, DroidRA. 그리고 그것의 효율성을 측정하였다.
우리는 우리 결과를 기존 연구와 비교하고, 각각의 도구의 장단점을 논의하고, 우리 연구의 의의에 대해 평가하였다. 우리 팀이 해당 도구들의 개발에 개입하지 않았기 때문에 우리의 분석은 완전히 독립적이다. 도한 우리는 분석의 결과, 사용했던 대상 애플리케이션, 우리의 설정 환경 등을 커뮤니티에 공개하여, 재생산 가능한 연구를 하고자 하였다.
우리의 연구는 다음 질문에 초점을 맞췄다
RQ1. 도구들이 벤치마크 애플리케이션에서 얼마나 잘 동작하는지?
RQ2. 벤치마크 애플리케이션의 부정확성의 가장 큰 원인이 뭔지?
RQ3. 벤치마크 애플리케이션의 결과들을 Google Play 애플리케이션에 일반화할 수 있는지?
RQ1.에 답하기 위해 FlowDroid, Amandroid, DroidSafe 각각의 실제 평가에 사용된 설정 옵션들을 추출했다. 리포트들에는 구체적인 정보들이 나와있지 않았다. 우리가 선택한 공통 설정 환경에서 평가하였고, 같은 애플리케이션 세트와 같은 source, sink를 이용하였다.
DroidBench와 ICC-Bench를 이용했다. DroidSafe가 가장 높은 정확성을 보였고, FlowDroid가 그 다음, Amandroid가 가장 낮은 정확성을 보였다. DroidRA, FlowDroid의 구버전을 통해 개발되고 평가된 것,은 reflection과 관련된 새로운 버전의 FlowDroid로부터 어떤 도움도 받지 않앗다. 흥미롭게도 이것이 Amandroid와 DroidSafe의 정확성을, 비록 조금일지라도 증가시키는 결과를 가져왔다.
우리의 실험에서 도구들의 정확성은 기존 연구들에서 보고된 것과는 보통 달랐다. Amandroid의 저자는 DroidBench에서의 F-measure이 81%, 96%가 된다고 보고하였으나, 실제로는 61%였다.
RQ2.에 답하기 위해 False positive와 False negative 결과들을 수작업으로 분석하였다. 간략하게 말해서, 모든 도구들이 reflection을 처리하는 데에 대부분의 문제들이 있었다. DroidRA는 이러한 이슈들 중 일부를 해결하는 데에 도움을 주지만, 복잡한 reflection-related construct에는 실패하였다. FlowDroid는 복잡한 문자열 분석과 리스트 매니지먼트 연산들이 있는 ICC Intent들을 정확하게 parse하고 추적하지 못하였다. Amandroid는 Android 프레임워크 함수, lifecycle과 callback함수들, location-related flow들을 정확하게 처리하지 못하였다.
RQ3.에 답하기 위해서, FlowDroid와 Amandroid가 실제 애플리케이션에서 flow를 알아챌 수 있는지 조사하였다. 1) 유저의 의해 입력된 로그인 크리덴셜이 인터넷 통신되는 경우 2) 유저의 혹은 휴대폰의 민감한 정보가 인터넷 통신되는 경우. DroidRA를 적용하는 연구도 수행하였다. DroidSafe는 제외하였는데, 저자가 명시적으로 Google Play 앱들에 적용되도록 디자인되지 않았다고 명시했기 때문이다.
로그인 케이스를 선택한 이유는 애플리케이션들이 로그인 기능을 지원하기 위해서는 유저의 비밀정보를 전송해야 하기 때문이다. 민감한 정보 케이스는, 개인정보를 그들의 서버로 전송한다고 알려진 spyware 애플리케이션을 선택하였다. 우리는 이러한 정보 전송을 expected flow로 보고, 도구들이 이 flow를 얼마나 잘 파악하는지 확인하였다. 우리는 수작업으로 각각의 애플리케이션에서 발견한 모든 flow에 대해 분석하였고, FP 결과를 파악하고, FP와 FN 결과 뒤에 숨어있는 이유들을 분석하였다.
우리는 두 도구가 모두 3일동안 동작하도록 설정하였고, 256G의 메모리를 각각의 실행마다 할당하였다. FlowDroid가 25개 중 11개의 애플리케이션에서 crash가 발생하였는데, ICC flow와 reflective calls를 분석하는 과정에서 발생하였다. Amandroid는 14개의 애플리케이션을 분석할 수 있었으나, 실행할 때마다 서로 다른 개수의 flow를 결과로 도출하였다. 따라서 Amandroid의 FP, FN 결과는 신뢰할만한 분석을 수행할 수 없었다.
FlowDroid가 성공적으로 분석한 14개의 애플리케이션에서는, 오직 2개의 애플리케이션에서만 expected flows를 발견하였고, callback 함수와 reflective calls를 탐지하는 데에 어려움을 겪는 것으로 보인다. 그 이유는 Google Play 앱들은 benchmark에서 파악되지 않는 callback/reflection에 의존하기 때문이다. DroidRA는 reflective call에서는 도구의 정확성을 향상시켜주지 않앗다. 또한 FlowDroid의 안드로이드 프레임워크 메소드의 모델링이 벤치마크에 사용되는 함수들에 대해서는 정확하였으나, Google Play에 사용되는 함수들을 커버하지 못하여, FP, FN 결과들을 만들게 되었다.
마지막으로, 벤치마크 앱에서의 성공에도 불구하고, 도구가 실제 애플리케이션에서 믿을만하게 분석하는 데에 이용될 수 없다는 점을 지적한다. 우리가 관찰했던 실패들이 현재 존재하는 벤치마크들에서는 명시적으로 커버되지 않았기 때문에, 우리는 각각의 실패를 격리하는 앱을 만들고 우리의 benchmark, UBCBench에 추가하였다. 우리는 이것을 DroidBench에 이것을 contribute하고, FlowDroid와 Amandroid의 저자들과도 실패들을 고치기 위해 작업하고 있다.
Contributions
ISSTA'18에 제출했던 논문의 확장 버전이다. 각자 도구의 새로운 버전을 가지고 새롭게 만들었다. Google Play 앱들을 가지고 새롭게 실험도 하여, 실제 사용 경우와 도구들을 비교하였다.
- 현존하는 static taint analysis 도구들을 비교하는 심층적, 독립적 분석을 제공하였다, bennchmark와 Google Play 애플리케이션 각각에 대해서.
- 각 도구의 주요한 장점과 단점을 파악하였다.
- 선택한 설정 환경, source and sink, applications에 대해 자세한 정보를 제공하여 결과가 보다 재사용하기 쉽도록 하였다.
- 벤치마크 도구들을 이전에 커버되지 않은 케이스들까지 확장하였다.
- 25개의 Google Play 앱들을 수작업으로 확립한 expected flow와 함께 분석하였다.
- 실험 환경과 결과를 공개적으로 사용가능하게 하여, 재사용이 용이하도록 하였다.
2. Background: Taint Analysis
static taint analysis에 대한 기본적 개념을 소개함. 민감한 source부터 민감한 sinks들의 집합인 민감한 정보의 흐름을 추적하는 것. source는 우리가 모바일 기기에서 보호하고 싶은 정보들이다(폰 번호, 연락처, 위치, unique device identifier). sink는 원하지 않는 정보 공개가 되는 지점을 의미한다(Internet이나 SMS와 관련된 함수들). 민감한 source로부터 sink로 데이터가 도달하면, taint tracking이 source부터 sink까지의 경로를 data leakage의 하나의 경우로써 파악한다.
taint analysis는 정적으로, 동적으로 수행될 수 있는데, 이 논문은 정적에 집중함. 이러한 도구들은 FlowDroid, Amandroid, DroidSafe 등이 있음. 이 도구들은 결정을 내리는 디자인의 측면에서 다른데, 간략하게 그러한 결정들의 관점에 대해서 언급하려 한다.
Sensitivites
aliasing과 virtual dispatch 구조를 처리하기 위해서, 통상의 도구들은 context, object, field에 대해서 sensitivity를 적용한다. flow and path sensitivity는 각 명령어들의 순서와 그들의 일관성을 통제하기 위해 이용된다.
context-sensitive 분석은 함수 호출의 대상을 분석할 때에 calling-context를 고려한다. k-call-site-sensitive analysis에서는, 함수 호출의 context가 현재 호출 위치를 포함하고, 호출자 메소드의 위치를 미리 정의된 깊이인 k까지 포함한다. Figure 1에서 foo()와 bar() 내부에서 사용된 sink()를 이해하려면 context-sensitive한 분석이 필요.
object-sensitive 분석은 Context와 같은 object 추상화, 할당 위치에 쓰인다. 특히, 메소드의 로컬 변수들에게 함수 호출의 receiver object의 할당 위치에서의 자격을 준다.(??) Figure 1에서 object-sensitive 분석은 a1과 a2의 sink() 함수의 호출을 차별화하기 위해 서로 다른 힙 주소를 사용한다. 즉, context- and object-sensitive 분석은 서로 다른 프로그램 요소를 이용한다. 호출 위치 vs 할당 위치, 맥락적 정보를 차별화하기 위해서.
field-sensitive 분석은 같은 추상 오브젝트에 대해서, 서로 다른 필드를 구별한다. flow-sensitive 분석은 명령어의 순서를 고려하는 것이다. x=1; y=x+1; x=2에서 y=2라고 확실히 말할 수 있는 것이다.
path-sensitive 분석은 path의 실현가능성을 나타내기 위해 path 정보를 수집하는 것이다. x > 0이라는 분기문이 있을 때에, 분석은 x > 0이라고 추측할 것이다. 만약 fall-through 경로라면 x <= 0이라고 추측할 것이다.
Implicit flows
Implicit flow란 민감한 데이터가 control flow에서 어떤 branch를 탈지에 대해 간접적으로 결과에 영향을 주는 것이다. 예를 들면 if taint then output = 1 else output = 0에서 taint가 어떤 branch를 탈 것인지에 영향을 주고, 그것이 output 변수의 값에 영향을 준다. 이론적으로, implicit flow tracker는 의존적인 모든 데이터를 추적하여, 많은 개수의 false positives를 만든다.
Java-specific features
보통 안드로이드 앱이 자바 언어로 작성되는데, reflection이나 exception과 같은 자바만의 특징들을 처리할 수 있어야 함. reflection이란, 오브젝트의 멤버와 타입 정보에 동적으로 접근할 수 있는 능력을 의미한다, 보통 멤버나 타입의 이름의 문자적 표시에 기반하여. 안드로이드 개발자들은 reflection에 많이 의존하는데, 뒤로가기 기능, 일반화, 민감한 정보 흐름을 숨기기 위하여. reflective 호출을 정확하게 해석하는 것은 정적 분석의 올바름에 문제가 된다. 문제를 해결하기 위해 어떤 도구는, 모든 가능한 해결방법들을 고려하기도 한다. 다른 도구는 변수에 타입이나 범위에 따라 해결방법들을 제한하기도 한다.
Exception은 명령어나 표현에 의해 throw되고, 메소드나 call stack 내부의 catch 코드에 의해 읽힌다. exception이 동적으로 로딩되고, exception의 타입이 어떤 코드블럭이 실행될지를 정하기 때문에, 정확한 처리는 어렵다. Spark나 Paddle과 같은 프레임워크는 exception을 처리하기 위해 over-approximation한 접근을 사용하여, 모든 exception을 하나의 글로벌 변수에 할당하면서. 변수는 exception이 catch되는 지점에서 읽히게 된다.(????). 즉, 이 접근법은 가능한 모든 예외가 실행되었다고 가정하고, 어떤 예외가 catch 지점에서 더 생겨날 수 있는지에 대한 정보는 무시한다. Soot와 같은 다른 프레임워크는 실현될 수 없는 exception을 intraprocedural CFG에서 제외한다.
Android-specific features.
Android modeling: 안드로이드 실행 환경과 애플리케이션이 상호작용하는 것을 추적할 때에, 보통 2개 중 하나를 따른다. 1) 파라미터 중 하나라도 tainted 되었다면, 보수적으로 Android framework method의 리턴 값이 tainted 되었다고 가정하는 것. 2) framework method를 정확하게 모델링하는 것. 후자는 수작업이나, 자동화된 Android binary distribution libraries를 통해 동작한다.
Application lifecycle: 안드로이드 애플리케이션은 4가지 타입의 Component로 구성된다, Activity, Service, Broadcast Receiver, Contetn Provider. 각각의 컴포넌트는 각자의 lifecycle method를 가지고, 안드로이드 시스템이 이 메소드를 통해 컴포넌트를 시작/중지/재시작할 때에 사용한다. Application들은 시스템과 유저의 이벤트(위치 변경 or 버튼 클릭)에 대응하여 유발되는 callback method라는 것을 가진다. 정적 분석 도구는 taint의 정확한 확장을 보장하기 위해서 lifecycle과 callback method를 이해해야 한다. 이러한 메소드를 추출하기 위해서는, 도구가 Android Open Source Project에 의존해야 하고, application code와, configuration 파일(manifest, XML 등)을 분석해야 한다.
Android에서 4개의 Component
Activity 생명주기
Inter-component communication (ICC): 안드로이드의 멀티-컴포넌트 모델은 서로 다른 컴포넌트가 explicit or implicit Intent를 이용해서 서로와 통신하고 정보를 주고 받기를 허락한다. 전자는 호출될 target 컴포넌트를 명시적으로 정의하는 반면, 후자는 Android에게 요청한 기능을 수행할 컴포넌트를 찾아줄 것을 의존한다. ICC 핸들링은 호출된 컴포넌트를 정적으로 매칭하기 어렵다. Epicc나 IC3와 같은 도구들은 ICC 정보들을 추출하여, ICC 정보를 초함한 flow analysis를 가능하게 한다. PRIMO는 이러한 정적 분석 결과 상단에 ICC에 대한 예측적 모델을 덮어씌워, ICC 탐색에 대한 정확성을 더했다.
Inter-app communication (IAC): ICC와 동일하게, IAC는 얼마나 민감한 데이터가 서로 다른 애플리케이션의 컴포넌트 간에 주고받아지는지를 살펴본다. ApkCombiner과 같은 도구는 서로 다른 애플리케이션을 하나의 애플리케이션으로 결합함으로써 IAC 문제를 ICC 문제로 축소한다.
Native code: 안드로이드 애플리케이션은 C and C++로 쓰여진 코드를 포함하고, JNI를 통해 실행할 수 있다. taint가 이러한 네이티브 코드를 통해서도 확장될 수 있기 때문에, 분석 도구는 네이티브 코드도 추적할 수 있어야 한다. Amandroid는 JN-SAF라는 inter-language 프레임워크를 이용하여 추적을 지원한다, 그 프레임워크는 Java와 네이티브 코드에서 발견된 data flow를 "스위칭"한다.
3. Study Design
static taint analysis에 대한 도구를 선정하고, 환경 설정하는 과정. 벤치마크를 통해 평가하는 과정 등
3.1. Tool Selection
이전 연구에서 38개의 Android application에 대한 static taint analysis 도구들을 분석하였다. 이 리스트에서, 우리의 이전 연구에서는, 모든 오픈소스 도구들을 선정하였다(2017년 6월). 논문을 2020년 1월으로 업데이트하면서, 도구의 최신 버전을 이용하였다. FlowDroid는 StubDroid와 합쳐졌다.
2020년 12월 기준으로 공개된 도구들을 스캔함. 총 181개 논문을 확인하였고, 17개의 서베이 논문을 배제, 78개의 dynamic & hybrid 도구들을 배제 하였다. 41개의 논문에서는 존재하는 taint analysis 도구를 이용할 뿐, 새로운 접근을 하지 않았다.
41개의 남은 논문 중에서, 15개는 IAC를 위해 제작되었고, 2개는 JavaScript, 5개는 native code, 1개는 implicit flow analysis를 위해 제작되었기 때문에, 우리의 연구 주제에서 벗어났다. 18개의 관련된 논문이 남았고, 저자들에게 직접 연락하여 도구의 사용 가능 여부와 소스코드를 물어보았다. 4개의 도구를 식별했는데, HornDroid, Ripple, DAPA는 더이상 유지되지 않고 있으며, 우리가 선택한 애플리케이션에 적용하기 위해서 상당한 구현 노력 없이는 불가능하였다. 따라서 우리는 DroidRA만을 우리의 연구에 포함하였다.
우리 연구에서 사용된 도구들은 FlowDroid, IccTA, Amandroid, DroidSafe, DroidRA 이다. FlowDroid는 IccTA와 통합하여 ICC 흐름 처리를 이용하고 있다. 따라서 통합된 버전으로 FlowDroid를 이용하였다.
이후에 각 도구에 대한 설명.(FlowDroid, Amandroid, DroidSafe).
DroidRA는 발전된 reflection 처리 메커니즘을 제공하여 가장 최고의 static analysis 도구를 발전시켰다. 메인 아이디어는 constraints를 생성하여 추후에 constraints solver에 넘겨주어 reflective calls의 타겟을 정하게 함으로써 inter-procedual, context-sensitive, flow-sensitive한 분석을 하는 것이다. 도구는 input application을 활용하여, 도구가 직접적인 Java 호출로 해석할 수 있는 숫자를 늘린다.(??) 우리는 DroidRA를 포함하여, 그리고 포함하지 않고 분석을 수행하였다. DroidRA로 처리한 애플리케이션들을 각각의 분석 도구에 반영하고, 원래의 버전과 그 결과를 비교하였다.
3.2. Tool configuration Parameters
각 분석도구는 매우 많은 환경 설정 변수들을 제공한다. 서로 다른 환경에서 비교하는 것은 의미가 없다. ~~ 조사했는데, 대부분의 연구들에서 환경 설정 변수로 어떤 것을 선택하였는지 기술하지 않았다. 어떤 도구들은 중요한 결정사항들이 hard-coded 되어 있거나, 전혀 설정할 수 없는 경우들을 발견하였다, FlowDroid의 object-sensitivity와 DroidSafe, Amandroid의 field sensitivity의 몇몇 설정들.
같은 파라미터에서 비교하기 위해, 각 도구에서 적용한 디자인 선택사항을 식별하기 위해 테스트를 생성, 실행하였고, 서로 다른 도구를 같은 디자인 선택사항을 적용하기 위해 정렬하였다. 최종 설정은 아래에 명시됨.
Sensitivities, Implicit flows, Java-specific, Android-specific
(서론에서 왜 이렇게 자세히 설명해주나 했더니, 이걸 위한 빌드업이었구나,,, 소름)
각 도구별로 특징을 정리하였음.
3.3 Evaluation Methodology for Benchmark Apps
DroidBench와 ICC-Bench를 사용하였다. 여기로부터 총 182개의 애플리케이션을 테스트셋으로 만들었다.
sources and sinks. 182개의 벤치마크 앱의 headers와 comments를 조사하였다. SS-Bench라고 부름.
expected result. 각각의 벤치마크 애플리케이션을 수작업으로 분석하여 예상할 수 있는 모든 플로우를 추출하였다. 검증을 위해 독립적으로, 2명의 저자를 통해 병렬적으로 수행되었고, 불일치 확률은 4%였다 -> 만나서 해결함.
도구에 의해 분석된 flows를 expected flows와 수작업으로 조사하여 비교하였다. 분석의 목적은 True positive, False positive, False positive, False negative를 식별하는 것이다. 마찬가지로 불일치 확률 3%는 만나서 해결하였다.
(이후 구체적인 확률, 실험 결과 등.. 구체적인 결과가 궁금하지는 않아서 생략.)
