RVFUZZER: Finding Input Validation Bugs in Robotic Vehicles ThroughControl-Guided Testing 논문 리딩

#개인 학습용입니다. 

 

Abstract

Robotic vehicles (RVs) are being adopted in a variety of application domains. Despite their increasing deployment, many security issues with RVs have emerged, limiting their wider deployment. In this paper, we address a new type of vulnerability in RV control programs, called input validation bugs, which involve missing or incorrect validation checks on control parameter inputs. Such bugs can be exploited to cause physical disruptions to RVs which mady result in mission failures and vehicle damages or crashes. Furthermore attacks exploiting such bugs have a very small footprint: just one innocent-looking ground control command, requiring no code injection, control flow hijacking or sensor spoofing. To prevent such attacks, we propose RVFUZZER, a vetting system for finding input validation bugs in RV control programs  through control guided input mutation. The key insight behind RVFUZZER is that the RV control model, which is the generic theoretical model for a broad range of RVs, provides helpful semantic guidance to improve bug-discovery accuracy and efficiency.Specifically, RVFUZZER involves a control instability detector that detects control program misbehavior, by observing (simulated) physical operations of the RV based on the control model. In addition, RVFUZZER steers the input generation for finding input validation bugs more efficiently, by leveraging results from the control instability detector as feedback. In our evaluation of RVFUZZER on two popular RV control programs, a total of 89 input validation bugs are found, with 87 of them being zero-day bugs.

#밑줄 친 부분 중 feed 백을 다시 input으로 사용한다는 말과 model 이 있다는 말이 state기반의 model-checking을 사용한 것 같다는 추측이 든다.

로봇운송체들은 많은 분야에서 다양하게 적용되고 있으나, 증가하는 보안 문제들로 인해서 배포의 영역을 제한하고 있다. 이 논문에서는 RV 제어 프로그램의 새로운 유형의 취약점을 찾기 위해서 매개변수를 빼먹거나, 올바르지 않은 입력값을 사용해서 의도적, 비의도적 권한상승 및 침투가 가능한지 확인한다. 이런 버그들은 로봇운송체들의 물리적인 중단을 야기하며 이는 운송체의 손상이나 충돌 또는 미션의 실패로 이어진다. 게다가 이런한 버그를 이용한 공격은 풋프린트가 매우 작아서 찾기 어렵다.  공격은 코드 주입, 제어 흐름 하이재킹 또는 센서 스푸핑이 필요 없이 단순히 지상 제어 명령의 입력만으로 수행된다. 우리는 이러한 공격을 방지하기 위해 RVFUZZER를 제안한다. 이 Tool은  RV 제어 프로그램에 돌연변이 입력 값을 통해서 이를 입력 검증을 하기 위한 베팅 시스템이다. RVFUZZER 연구는 광범위한 RV에 대한 특정 모델이 아닌 일반적인 이론적 모델에 대해서 RV 제어 모델을 대상으로 한 버그 발견의 정확도와 효율성을 높이는데 semantic 차원에서 지침을 제공해준다는 것이다. 구체적으로, RVFUZZER는 제어 모델로 시뮬레이션 되는 물리 동작을 통해 제어 프로그램의 불안정성을 탐지하는 검출기를 포함한다.  또한 RVFUZZER는 제어 불안정성 검출기의 결과를 피드백으로 활용하여 입력 검증 버그를보다 효율적으로 찾기 위해 입력 생성을 조정한다. RV Fuzeer를 널리 사용되는 두 가지 RV 제어 프로그램에 대해 적용하여 평가했을 때, 총 89 개의 유효한 입력 버그가가발견되었으며 그 중 87 개는 제로 데이 버그였다.

Background

RV Control Mode

l은 미션 중 RV의 움직임과 작동을 제어하는 일반적인 이론의 토대가 되는 모델이다.

RV의 움직임은 아래와 같이 x,y,z 축의 각회전을 포함한 x,y,z,롤링, 피칭, 요잉에 따라 이뤄진다. 

