what‘s different about fuzzing automotive software?

WHAT‘S DIFFERENT ABOUT FUZZINGAUTOMOTIVESOFTWARE?

RAKSHITH AMARNATHCORPORATE RESEARCHROBERT BOSCH GMBH

FuzzCon Europe 20202020-09-08

Corporate Research | Rakshith Amarnath | 2916 | 2020-09-08© Robert Bosch GmbH 2020. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as well as in the event of applications for industrial property rights.

What is this talk about?What's different about fuzzing automotive software?

Why fuzz automotive software?What’s the difference?How to cope with the differences?Conclusions and Takeaways


What's different about fuzzing automotive software?



What's different about fuzzing automotive software?Why fuzz automotive software? Take proactive

measures Continuous fuzzing of

automotive software (especially for SAE automation level 3 and above)

Compliance to internal/future norms Internal guidelines

and norms at companies

Future Norms e.g. ISO/SAE 21434

Technically effective Fuzzing also makes

technical sense: to combat large number of false positives of static analysis, finding subtle bugs that go beyond simple coding guideline checks etc.

Requirements from customers Automotive

manufacturers emphasize that fuzz testing be done

4

Intrinsic and extrinsic motivations for fuzzing automotive software

Fuzzing makes sense and just doing it! Fuzzing gets imposed and having to do it!


Difference #1: Platform dependenceWhat's different about fuzzing automotive software?

6

Peculiarities

Impediments

• Stronger platform dependence due to resource constraints and optimizations• Well established Hardware-in-the-Loop (HiL) testing• Customary use of certified compilers

• Stubbing necessary to eliminate platform dependencies• Execution on Linux is not always possible out of the box• Complex build chains (e.g. code generation) require special treatment• Non trivial interfaces make creation of fuzz targets challenging

Challenge: High entry barrier for fuzzing automotive applications


Difference #2: StatefulnessWhat's different about fuzzing automotive software?

7

Peculiarity

Impediments

• Automotive software is predominantly stateful -> a set of state transitions have to occur before something interesting happens

• Traditional fuzzers target software with single input whereas stateful programs require sequence of inputs

• Adequate consideration of evolving program state during input generation is missing

• Resetting (cleaning up resources for) the software that runs on its own (in infinite loop) is challenging

Challenge: Novel fuzzing techniques are required to fuzz stateful embedded software


Difference #3: Integration of 3rd Party BinariesWhat's different about fuzzing automotive software?

8

Peculiarity

Impediments

• Automotive software often involves multiparty software (binaries) from different vendors

• Unavailability of source code makes it hard to achieve the performance equivalent of state of the art modern fuzzers

• Executing native automotive binaries virtually is not always possible using prominent instruction set emulators like QEMU, UniCorn, Gem5

Challenge: Scalable approaches needed for fuzzing native automotive binaries


Solution: Lower the barrier What's different about fuzzing automotive software?

10

SUT

Fuzzer

Input (StdIn)

Crash/Timeout

Fuzz TargetAutomotive SW

Abstract Fuzz Target- Manage lifecycle i.e. (startup,

input injection, execution, teardown)

- Input transformationInherit

Eased by

Separate security specific activities from projects to lower the overhead for security testing

Automotive Software:- Non-trivial input format

required- Special setup phase

required

Fuzz Target:- Directly affects quality of

fuzzing- Most effort in connection

to fuzzer + writing fuzz target


Solution: Provide support for stateful fuzzing (ongoing research)What's different about fuzzing automotive software?

11

Motivation: The more (automation in finding internal states), the better

What will stateful fuzzing help with? Allows systematic testing for sequences of inputs leading to security vulnerability (Ideally) no knowledge or specification of “critical” internal states necessary

Open research avenues? State identification Building sequences Picking a state to fuzz

Create input

Inject input

Check for crash

Reset SUT

Start up SUT

Fuzzing stateful programs has potential for further research in the context of embedded software

