Connection between Control Coupling and Security:

Control Coupling (CC), some details:

Basically, control coupling occurs when control is transferred from one component to another. (DO-248C states that)

There are different ways of transferring control between components, which affect the coverage analysis of the couplings formed in these different cases.

For C/C++, the following ways (without considering multithreading mechanisms) should be noted

(in C programs, only the first two can be used)

- Call by name;

- Call by pointer;

- Calling a virtual method (using dynamic binding);

- Execution of a throw statement;

- Calling constructors and destructors when creating and destroying class objects;

- Execute overloaded operators.

Calling by name is the simplest case:

Function definitions and function calls can be found by parsing the source code, thereby discovering couplings between components that exist in the source code. In partial integration testing, however, it is important to remember that traversing the call point of a function does not mean that the corresponding coupling has been covered, if the test calls a stub rather than a real airborne function.

Detecting call by pointer is challenging.

During the static analysis stage, it is necessary to identify the functions that are callable with the call-by-pointer operator. Subsequently, while conducting tests, the occurrences of these functions being called must be recorded. A dataflow analysis can be carried out to identify the linkages between the definition and use points of variable values (in this scenario, pointer values) to generate a list of potential functions.

A simpler method for identifying couplings involves comparing function signatures in the source code with the type of pointer used for function calls.

For each call-by-pointer operator, a set of potential functions that can be executed is generated, thereby reducing the collection of coupling coverage to recording all the called functions.

Typecasting pointers can lead to situations where a function is called by a pointer with a type that does not match its signature. This issue arises when analyzing couplings implemented through pointer calls.

When utilizing dynamic binding in C++, it may be challenging to determine the methods of which classes are called when calling a virtual function since some of them may never be called.

As advised in the supplement to DO-178C (refer to RTCA DO-332, Section OO.6.7.2), coverage is deemed complete only if all methods that could be called (as per the language syntax) when calling a virtual function were called. In C++ programs, implicit calls are allowed, e.g., calls of constructors and destructors when creating and deleting objects.

In this case, for one class, several constructors can be defined (including the copy constructor), while destructors can be declared as virtual functions. In addition, overloading of language operators (including the function call operator, “()”) should be taken into account.

Control coupling coverage analysis should consider the coupling that arises when class objects are created and deleted, or overloaded operators are used (together with their corresponding constructors, destructors, and operator definitions).In C++, control transfer between components can be implemented using the exception handling mechanism (try-throw-catch).

If an exception handler (catch) is defined in one function and a throw occurs in another, then invoking the exception handler corresponds to control transfer between the functions, i.e., it should be regarded as a coupling between them.

To find such couplings in source code, it is required to track call chains that begin in the try blocks, while tracking the possible overrides of the exceptions processed in the catch blocks, in order to determine the actual catch blocks to which control is transferred upon occurrence of throws.

Moreover, control coupling between components can be established by organizing their interaction in multithreaded software systems.

Searching for interthread couplings in the process of source code analysis can present quite a difficult problem due to a variety of methods used for organizing these couplings.

Security side of the CC:

Minimizing control coupling can have indirect benefits for security in a software system.

1. Isolation of Components:When modules are less control-coupled, it often means they are more isolated and encapsulated. This isolation can prevent unauthorized access to critical functionalities or data, enhancing security.
2. Attack Surface Reduction:A system with reduced control coupling tends to have a smaller attack surface, meaning there are fewer pathways or interfaces that could be exploited by attackers. This reduces the chances of security vulnerabilities.
3. Modular Security Policies:Minimizing control coupling allows for more modular security policies. Each module can enforce its own security measures without being overly dependent on others. This can make it easier to manage and update security features.
4. Easier Security Audits:Modules with low control coupling are typically more self-contained and have clearer boundaries. This makes it easier to conduct security audits and identify potential vulnerabilities or weaknesses.

Reducing control coupling can contribute to a more secure system.