RV의 제어 모델은 여러개의 구성요소로 되어있다. 6DoF,6자유도를 특정한 정도로 조정하기 위해서이다.

x축 통제 컨트롤러는 다음 그림과 같다. 

x축 컨트롤러 내부에는 캐스케이드에 3개의 기본 컨트롤러가 있으며 각각은 x 축에 따른 차량의 위치, 속도 및 가속도를 각각 컨트롤 한다. 그리고 기본 컨트롤러는 두개의 상태를 입력으로 받는다. 기준상태와, 센서에 의해서 보고 및 관찰된 상태를 말한다. 컨트롤러의 목적은 기준생태에 근접하게 관찰 상태를 유지하는 것이다. 이러한 핵심 기능을 control state stabilization.이라고 한다.  최종 컨트롤러에서는 각가의 컨트롤러에게 이상적인 상태를 다운 스트림 시킨다. 그리고 각가의 컨트롤러는파라미터 지시를 받는다. 

RV 통제모델은 각 축에 대한 복합적인 독립성을 가진다. 게다가 각각의 컨트롤러, 센서들 그리고 RV의 움직임은 피드백 루프를 형성 하여서, 컨트롤러들이 주기적으로 상호작용 할 수 있도록 해준다. 

[참고]

Cascade 다단제어기

https://pyomark.tistory.com/289

22. 다단 제어

RV Control Program

컨트롤 프로그램은 컨트롤 모델을 구현한다. 이 프로그램은 다음의 메인 모듈들을 가지고 있다. 

1) 센서들의 입력을 수집하는 모듈, 2) 현재 미션에 따라서 참조 상태와, 센서 값 등의 통제 명령출력을 보내는 모듈

3) 미션 모듈, 지시를 주거나 실행시키고, 또 중간에 인터럽트 시키는 모듈

이러한 모듈들은 주기적 에포크에서 반복적으로 실행된다. 

비행동안 RV는 GCS와 통신한다, GCS는 제어프로그램에 GCS 신호를 준다. 이러한 명령들은 RV의 동적으로 조정하고, 컨트롤러와 미션 파라미터를 조정한다.

우리는 dynamic parameter 의 변화는 RV의 제어 퍼포먼스를 향상시키는 것을 주목하였고, 또한 외적 요인에 대한 반응성을 높여준다. 

제어하고 통신와 통신 기능을 위해 대부분의 RV 들은  런타임 로깅 함수를 가지고 있다. 트러블 슈팅 목적이다. 

RVFUZZER는 컨트롤러 오작동을 자동으로 결정하는데 사용되는 로그를 활용한다. 

Control Prameters

RV 컨트롤 모델과, 프로그램의 복잡성과 일반성으로 인해 컨트롤 프로그램은 많은 파라미터들로 구성되어 있다. 

파라미터 대부분은 런타임 동안 GCS의 명령 인터페이스를 통해 매우 동적으로 조정된다. 아듀 파일럿으 경우 247개의 제어 파라미터가 있다. x-y축 111개, z축 119개, roll 29, 30개 yaw, 29개 pitch 용 103개 모터 제어, 40개의 미션 명세용 이다. 우리는 247개의 파라미터중 몇몇의 파라미터는 다수 컨트롤러에서 공유됨을 주목했다.  파라미터 값들 중 하나를 조정해야 되는 GCS 명령을 받으면 제어프로그램은 입력값에 대한 validity 검사를 수행한다. 새로운 값이 안전한지 아닌지 범위가 맞는지 하지만 우리는 이부분을 못했다. 

-> 이부분 점검

Attack Model

Attack Model and Assumptions

입력 유효성 버그를 일으키는 공격의 유형은 다음과 같다. 1) 통제 파라미터에 범위를 벗어난 값이나, 옳지 않은 값을 넣는이다 : 공격자는 정항적으로 보이지만, RV의 GCS 명령을 변경 시키는 악의적인 파라미터 수정을 실제로는 악의적인 매개변수를 일으킨다.

 

 

 

 