Recent research that addresses stateful aspects for network protocols in Servers:

AFLNET: A Greybox Fuzzer for Network Protocols


Solution: Fuzz native binaries (future work)What's different about fuzzing automotive software?

12

Perform compile time lightweight instrumentation to collect code coverage

Fuzzer Program (under test)

[;x1-GPZ+wcckc];,N9J+?#6^6\e?]9lu2_%'4GX"0VUB[E/r~fApu6b8<{%siq8Zh.6{V,hr?;{Ti.r3PIxMMMv6{xS^+'Hq!AxB"YXRS@!Kd6;wtAMefFWM(`|J_<1~o}z3K(CCzRH JIIvHz>_*.\>JrlU32~eGP?lR=bF3+;y$3lodQ<B89!5"W2fK*vE7v{')KCi,c{<[~m!]o;{.'}Gj\(X}EtYetrpbY@aGZ1{P!AZU7x#4(Rtn!q4nCwqol^y6}0|Ko=*JK~;zMKV=9Nai:wxu{J&UV#HaU)*BiC<),`+t*gka<W=Z.%T5WGHZpI30D<Pq>&]BS6R&j?#tP7iaV}-}`\?[_[Z^LBMPG-FKj'\xwuZ1=Q`^`5,$N$Q@[!CuRzJ2D|vBy!^zkhdf3C5PAkR?V hn|3='i2Qx]D

Leverage code coverage information at runtime to mutate existing inputs to maximize code coverage

Binary (under test)

Inject sanitizers and instrumentation into native binary

Virtual Hardware

execute

Providefeedback

Going ahead, systematic and scalable approaches for fuzzing automotive binaries are needed

Recent research addressing smart fuzzing on RISC-V based virtual prototypes:

Fuzzing Embedded Binaries leveraging SystemC-based Virtual Prototypes


Wrap UpWhat's different about fuzzing automotive software?

14

Why fuzz automotive software?

What’s the difference?

How to cope with the differences?

Intrinsic motives

Extrinsic motives

High entry barrier for fuzzing

Stateful software

Native binaries complicating fuzzing

Ideas to lower entry barrier

Thoughts on fuzzing stateful programs

Thoughts on fuzzing native binaries

Fuzzing IS and CONTINUES to be important for automotive (IoT) software


Takeaway: Curious to contribute?What's different about fuzzing automotive software?

15

Bosch Software

(C, C++, …)

Automated Security Analysis & Testing Platform at Bosch CR

Automation Server

(Jenkins)

Stateful Fuzzing

SW

Input SequenceGrammar Fuzzing

SW

Input GrammarOrchestrated Fuzzing

SW

Input Queue

Your super Fuzzer

SW

I have a cool fuzzer

for embedded applications

Extensible platform enables contributions from the fuzzing community

Reporting identified vulnerabilities


Acknowledgements and ContactWhat's different about fuzzing automotive software?

16

This talk wouldn’t have been possible without the ideas and great work of my team of experts, researchers and engineers. I sincerely thank the following people: Dr. Simon Greiner Dr. Christopher Huth Mark Giraud Dr. Nishant Sinha Anjali Bhat and Rajat Jaiswal

Management support for the topic has been tremendous so I also sincerely thank: Dr. Paul Duplys and Dr. Andreas Nauerz

Feel free to reach out to me on LinkedIn or firstname[dot]lastname[at]bosch[dot]com


Time for QuestionsWhat's different about fuzzing automotive software?

17

We are hiring!Our Mantra: DevSecOpsJoin my team#software security

Research Scientist

Research Scientist

PhD position

https://www.bosch.de/en/career/job/REF81466H-research-scientist-for-software-security-and-security-automation/

https://www.bosch.de/en/career/job/REF81473I-research-scientist-for-security-engineering-and-security-automation/

https://www.bosch.de/en/career/job/REF82866V-phd-software-security-and-security-automation/

what‘s different about fuzzing automotive software?

Documents