Security an increasingly important component of open source efforts

Top automotive security flaws pt. 2: code and code injection

on Nov 3, 15 • by Jeff Hildreth • with No Comments

Read on to learn about what you can do to secure your code from the #8 and #7 vulnerabilities of 2015: improper control of generation of code, and weaknesses introduced during development ...

Home » Software Security » Top automotive security flaws pt. 2: code and code injection

Over the past few weeks we’ve hosted a webinar, The top ten automotive cybersecurity vulnerabilities of 2015, and taken a deeper look at two of the top 10 cybersecurity vulnerabilities: #10 numeric errors and #9 cryptographic issues. Today we’ll continue our immersion into these top vulnerabilities by examining two more.

#8 Code injection – (21:05 in the webinar)

Code injections are something that affect interpreted environments such as PHP, so this is a large vulnerability among the website development community. Despite this vulnerability being largely seen in website development, it is still very much present when it comes to infotainment systems and other complicated in-vehicle systems.

Because there is usually a scripting engine in place to take care of a lot of the service startup, there is usually an extra vector that can be attacked. This can also affect black box components containing interpreters that you’re unaware of, like a font interpretation.

Example of code injection (22:45)

Code injection example: Windows RTThe example we use is Windows RT, which is interesting because this isn’t open source code. This proves that even though something may be proprietary, it doesn’t mean that it isn’t open to vulnerabilities. This is important to know when doing integration of these technologies into your code. Something as innocent seeming as being able to display fonts could be the reason why your code has become vulnerable.

So how can you fix vulnerabilities in proprietary code?

At 23 minutes at 47 seconds we discuss design review, manual analysis, and automated static analysis as the remediation, but understand that security proprietary code can be challenging.

From a design standpoint you need to make sure that you’re aware of all your black box components and that all of them are up-to-date. Don’t assume that everything is within your own system. Pay special attention to items that may be pulling from a website.

Static code analysis can help in this realm by identifying the use of unsafe data as it flows through the system. This is where you’ll likely catch an injection-based attacks. Follow up by manually cleaning any externally acquired information.

It’s important to keep in mind all of the code that is coming into your ecosystem, assume that there are vulnerabilities in multiple stages of your software development lifecycle.

#7 Code – (26:47)

It may seem odd to have this as its own vulnerability, but code made the list because we’re talking about anything that doesn’t fall into a very specifically defined category – so consider this the catchall vulnerability. This can include things like:

• Mismanaging passwords, storing plaintext passwords, hardcoded passwords
• Improper handling of API contracts
• Improper or absent error handling
• Improperly handling time and state
• Code generation issues

One thing we emphasized was to not create your own encryption – it isn’t worth it. It’s very easy to reverse engineer and has left many people frustrated and embarrassed when it doesn’t behave how they anticipated.

Example of code (28:26)

Security vulnerability code - chrony example failThe example we have for this catchall of vulnerabilities is chrony (NTP) where it’s not initializing the last “next” pointer when saving unacknowledged replies to command requests. What ends up happening is that you’re actually executing arbitrary code or at least creating a denial of service.

At 28 minutes and 51 seconds, we show a code snippet to explain the vulnerably. The sample shown is very subtle, and might actually require some studying before seeing why that there is a vulnerability. Basically, the issue in the example is that this a very long and complicated test, and that the logical ore in the code causes an invalid time stamp when you come through with an issue token of one (1). This means that you’re going to allow a token to be issued without properly examining the test.

Explore how to fix the code (29:37)

Security vulnerability code - chrony example fixWe see that it changes the code up a little bit, but that fundamentally the fix is making the control logic much easier to see and much clearer. Take note that this is the way you should design it in the first place so that you don’t have overcomplicated code. Though it may seem boring, sometimes coding by the book will save you from a vulnerability.

Continuing on the path of remediation (30:21), we explore design review and manual analysis as ways to avoid catchall code vulnerabilities. Be sure to use well-identified coding patterns – tricky coding doesn’t do anyone any good. Also create consistent API contracts and track the use and storage of encrypted data passwords.

Keep an eye out for unclean code, as it often points to poor quality and potential security issues. Unclean code itself isn’t always the vulnerability, but unclean code can be an indicator of where there was no methodical process. And be sure to handle all errors so you aren’t left with any surprises.

We wrap this section by reminding everyone that good coding means good security. You may not enjoy having a coding style guide, but rest assured that it exists to keep vulnerabilities at bay.


Let me know in the comments if you have any questions or feedback on these vulnerabilities. And be on the lookout for future blog posts where we’ll explore the remaining to 10 cybersecurity vulnerabilities.

Related Posts

Leave a Reply

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

Scroll to top