RVFUZZER Design

In this section, we present the design of RVFUZZER. We first give an overview of RVFUZZER’s architecture and then present detailed design of two key components of RVFUZZER: (1) the control-guided instability detector that monitors the vehicle’s control state to detect controller malfunction and (2) the control-guided input mutator that generates control program inputs for efficient program testing.

이 섹션에서는 RVFUZZER의 설계에 대해 서술한다. 먼저 RVFUZZER의 아키텍처에 대한 개요를 제공 하고, 그 다음 (1) RV의 제어 상태를 모니터링하여 컨트롤러 오작동을 감지하는 제어 불안정성 검출기 그리고 (2) 제어 유도 입력 오류 검출을 위한 효율적인 프로그램 테스트를 위한 뮤테이션 생성기에 대해 말한다. 

Overview

RVFUZZER is designed to (1) detect physical instability of the RV during testing and (2) generate test inputs iteratively to achieve high testing efficiency and coverage. 

 

Fig. 3 presents an overview of RVFUZZER, which consists of four main components: a GCS program, the subject control program, a simulator, and a control-guided tester – the core component of RVFUZZER. The roles of the first three components are as follows: the GCS software is responsible for issuing RV control parameter-change commands; the subject control program, as the testing target, controls the operations of the (simulated) RV; and the simulator emulates the physical vehicle and its operating physical environment. We note that (1) the GCS and RV control programs are from real-world GCS and RV; and (2) our simulators [7, 8] are widely adopted for robotic vehicle design and testing.

RVFUZZER’s control-guided tester consists of two submodules(1) control instability detector and (2) controlguided input mutator.During testing, the control instability detector detects non-transient physical disturbances of the target RV (e.g., crash and deviation), as indication of control program execution anomaly caused by an input validation bug. The control-guided input mutator is a feedback-driven input mutator for efficient mutation of control parameter and environmental factor values. Using the results of the control instability detector as feedback, the mutator adaptively mutates control parameter values via a well-defined RV control interface (i.e., GCS commands created and issued by the GCS software). In addition, it mutates environmental factors (e.g., wind) by re-configuring the simulator.

RV Fuzzer는 앞서 언급했듰이 물리적인 불안정성에 대한 검출, 그리고 테스트 효율과 커버리지가 더 좋은 입력 검출을 생성하기위해 설계 되었다. Fig3는 RV Fuzzer의 개요이다. 이는 4개의 핵심 구성요소로 되어있다. 먼저 GCS program, 그리고 대상이되는 control program, 시뮬레이터, 그리고 ccontrol-guided tester이다. 이때, control-guided-tester가 핵심 엔진이다. 처음 세 가지 구성요소들의 역할은 다음과 같다. 먼저 GCS 소프트웨어는 RV의 제어프로그램이 가지는 파라미터의 변화 체인지와 명령들을 말한다. 그리고 subject control program은 타겟시스템으로 시뮬레이션 되는 RV를 조작한다.

그리고 시뮬레이터는 RV의 물리적 동작과 환경을 애뮬레이트 한다. GCS와 RV 제어프로그램과, 시뮬레이터(ardupilot 기반)이 RV 설계와 테스팅에 많이 적용되어 있다는 것을 강조한다. 

# 과연 아듀 시뮬레이터가 어느 정도 현실성 있는지 어떤 것을 전제로 physical operation을 시뮬레이션 하는지 고민해볼 필요가 있다. 

RV Fuzzer의 핵심엔진은 2개의 서브 모듈로 구성되어 있다. 먼저 불안정성 검출기와, 뮤테이션 생성기 이다. 테스팅 동안 검출기는 비 일시적인 물리적 교란을 감지했다.(충돌과 편차). 뮤테이터 생성기는 피드백을 통해 보다 효율적인 제어 매개 변수 및 환경 요인을 생성했다. 시뮬레이터는 바람과 같은 환경적인 요인도 factor로 포함한다. 

