Android Operating System: One Potential Vulnerability per 4000 Lines of C++ Code

 

For many years, Andrey Karpov has been publishing articles on code quality, and bugs reviews of open source projects. For example, he is the author of such publications as “The Ultimate Question of Programming, Refactoring, and Everything” and “27 000 Errors in the Tizen Operating System“.

image1

Recently, the open source Android operating system has become of interest for him. He researched that part of the operating system code, which is written in the C and C++ languages. After that he came to a conclusion, which always takes place after such research: human error is always possible. By using the PVS-Studio tool, it becomes possible to detect at least one security defect (potential vulnerability) per 4000 lines of code.

Android code is of high quality and is well tested. However, no matter how carefully people wrote and tested the code, the probability that the error will be unnoticed is very high. Static and dynamic code analysis tools can cover for developers. In this case, the PVS-Studio SAST static analysis tool for applications security was used to find defects.

Sure, no matter which supporting tools you use, there is no guarantee that errors and vulnerabilities will not remain in the code. However, their number can be dramatically reduced even at the code writing stage.

Let’s see the example of one security defect found in the Android code.

static void FwdLockGlue_InitializeRoundKeys() {
  unsigned char keyEncryptionKey[KEY_SIZE];
  ....
  memset(keyEncryptionKey, 0, KEY_SIZE); // Zero out key data.
}

An array keyEncryptionKey is created on the stack and stores private information. At the end of the function, a developer wants to fill this array with zeros so that it would not accidentally get somewhere, where it should not. The following article tells about the way the information can get somewhere, where is shouldn’t be: “Overwriting memory – why?“.

To fill an array storing private information with zeros a developer uses the memset function. The comment “Zero out key data” confirms that we understand everything correctly.

A potential vulnerability lies in the fact that with very high probability the compiler will remove the function call to memset when building the release-version. Once the buffer after a call to memset is not used, the function call to memset is superfluous in terms of the compiler.

We have before us a classic security defect, classified according to the Common Weakness Enumeration as CWE-14: Compiler Removal of Code to Clear Buffers. The less of such errors – the more difficult it is to find and exploit the vulnerability in the system. In other words, the smaller is the number of CWE-bugs in code, the less of them can become CVE under certain circumstances.

If you are interested in this topic, we suggest to get acquainted with the full text of the article by Andrey Karpov: We Checked the Android Source Code by PVS-Studio, or Nothing is Perfect

Enjoy the reading!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.