Automotive security vulnerabilities image

Does the ‘V’ in GENIVI represent vulnerability?

on May 8, 17 • by Walter Capitani • with 2 Comments

Everywhere we look today, security’s in the news. Nowhere is this more evident than in the automotive sector. Rogue Wave Software engineers recently performed a security analysis of the GENIVI open source code base. Here's what they found...

Home » Static Analysis » Does the ‘V’ in GENIVI represent vulnerability?

Everywhere we look today, security’s in the news. From the usual data breaches revealing passwords and other private information, to the explosive growth of hacking opportunities of connected devices in the IoT, this trend seems set to continue for some time.

Nowhere is this more evident than in the automotive sector, which has recently upgraded its functional safety standard to tackle cybersecurity issues.

As part of our ongoing research into security vulnerabilities, Rogue Wave Software engineers have recently performed a security analysis of the GENIVI open source code base. For those not familiar with GENIVI, it is a consortium of automotive OEMs and suppliers which have joined together to share code common to vehicle infotainment systems.

A summary of these results can be seen in the Klocwork CWE Top 25 Security Report, a built-in report debuting in Klocwork 2017.1, released last week. These built-in reports can be generated for many common security rulesets, including CERT-C and DISA-STIG. This report provides information on the trends, current security, and new vulnerabilities detected in the GENIVI open source code base.

Klocwork Security Report GENIVI Components

We can quickly glean from the pie chart in the top left corner of the report that there are a number of critical security vulnerabilities in the code base. Inspecting the Top 3 New Vulnerabilities table, we can see several areas of concern, particularly the CWE-120 issues of which there are 93. In addition, the navit source code module is highlighted as the riskiest source code directory.

This report can quickly be included in your next project status report or sent to management to indicate the progress being made to close out security vulnerabilities. The report is interactive so we can click on a security rule and browse all related vulnerabilities, or we can click on a severity section of the pie chart to view the associated security issues.

If we click on the ‘Critical’ section of the pie chart, the Klocwork portal displays the list of defects assigned this level of severity. We can see that there are a number of issues related to array bounds violations and tainted data, particularly in the navit module called out in the security report as a risky area of code (see the issue highlighted in blue below).

The security report

If we take a closer look at this vulnerability, we can see how tainted data is used as an array index on line 542 of the code, which represents a serious security issue.

A closer look at this vulnerability

The good news about the GENIVI code base is that most of the security issues found are relatively simple to correct, and therefore it shouldn’t take long to eliminate these vulnerabilities and publish a secure, open source infotainment infrastructure we can all rely on.

Stay tuned for upcoming blog entries as we continue to scan updates to the GENIVI code base and report on any new and fixed vulnerabilities that we find.

Attending the GENIVI All Members Meeting this week? Come see us at the showcase Wednesday night.

Learn what else is new in Klocwork 2017.1.

Watch this video and see how easy it is to create reports and manage security with Klocwork.

Related Posts

2 Responses to Does the ‘V’ in GENIVI represent vulnerability?

  1. Stephen Lawrence says:

    Regarding the high number of issues reported against Navit. Navit is an upstream navigation engine that is used in the oss proof of concept for certain Location Based Services (LBS) APIs in the Genivi Development Platform (GDP). It is not part of the Genivi Specification, nor is part of the core Genivi middleware.

    You might consider defining whether by Genivi Components you mean components created and maintained by Genivi or upstream components. For the latter you could further divide between upstream components that are likely to play a part in the middleware such as bluez and those that are used above the middleware to illustrate application concepts in GDP.

    • Walter Capitani says:

      Thanks for pointing that out. We just recently started analyzing the GENIVI codebase, and wanted to use these analysis results to illustrate how static code analysis can help ensure code security. I’d be interested to know – which components might you (or the community) be most interested in?”

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top