#이걸 실제 시스템을 대상으로 했을 때와 시뮬레이터를 대상으로 했을 때 어떤 차이를 보이는지를 함께 보일 수 는 없었는지? 해당 논문에서 구현까지 가지 못한 건 아닌지 궁금하다. 

Control Instability Detector

The goal of the control instability detector is to continuously monitor RV control state to determine if a specific GCS command has induced non-transient physical disturbance. Such a physical disturbance can be considered as an indication of an input validation bug. We note that input validation bugs may not lead to program crash, a common indicator of traditional bugs (e.g., memory corruption).We first define a rule to detect physical disturbances, which is tailored for input validation bugs. We then describe the mechanism to monitor the RVFUZZER’s 6DoF control states for detecting such a disturbance.

불안정성 검출기는 지속적으로 RV의 통제 상태를 모니터링 하는 것을 목표로 하는데 이를 통해 특정 GCS 명령이 비 일시적인 물리적인 이상 동작을 야기하는지를 판별하기 위함이다. 이러한 이상 동작은 입력값 버그라고 판달 할 수 있다. 우리는 입력값 버그는 프로그램 크래시가 아니다.(예,메모리 오염은 아니다.) 우리는 먼저 입력 유효성 검사 버그에 맞게 조정 된 물리적 장애를 감지하는 규칙을 정의했고 그 다음 이러한 장애를 감지하기 위해 RVFUZZER의 6DoF 제어 상태를 모니터링하는 메커니즘을 설명합니다.

Indication of Control State Deviation Exploitation of an input validation bug will cause an RV’s failure to stabilize its control states and/or complete its mission. To accurately detect bug-nduced physical disturbance, RVFUZZER must be equipped with the capability of control state deviation detection. Among the possible physical disturbances experienced by an RV, there are two types of control state deviation: (1) observed state deviation and (2) reference state deviation. Accordingly, we define a detection rule to determine if one of he two types of control state deviation has occurred. The first type – observed state deviation – is the case where a controller (e.g., the primitive x-axis velocity controller) fails to stabilize its observed state (x(t)) according to its reference state (r(t)). In the theoretical control model, a controller always tries to keep x(t) close to r(t) (Section 2). Consequently, if the difference between x(t) and r(t) keeps increasing and exceeds a certain threshold, the observed state will be considered deviating from the reference state. To quantify the observed state deviation, we leverage the integral absolute error (IAE) formula [47] which is widely used as a stability metric in control systems.

Given a time window w and starting from a certain time instance t, the formula quantifies the level of deviation(deviation(t)). If deviation(t) is larger than a pre-determined threshold t, our rule will determine that there is a control state deviation starting at t.We will describe how to experimentally determine w and t for each 6DoF control state in Appendix A.

제어 상태 편차의 표시 입력 검증 버그를 악용하면 RV가 제어 상태를 안정화하지 못하거나 미션을 완료하지 못합니다.RV가 경험할 수있는 물리적 장애 중에는 두 가지 유형의 제어 상태 편차가 있습니다. (1) 관찰 된 상태 편차와 (2) 기준 상태 편차. 따라서 두 가지 유형의 제어 상태 편차 중 하나가 발생했는지 여부를 판별하는 감지 규칙을 정의합니다.

첫 번째 유형 – 관찰 된 상태 편차 – 컨트롤러 (예 : 기본 x 축 속도 제어기)가 참조 상태 (r (t))에 따라 관찰 된 상태 (x (t))를 안정화하지 못하는 경우입니다. 이론적 제어 모델에서 컨트롤러는 항상 x (t)를 r (t)에 가깝게 유지하려고합니다 (섹션 2). 결과적으로, x (t)와 r (t)의 차이가 계속 증가하고 특정 임계 값을 초과하면, 관찰 된 상태는 기준 상태에서 벗어난 것이다. 관측 된 상태 편차를 정량화하기 위해 제어 시스템에서 안정성 지표로 널리 사용되는 적분 절대 오차 (IAE) 공식 [47]을 활용한다.

