Victor Marginean is currently leading the Security & Privacy for Human Interfaces Business Unit at Continental. While working closely together with Code Intelligence in order to ensure software quality and security, he became an advocate of modern fuzzing.
At FuzzCon - Automotive Edition, he joined us to deliver a thrilling talk about the security challenges the current development of machine learning is presenting the automotive sector with. He kindly summed up the essence of his talk titled “If you think it’s complicated now, wait for Machine Learning to happen..." in this article.
A few words about what I am doing: My team and I are mainly responsible for display solutions, interior cameras, instrument/digital clusters, cockpit HPC and sound solutions. In this article I want to explain, our software testing approach with regard to Machine Learning.
“It's clear that we need to bring the speed from the other industries into automotive, but we also need to be careful because a car needs to be on the road for 15 years. This brings up a lot of additional topics that we need to watch out for.“
Start With the Boot ROM
One of the first steps, when it comes to securing autonomous software, is to check the Boot ROM. The Boot ROM is a small piece of mask ROM or write-protected flash that is embedded into the processor chip. It contains the very first code that is executed by the processor on power-on or reset. If you have vulnerabilities inside the boot ROM, you will not be able to fix them without changing the hardware. You have probably heard about similar vulnerabilities over the last few years (or even months), that have been highlighted by researchers for example in apple products. The problem with Boot Rom vulnerabilities is that they can only be fixed, by fully replacing the hardware. This is why you should keep it simple, be careful and - most importantly - conduct proper testing!
Together with Code Intelligence, we are currently working on an implementation of fuzz testing on our boot ROM software. Our main struggle with this is that the suppliers (understandably) usually do not want to provide their source code, as it is their intellectual property.
In most projects we receive, the OEM (Original Equipment Manufacturer) defines requirements that we must ensure are implemented and tested. For this purpose, we are applying static testing, functional testing, regression testing, and now also fuzz testing, just before the pentesting phase. Most of our requirements can be met with functional and regression testing. If you specifically look at static testing and fuzz testing, you will see that out of the hundreds and thousands of requirements that we receive from the OEMs, only one percent is referring to fuzz testing.
Now, let’s have a look at what we actually get from this one percent. If you have a look at this distribution, you will see that we got 57% of the vulnerability findings out of the fuzz tests. Now this does not mean that we can rely entirely on fuzzing, especially since we are still facing the problem that many OEMs do not want to provide us with their source code, but I was still impressed with the huge impact the fuzz testing had.
It is also interesting that the fuzz tests only included specific buffer overflows - no undefined behaviors and no other bugs that were discovered by the tool. I would say that you get quite a lot from fuzz testing, especially if you do it iteratively. This would mean that you do it for all pull requests, to make sure that once you fix a bug, you will not reintroduce it later.
“Only 1% of all the security tests done for the project where CI Fuzz* was used were fuzz tests, but through them, we find about 57% of vulnerabilities.”
|
*CI Fuzz is a CI/CD-agnostic platform for automated security testing. The platform helps developers to protect themselves against unexpected edge cases. It empowers them to fix bugs during development and to achieve reproducible testing results. Watch our demo to see how it works in action.
|
Fuzzing: the Vaccine for Your Software?
Let’s look into a current-day example. During the last month, we all read a lot about medicine and how all these vaccines are working and somehow it reminded me of software. If you think about it, software is basically also an ecosystem of hundreds of thousands of functions that are somehow living inside the microcontroller. How long your software will “live” really depends on your quality standards during production. In order to better understand how software can evolve, we should have the means to measure the interactions between these different functions to see what combinations are most fit. I believe that as software complexity increases (which is especially true for embedded security testing), fuzzing enables us to make sure that our software evolves securely - without hiring 200 security experts to review our code!
How Do We Prepare for Machine Learning in the Automotive Industry?
Honestly, right now I do not see another way than with fuzz testing. We need testing methods that can protect us against the different additional attacks, coming from the arrival of machine learning in the automotive sector. Especially, since the consequences of someone getting access to my vehicle or gaining remote control, can be devastating.
About Victor Marginean
Victor is currently working at Continental Automotive near Frankfurt and leads the Security & Privacy for Human Machine Interface Business Unit. This includes the Governance and Development teams world-wide. He previously worked for more than 10 years in Telecommunications at Nokia and in Cloud computing at Cognizant SoftVision. He is a tech geek and the new passions are UNECE R155 readiness preparation and the combination of automated driving, machine learning and the impact on CyberSec.