Attack Objectives and Scenarios

This section describes the AMP system-specific technical attack objectives. As is discussed in Section 4.3.7, threat actors aim for changing the system state. In other words, the adversary wants to control or disrupt the system’s behaviour. Disregarding of their motivation, it is assumed that the adversary aims for a specific function. A specific function which is technically represented as a process on the application layer and logically bound to a specific MC-domain (compare Section 4.3.3).

Harper et al. [62] define five phases of hacking/attacking a systems, from which the first three are considered in the following: Reconnaissance, which means to "ob- tain information either actively or passively" [62, p. 15], Scanning, to identify the environment which will be compromised, Gaining Access, which means to exploit the previously identified vulnerabilities [62], and Maintaining Access, or to make sure a re-entry is possible and finally to cover tracks to hide the malicious activities.

A crucial fact of considering memory based (and memory-map based) attack vectors is that the attacker needs to know its particular target memory area and therefore its address. Many known memory exploits and techniques rely on this issue. Some prominent examples are buffer overflow attacks [40], format-string attacks [40] and Return Oriented Programming (ROP) [24]. These techniques have one common base, the modification of a return address of a function call in order to jump into injected and malformed code sections. The details of those techniques are out of the scope of this work. However, it is important to mention that the effort to determine the specific address or the relative position (offset) to a particular instruction is crucial. Usually the attack vector works as follows. Somehow the adversary needs to gain access to the application and exploits a vulnerability of a function, via a buffer overflow for example. In the next step, the adversary re-interprets the code structure and seeks for a suitable position to interfere with the control flow of the application. Most commonly this is done via overwriting the return address of a function call. The newly written address points to a memory area which is under control of the adversary.

In the following this process is formalized. Step 1: Gain access/entry the function Step 2: Re-interpret structure

Step 3: Mount attack

In order to mount an attack described above, there were still some assumptions made. In order to find a suitable entry to the system, the adversary needs to put effort

into exploring it. This is usually referenced to as reconnaissance in a preparational step. Reconnaissance also takes place in Step 2, when the adversary seeks to re-interpret the structure of the system to proceed with Step 3, which is the execution of the attack. As a result, this could be split into preparational reconnaissance and online reconnaissance.

Threatening the System State. This subsection aims at defining the goal of threatening a system element. In this particular environment, the fulfilment of system qualities is prioritized. One important component in achieving this goal is to ensure that the system operates as it was intended. Hence, the proper function of the system turns into the focus of the stakeholder of the system. On the threat agent side this means that if someone endeavours to misuse the system in any way, they must manipulate its behaviour. The system state is, on a logical level, the asset that an adversary aims at changing in order to reach their goal. The system’s state is an abstract description of what a system or function is operating on during runtime. Consequently, if a threat agent is capable of changing the state of a system, he has control over the system. If this is transferred to AMP systems, OS have states which are exposed to be fraudulently interfered with by other OS or data flows consumed by them.

Control-Flow Integrity (CFI) related Attacks

Attacks on the integrity of control-flows are a severe representation of tampering threats. This type of attack is affecting the Control Flow Integrity (CFI) by subverting the machine-code of software-systems [2]. In short, CFI attacks aim for illicit control of a program’s state. Control-flows can be subverted either directly by tampering with the instructions of the machine code or indirectly by modifications of data that are consumed by the program. The latter type of attack is referred to as non-control flow data. Control-flow data are kernel text sections, such as instructions in binary code or function pointers which redirect the execution flow of instructions. Furthermore, processor registers which contain the instructions to be executed [133]. Non-control flow data preserve possibilities to interfere with the state of the program and can be categorised with the following [26]. Typical examples concerning MPSoCs are input data which are consumed by a program and affects their behaviour. Input data can be something that has been issued by an external entity such as a sensor connected by an automotive bus. On an application and OS level, this might be a message passed over an SHM or on a SoC level data frame that was communicated through the communication architecture. The subversion of configuration data includes a broad