주어진 시간 윈도우 동안 공식은 편차의 총량을 계산한다. 만약 편차가 미리 정의 된 쓰레스 홀드보다 크면 우리의 규칙은 이를 통제상태의  이상의 시작이라고 한다. 우리는 Appendix A를 통해 t실험적으로 w와 t를 결정하는지에 대해 말한다. 

The second type – reference state deviation – is the case where an RV deviates from its given mission. A controller is expected to adjust its reference state to track its mission. If a controller fails to do that, it is considered malfunctioning. To detect such a deviation, our rule will check whether the  difference between the reference state and the mission target becomes persistently greater than a threshold.

We note that our detection rule only considers non-transient control state deviation. An RV may experience transient control state deviation during normal operation but can effectively recover from it, thanks to the robustness features of the controllers such as the extended Kalman filter [46, 51, 60].

두 번째 유형, -참조된 상태의 편차- RV 편차가 주어진 미션에서 벗어난 경우를 말한다.(미션 실패) 컨트롤러는 미션 트랙에 맞는 상태로 다시 돌아 가도록 기대되지만 많약 컨트롤러가 이에 실패 한다면 이는 미션실패를 야기하는 오작동으로 볼 수 있다. 이러한 편차를 탐지하기 위해 우리의 규칙은 미션 목표와 상태의 편차가 쓰레스 홀더 이상인 상태가 지속되는지 확인한다. 

RV는 일시적인 통제상태 편차는 지속적으로 겪지만 칼만 필터로 인해 가지는 robustness 특징으로 금새 회복하기 때문에 우리는 우리의 검증 규칙이 비일시적인 통제상태 편차에만 집중했다. 

Control Instability Detection

We now apply our “observedreference” and “reference-mission” deviation determination rule to detect control instability. During a test mission, the control program readily logs all its 6DoF control states (Section 2). The log data can be retrieved by the GCS software, which will then be accessed by the Control Instability Detector and applied to the evaluation of the detection rule (Fig.3). Note that the control states include those of the three primitive controllers (for position, velocity, and acceleration control) inside each 6DoF controller; and each primitive controller logs its observed, reference and mission states. As such, the Control Instability Detector can apply the detection rule to detect control state deviation at any primitive controller.

제어 불안정성 감지, 우리는 제어 불안정성을 탐지하기 위해 위의 두 가지 편차에 대해 편차 결정 규칙을 지정했다. 테스트 미션동안 제어 프로그램은 모든 6Dof 제어상태를 기록하며, 로그 데이터는 불안정성 검출기에 접속 가능한 GCS 소프트웨어에서 검색될 수 있다. 제어 상태는 각 6DoF 제어기 내부의 3 개의 기본 제어기 (위치, 속도 및 가속 제어를위한)의 상태를 포함한다. 그리고 각 기본 컨트롤러는 관찰, 참조 및 미션 상태를 기록한다. 이와 같이, 제어 불안정성 검출기는 임의의 기본 제어기에서 제어 상태 편차를 검출하기 위해 검출 규칙을 적용 할 수 있다.

Control-Guided Input Mutator

A software testing system needs to judiciously generate program inputs to achieve high bug coverage while reducing the number of the subject program’s test runs.

In other words, the set of generated testing inputs should be representative to roduce the same or similar results when other untested inputs were provided to the program. We first define RVFUZZER’s input mutation space (i.e., types and value ranges of dynamically adjustable control parameters). We then describe our control-guided input mutation strategy to generate representativetesting inputs, with consideration of environmental factors that affect the RV operation and control.
Our input generation method considers both control parameters and environmental factors3. For control parameters,
we first define their value mutation spaces (Section 4.3.1).
We then present the feedback-driven input mutator which generates a reduced set of control parameter-change test inputs (Section 4.3.2). The mutator also mutates the external environmental factors and tests the control program under different combinations of input control parameter values and environment factor values.

