Software diversification is changing the structure and internal interfaces of a program in order to generate unique diversified versions of this program. Unique instances of the software are distributed among the users. These in- stances are all functionally the same, but differently diversified. This means that diversification breaks the monoculture software distribution model and introduces multiculturalism in software deployment process. The security benefit of the multicultural software deployment model is impeding the risk of large-scale attacks. Even supposing that the attacker manages to crack one instance of the software and utilize some non-public internal interface, on account of the fact that software instances are unique, the attacker cannot access other instance. In other words, the attack model must be designed individually for each particular software instance and the same attack model does not work on all software instances. Therefore, diversification is a very
Figure 2.4: Software diversification
effective technique for securing largely distributed systems and also the sys- tems in the current era of operating system and interface monoculture. Fig- ure 2.4 shows the unique design and distribution of the diversified software instances, and how diversification thwarts the risk of large-scale attack.
In order to access the resources of a system, interfaces are used. Di- versification alters the internal interface(s) to secret ones. Diversifying the internal interfaces of the software creates a unique secret that is propagated only between the legal ”clients” of the interface (i.e., they are also diversified to be compatible with inner layers), to maintain their communication be- tween each other. The diversification secret is kept private from illegitimate parties to prevent their access to the diversified resources.
Interface diversification introduces proactive protection against malware, especially when it is applied throughout all the interface layers. Malware (malicious software) is a piece of software that is designed to run its code on a user’s computer to disrupt its operation or manipulate the system in the way that the attacker desires [55]. To do this, malware needs to gain knowl- edge on the system, its environment, and how to interact with it and access its resources. Software diversification modifies the internal interfaces of the software and makes it challenging for the malware to get such knowledge. Consequently, the malware code becomes incompatible with the system’s environment and when not able to interact with it, it becomes ineffective. To achieve this, many different diversification techniques have been pro- posed that each target various parts in software layer. Depending on the need of the system, different diversification mechanisms could be employed. Diversification mechanisms could be as simple as name changing or a more complex technique such as system call diversification.
from the operating system kernel. System calls as part of overflow attacks could be misused by a malware to access the operating system and carry out its malicious intend. Diversification of the system calls could conceal their interface and make them inaccessible by the malware. Symbol diver- sification [39] diversifies the indirect library entry points to the system calls by renaming the symbols in Linux binaries. This makes it difficult for the malware to use these entry points and system’s resources, because it does not know the diversification secret (the function that relates the original and new symbol names). Liang et al. [42] propose a system call randomization approach to counter code injection attacks. This type of attacks uses system calls to inject code. By randomizing these system calls, the attacker who does not know the randomization algorithm key, will inject a code that is not randomized in the same way that the target process has been randomized, so it is not valid for the de-randomized module. Thus, the injected code fails to execute without correctly calling the system calls. Address Space Layout Randomization (ASLR) [44] is another practical and effective diver- sification technique that protects the operating system from buffer overflow by randomizing the location of the executables in the memory [35]. This, randomizes and reshuffles the address space locations of a process (the base of the executable, heap, stack, and library position). Here, the memory could be seen as an interface that after diversifying it, the attacks that rely on the known layout structure are prevented.
Software diversification has many parallels with code obfuscation. Whilst the main goal of these two software security approaches are different, many of the techniques developed for software obfuscation can be parameterized for software diversification purposes. This means that obfuscation could be applied to generate diversified versions of the code, and obfuscation could be applied to make diversified software less understandable and distinguished from equivalent versions. These two techniques do not aim to eliminate software vulnerabilities, but make it difficult for an attacker to exploit these vulnerabilities and conduct a successful attack. In the literature, there exist a wide range of studies on applying these two techniques for securing various execution environments [32] such as cloud computing [37, 50], IoT [29, 30], mobile and embedded systems. The studies show that the two techniques have been successful in mitigating the risk of a wide range of attacks [32] including buffer overflow, injection attacks, Return-Oriented Programming (ROP) attacks, and JIT spraying attacks. Diversification and obfuscation could be applied on different parts of software at different phases of develop- ment process: design and implementation, compilation and linking, loading, installation and update, and execution. The most common phase is compile time (i.e., at the time the program is compiled and linked) [33].
It is worthwhile discussing here how obfuscation and diversification differ from security through obscurity. Security through obscurity protects the
code/secret/asset by concealing it. This means that the asset is safe until it is not discovered. When it is discovered, it is no longer safe, and the system is vulnerable. This is while that obfuscation does not try to hide the program but instead secures the program, even in the case that the source code or the binary code of the program is revealed. This means that even if the attacker gets access to the code, he/she cannot read/understand it, because it is obfuscated in a way that the attacker does not know. For instance, in source code obfuscation the code is not hidden but it is obfuscated in a way that it is difficult to comprehend and reverse engineer.
Diversification removes the knowledge necessary to interact with the environment and access the resources, i.e., the previously publicly known interfaces towards the system resources are removed, and thus, the system is hardened. For instance, in symbol diversification [39] the indirect library entry points to the system calls are renamed. This means that the old names are not hidden, but they do not exist anymore.
Therefore, security through obscurity could be valuable to add a valid layer of security, but it cannot be a sufficient and strong security mechanisms by itself and cannot substitute the security for secrecy.