Software security

Top automotive security flaws pt. 1: numeric and cryptographic errors

on Oct 27, 15 • by Jeff Hildreth • with No Comments

Learn more about numeric errors (#10) and cryptographic issues (#9) as we countdown 2015's top automotive security vulnerabilities...

Home » Software Security » Top automotive security flaws pt. 1: numeric and cryptographic errors

As mentioned in my previous blog post, What are the top automotive cybersecurity vulnerabilities?, we’ll be diving into the top 10 vulnerabilities over a series of blog posts with in-depth information from our recent webinar. Read the blog post, follow along with the recorded webinar, and provide comments below to keep the conversation going.

#10 – Numeric errors (7:36 in the webinar)

The number 10 vulnerability is identified as numeric errors. These errors can be a lot of different categories of problems:

• Wrap around errors

• Improper validation of array index

• Integer overflow

• Incorrect byte ordering

• Incorrect conversion between numeric types

• Incorrect calculation

Math calculations that you’re doing, if you not looking for overflows using data that’s coming from an external source, it’s subject to this kind of a vulnerability.

Example of a numeric error (8:12)

The example we use is a bug in the bitmap, or BMP file decoder, in Qt. Here, it doesn’t properly calculate the masks used to extract the color components like red, green, blue, and alpha components of the image.

Numeric errors - Qt example: fail

If you create a bad image in just the right way you can cause the software that is creating that image to crash. This bug may have taken a little bit longer to be recognized because it isn’t a JPEG or other common image file.

Then, at 9:20 in the webinar, we explore the failure in the actual code. 

As you’ll see in the code, there are shift and scale values that are being calculated from the bitmap that is being loaded, and in this example, we’re taking 256 and dividing it by a calculated value of what the mask shifted by the shift value, and then adding one.

Numeric errors - Qt example: fix

This will make the system crash if the mask value is a bunch of 1s and shift values is a bunch of 0s because you would be dividing 256 by 0.

Though some people may claim that this situation would never really happen, that isn’t the point. The main point is that security is very difficult because it’s not just about coding correctly, you have to also think maliciously and code defensively while coding correctly. You can no longer code for just good circumstances, you must code defensively for bad circumstances.

How to solve numeric error vulnerabilities (11:09)

By simply adding in code that says every time a denominator might come out as equaling zero, we say the image is bad and bail on the set of code. By doing this we’ll never run into a zero answer because we’re testing every single time to ensure we bail out on bad images.

Making sure to avoid these bad images is important because you can never truly be sure where your images are coming from. You may think you’re only displaying logos and safe files, but your code could be pulling images from Bluetooth or web-based apps without you having visibility into this.

We wrap numeric errors at 12:32 with a recap of remediation tactics. To help with numeric errors, you need to enforce, regulate, and pay to:

• Architecture and design guidelines

• Implementation guidelines

• Manual analysis

• Automated static analysis

• Automated dynamic analysis

Vulnerability number 10 was wrapped by emphasizing that security needs to be considered a high priority through the entire build phase. It’s important to remember that no matter how small or inconsequential an error seems to you, it could be the perfect breeding ground for a malicious attack. Regardless of what you’re creating, all vulnerabilities need to be secured.

#9 – Cryptographic issues (15:10 in the webinar)

As mentioned in the webinar, these are the “fun” weakness – the weaknesses related to the use of cryptography are the weaknesses that baffle so many developers. There are a lot of things that you could do to mess up cryptography:

• Missing encryption of sensitive data

• Key management errors

• Missing required cryptographic step

• Inadequate encryption strength

• Use of broken or risky cryptographic algorithms

• Use of reversible one-way hash

• Not properly using random initialization

• Improper use of RSA algorithm

Example of cryptographic issues using OpenSSL (15:47)

As we all know, OpenSSL got famous a short time ago for Heartbleed, which is a separate issue than what we cover here. The issue we explore is where OpenSSL doesn’t ensure that the pseudo random number generator gets seated before it proceeds with the handshake.

Cryptographic issues - OpenSSL example: failWhat this basically means is that there isn’t sufficient information to ensure that the output is predictable when it goes through the algorithm. This means that the space that is needed to test for possible keys against encrypted data is drastically reduced and people will therefore be able to break the encryption. The hacking of Wi-Fi WPA encryption is a good example because the way those numbers are seated, regardless of the WPA security, make it hackable due to the consistent time around startup.

We dive into our code example at 17:42 in the webinar.

Cryptographic issues - OpenSSL example: fixThe main piece to understand in this example is that we’re examining a piece of the client buffer in the loop, where we say if something happens then go ahead and fill the random buffer. The problem with this is that we’re not calling the fill_hello_random if that value is non-zero. This means that there are paths through that code where it won’t be a random buffer when we start the handshake which can lead to unpredictable results.

We show the fix for our OpenSSL example at 18:35 in the webinar.

And the fix for this is: always calling a randomizing function. There should always be a test to make sure that the value is acceptable, but then – you always call the randomizing function. So now if you have a zero flag coming in you can abort, which ensures that you can’t start the handshake without having a randomizing buffer – which is crucial.

How to solve cryptographic issues (19:00)

In order to remediate cryptographic issues you absolutely have to put design review to the top of your list. Key design decisions should be reviewed by someone with a very deep understanding of cryptography so nothing is missed – don’t make the mistake of assuming you have enough knowledge to make it work. And keep up on the latest research so you can be aware of any changes.

It’s important to not forget about manual analysis: carefully analyzing the cryptography process and making sure that error paths are checked and working properly. This may seem like Programming 101, but it’s something that’s really, really important and needs to always be a part of your process. Also double-check your non-standard flow control to make sure you aren’t overthinking things.

We wrapped the discussion around cryptographic issues by again mentioning the importance of staying current on research so you can always be alerted to any new vulnerabilities that may unknowingly be in your code.


Stay tuned for a recap of the remaining vulnerabilities in the coming weeks.

Have any questions about numeric errors or cryptography issues? Leave a comment for discussion.

Related Posts

Leave a Reply

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

Scroll to top