우리는 첫째로  RFFuzzer의 입력 뮤테이션 공간을 정의했다.(제어패널의 조절 가능한 값의 타입과 값들의 범위) .

우리는 뮤테이션 생성기를 RV의 운용에 영향을 미치는 환경 변수를 고려한 테스팅 입력값을 생성하는 것을 목표로 하였다. 

우리의 입력생성기는 제어파라미터와 환경 요인을 함께 조절가능하다. 우리는 제어 파라미터를 위해서 먼저, 값의 뮤테이션 범위를 정의했다. 그리고 우리는 피드백-driven 방식으로 입력 뮤테이터를 설계 함으로써 테스팅 시도의 중복을 피했다. 

뮤테이터는 또한 외부 요인의 값도 생성 가능하며, 외부 값과 컨트롤 파라미터들을 다르게 조합가능하다. 

Control Parameter Mutation Space

Interestingly, the ranges of many control parameters can be narrowed by polling the control program. This can be done by first sending a parameter-change command with a very large/small value; and then querying the actual value of that parameter, which now becomes the maximum/minimum value of the parameter defined in the control program. While the possibility of such probe is specific to control program implementation, we do
observe such implementation logic in ArduPilot and PX4.

제어프로그램의 뮤테이션 공간은 다음의 3가지로 구성되어 있다. 1) 동적으로 조정 되는 제어파리미터, 2)각 파라미터의 가능한 모든 값, 3)각 파라미터의 기본값

제어 파라미터들은 특정 제어피로그램과 GCS 명령 인터페이스에서 획득가능하다. 우리는 ArduPilot,  PX4, Paparazii를 대상으로 진행했으며, RV-GCS 통신으로는 사실상 표준인 MAVLink를 사용했다. 

제어 매개 변수의 값 범위는 1)제어 매개 변수의 데이터 유형과 2) 프로그램 자체의 폴링에 의해 결정 가능하다. 

제어 파라미터의 데이터 타입은 일반적으로 그 값과 범위를 결정해 준다. 예를 들어 32비트 정수를 사용하는 파라미터의 값 범위는 [􀀀231;231􀀀1]. 이다. 흥미로운 점은 컨트폴 프로그램의 폴링이 제어 파라미터의 범위를 좁힌다.  

폴링 방식의 응답을 통해서 우리를 매우 큰값과 작은값의 로 경계값 테스팅을 하고 이를 통해서 제어 프로그램에 정의된 파라미터의 상한경계값과 하한경계값을 폴링을 통해 구할 수 있음을 추측할 수 있다. 

증명해야 할 문제지만 해당 제어 프로그램 구현이 ArduPilot 과 PX4에 있음을 유추 가능하다.

이 로직에 대해서 분석하고 이를 기반으로 fuzzing을 수행한다면 좀 더 효율적일 것 같다. 

또한 뮤테이터는 각 제어매개변수의 범위 내에서 기본값을 선택한다. 이러한 기본 값은 뮤테이션 기간 동안 공같 탐색을 하는데 사용된다. 우리는 컨트롤 제어 파라미터의 기본값을 활용했다. (벤더들이 제공해줌).

#참고 폴링

여기서 "폴링(polling)이란 하나의 장치(또는 프로그램)이 충돌 회피 또는 동기화 처리 등을 목적으로 다른 장치(또는 프로그램)의 상태를 주기적으로 검사하여 일정한 조건을 만족할 때 송수신 등의 자료처리를 하는 방식을 말한다."

즉 현존 하는 대부분의 실시간 처럼 보이는 웹사이트 들은 클라이언트가 서버에게 일정한 주기를 가지고 응답을 주고받는 폴링 방식을 사용한다. 

이는 AJAX polling 이라고도 불리는데 주로 AJAX 호출을 사용하기 때문이다.

폴링의 문제점

1. 폴링의 주기가 짧으면 서버의 성능에 부담이 간다.

2. 주기가 길면 실시간성이 떨어진다.

출처: https://jokergt.tistory.com/65 [Gun's Knowledge Base]