Feature: System security


Figure 2: Screenshot of buffer overflow detection with the TrustInSoft exhaustive static analysis tool


void increment_array(int array[], int len) { while (len >= 0) { (*array)++; // Increment the value of the array // cell array++; // Move to next array cell len--; // Decrement counter }


}


int main(int argc, char *argv[]) { int data[4] = {1, 3, 5, 7}; char name[] = "foobars"; increment_array(data, 4); // Increment array


} A traditional test would validate the function’s requirement to


increment the cell values in the output array, and report a pass or fail based on the result. Te test designer may not consider checking whether the loop end condition (and, therefore, the array index) caused an out-of-bounds memory access due to unexpected or undesired side effects in the system. Tis does occur in this code sample due to an improper condition specified in the while loop. A traditional test against requirements would miss the buffer


overflow condition and report that the array is {2, 4, 6, 8} aſter calling the function and would always pass, as shown in the following console output from an example test run:


gcc -I. increment.c -o ub && ./ub Run test_increment_array() increment_array({1, 3, 5, 7}) = {2, 4, 6, 8} --> PASSED


Without prior consideration from the developer or tester 14 June 2024 www.electronicsworld.co.uk


behind the test run for out-of-bounds array access, the buffer overflow would not have been detected, resulting in a false negative. Not only is this flaw subtle and easy to miss with traditional testing methods, it can result in memory corruption and cause soſtware crashes and defects, as well as introduce vulnerability to the applications of vehicle soſtware. Tis is the problem of traditional testing. In this example, the TrustInSoſt tool detects the application


writing 16 bytes aſter the beginning of the array; see Figure 2. Tis memory corruption is revealed by a more verbose test case, where the out-of-bounds write condition affects the value of the variable name – even though it is not involved in the tested function; see the following example of the console output:


gcc -DVERBOSE -I. increment.c -o ub && ./ub Run test_increment_array() Address(data) = 0x7ffe8eb68f50 = 140731292749648 Address(name) = 0x7ffe8eb68f60 = 140731292749664 Before increment array = {1, 3, 5, 7} - name = foobars Aſter increment array = {2, 4, 6, 8} - name = goobars increment_array({1, 3, 5, 7}) = {2, 4, 6, 8} --> PASSED


Tis simple example illustrates that even applications with


complex control and data paths can benefit from exhaustive static analysis to ensure safety in their automotive soſtware.


Using a sound tool Soundness means that you can’t prove anything that’s wrong. TrustInSoſt Analyzer is sound; more precisely: if there are no undefined behaviours found by the analyser then it means that the analysed program has no undefined behaviours. In other words, there are no false negatives, and the absence of


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52