range of possible surfaces as well. Most notably, this could be the configuration of a processing element or a memory protection unit which enforces the separated address spaces for the particular system levels. Modifying identity data implements typical spoofing threats. The modification can cause a program to falsely authenticate a communication entity due to compromised identification data. Lastly, the category of decision-making data can influence boolean variables which imply a conjunction or disjunction to reach the final verdict [26].

CFI Attack Types

Following Petroni et. al [132], the following CFI-specific Threats are categories, which are differentiated and considered:

User-space object hiding: Aims to inject code with an illicit capability within an user-space object such as an application.

Privilege escalation: Code injection with illicit capability within user-space aiming for escalating/elevating privileges.

Re-entry/Backdoor: Implements illicit capability on OS-level.

Reconnaissance: Reverse engineering of kernel structures in order to gain knowl- edge about system structures or functionalities.

Defense neutralization: Deactivation of defense or protection controls imple- mented on OS-level.

Control Flow Side Channel Attacks In general, side channel attacks aim at exploiting leaked information which was gained by a covert channel [124]. Covert channels are not intended for information transfers such as the software program’s effect on the system load [105]. Recent endeavours revealed several instances of side channel attacks that take effect on adjacent system entities. For example, Rowhammer has been introduced by Kim et al. in order to flip bits in a DRAM11 _{row without}

accessing them directly [96]. Furthermore, with Meltdown and Spectre, possibilities have been demonstrated as how to misuse the speculative behaviour of modern (embedded) processors [103, 111].

4.4 Summary

This chapter elaborated upon the vulnerability assessment of two hypothesised attacks. This was approached by the conceptual analysis of the vulnerability and exploitation of these attacks. First, the disruption of the accesses to a shared last level cache was examined. Second, the assessment on the tampering of memory by an adjacent processing element has been conducted.

A denial-of-service attack on shared cache setups of modern processing element designs has been discussed. The contention is caused by shared way-sets in k-way-set associative caches. The concept shows how to provoke the contention by overcommit- ting associated way-sets. As a result, the vulnerability is a non-controlled shared usage of cache way-sets, which enables an adversary to provoke cache-misses on memory accesses. In the CVSS scoring, this vulnerability has been scored at Medium (5.3) with a high impact on the availability of the attacked domain.

The exploitation of the identified vulnerability has been conceptually and experimen- tally approached. The assessment reveals that particular physical addresses can be modified and cause the previously described effects. This is possible, even though they are in separated memory partitions of asynchronous domains located in an AMP system. In a penetration test, the formerly conceptualized attack was experimentally demonstrated. Here, on the basis of the experimental platform, an increase of 129,501

CPU cycles (arith. mean) per memory access has been provoked by the DoS attack.

The consideration of the temporal CVSS score slightly decreased the value from 5.3 to

4.8, which is still a Medium exploitability score. The maturity of the given experimental

exploit code has been rated as Functional, which means it shows the effects but must be adapted to be applicable in other systems.

The second assessment approached concepts of misusing a memory access capabil- ity in heterogeneous MPSoC designs. DMA capable peripherals such as GPUs and co-processors can be misused to exploit an insufficient protection architecture within the MPSoC. The conceptual exploitation has been analysed and scored with CVSS at the level High (8.1 ). Having this vulnerability in place, a change of privilege scope is possible. This leads to High impacts regarding the confidentiality and integrity of the asset.

Experimentally, the exploitation of the identified vulnerability has been explored and scored. The penetration test demonstrates a compromisation of a co-processor firmware image to circumvent the memory protection of the main processors. As a result, the

temporal CVSS score is High but decreased to 7.4 due to the maturity of the shown exploit code.

Both assessments were reflected in the third part of this chapter. Here, a general view of the given vulnerabilities and assets is conducted. For that purpose, the concepts have been generalized and reflected in the layer hierarchy of an AMP system. The results are twofold. First, the systems should be analysed to reflect the distinct hierarchies of an AMP system. This will reveal resource control and access violations. Furthermore, the findings enable the ability to define requirements for protection architectures such as multi-layered systems.

5

Risk Treatment

Exploitation Prevention and Mitigation Concepts

Contents

5.1 Risk Treatment Strategy . . . 146

5.1.1 Target and Residual Attack Potential . . . 147