Code Reuse Attacks

What it is

Code reuse attacks allow the adversary to make malicious results by exploiting the control flow of existing program without any additional code injection.

In a code-reuse attack, the attacker combines existing code fragments (called gadgets) to achieve arbitrary computation. While code-resue attacks are Turing complete, they are generally used to disable code integrity and to allow an attacker to execute injected code. 

Return Oriented Programming (ROP)

Code reuse attacks allow attackers to execute arbitrary code on a compromised machine.

In this, the attacker directs the control flow through existing code without injecting new executable code.

Using ROP, the attackers can link small pieces of code which is known as gadgets, that already exist in the binary image of a vulnerable application.

In fact, the ROP gadgets are short sequence of code, typically ending with a return or indirect control transfer instruction. Instead of injecting binary code into the memory space of an application, the attacker can use a sequence of gadget in the stack or other memory of the program.

Each gadget ends with an indirect control transfer instruction, which transfers the control of next gadget according to the injected gadget sequence.

Existing defender lose effects

During the attack, the adversary can circumvent many defenses such as 
  • Read-only memory
  • Non-executable meomry
  • Kernel-code integrity protections

Since the injected part is only data (rather than code). In addition, access to ROP exploits is not difficult since they are provided in the publicly available packs. 

Most of existing defense mechanisms cannot defend code reuse attacks, such as
  • Instruction Set Randomization
  • Simple Address Space Layout Randomization (ASLR)
  • Stack canaries (Ref [25] in [3])

How to defense

Instruction Location Randomization

Software Diversity

  • By randomizing a binary’s code layout, a memory vulnerability is moved to a priori unknown location in the binary, thereby bring down the probability of return-to-libc and return-oriented attacks. [2]
    • [2] proposes an approach to recompile the code during execution with Java JIT compiler.

[1] Enhancing Software Dependability and Security with Hardware Supported Instruction Address Space Randomization, by Weidong Shi, in DSN15
[2] Adaptive Just-in-Time Code Diversification, by Abhinav Jangda, in MTD15
[3] An Evil Copy: How the Loader Betrays you 

How to come up with new ideas in security domain

The followings are my own experience in finding research ideas in security domain.

Ideas from Security Threat

  • What the defenders can do to improve security?
    • How to detect attackers?
    • How to defend against attackers?

For the cloud computing problem, the defenders can be further divided into two categories: (1) Cloud provider (2) Cloud benign users

    • What the attackers can do to increase damage?

    Ideas from Existing Work

    • Improve
      • Scalability of their mechanism
    • Combine
      • Can we combine other mechanisms with their mechanism
    • New Problem
      • Can we use the proposed mechanism to solve a different problem
    • New Mechanism
      • Can we solve the problem with a better mechanism

    Latin Square

    What it is

    • An n*n array filled with n different symbols, each occurring exactly once in each row and exactly once in each column. 

    What property does it have

    What’s the application in security

    • use for image cipher


    Split Keys to Multiple Machines

    The objective of this post is to discuss the feasibility of splitting credentials into multiple machines.

    Why to Split Key

    • The motivation is to enhance the difficulty for the attackers to steal the key. The attackers would need to compromise several machines together 

    How to Split Key

    • [2] RSA

    Feasibility of Splitting Key to Protect Security

    • Though the secrets are separated, the rebuilding process must occur, by necessity, on a single machine which obtains, at some point, the secret itself. In particular, if you do the reassembly on a machine which is evil (i.e., which is under the control of an attacker through some malware), then the attacker learns the SSH private key. [1]


    • It is not feasible to defense covert channel attack through splitting credentials to multiple machines. 


    Cloud Covert Channel Attack

    What it is

    Co-residence threats in Cloud 

    In current commercial cloud, cloud providers allow multiple users to share the physical machine rather than assigning a dedicated machine to every user. Although in theory, VMs running on the same server (i.e., ci-resident VMs) should be logically isolated from each other, malicious users can still circumvent the logical isolation, and obtain sensitive information from co-resident VMs [6].

    A malicious virtual machine (VM) can extract fine-grained information from a victim VM running on the same physical machine.

    Thus malicious users can try to co-locate their VMs with target VMs on the same physical server, and then exploit side channels to extract private information from the victim [5].


    • Access Driven
      • The attackers program monitors usage of a shared architectural component to learn information about the key, e.g., the data cache, instruction cache, floating-point multiplier, or branch-prediction cache.
      • The attackers could be asynchronous, meaning that they do not require the attacker to achieve precisely timed observations of the victim by actively triggering the victim operation. 


    • Zhang et al. [1] demonstrate a VM can extract a private ElGamal decryption key from a co-resident victim VM running Gnu Privacy Guard (GnuPG), which is a popular software package that implements the OpenPGP email encryption standard.
    • By overloading the CPU while a victim AES encryption process is running. They managed to gain control over the CPU and suspend the AES process thereby gaining an opportunity to monitor cache access of the victim process.

    Threats Of Covert Channel Attacks

      How it works

      The first step for the attackers is to try to achieve co-residence with the target VMs, and then conduct covert channel attacks by exploiting shared microarchitectural components such as caches.

      How to achieve co-residence

      • The most straightforward approach is to use a brute-force strategy, start as many VMs as possible until co-residence is achieved.
      • [7][8] investigate how to efficiency achieve co-residency.

      Approach 1: PRIME + PROBE method 

      • Step 1: 
        • Attackers create one or more eviction sets. An eviction set is a sequence of memory addresses that are all mapped by the CPU into the same cache set. 
        • The PRIME+PROBE method also assumes that the victim code uses this cache set for its own code or data.
      • Step 2:
        • The attackers prime the cache set by accessing the eviction set in an appropriate way.
        • This force the eviction of the victim’s data or instructions from the cache set and brings it to a known state.
      • Step 3:
        • The attackers trigger the victim process, or passively waits for it to execute. 
        • During this execution step, the victim may potentially utilize the cashe and evict some of the attacker’s elements from the cache set.
      • Step 4:
        • The attacker probes the cache set by accessing the eviction set again.
        • A probe step with a low access latency suggests that the attacker’s eviction set is still in the cache.
        • Conversely, a higher access latency suggests that the victim’s code made use of the cashe set and evicted some of the attacker’s memory elements.
        • The attackers thus learns about the victim’s internal state. 
        • The actual timing measurement is carried out by using the (unpriviledged) instruction rdtsc, which provides a hide-fidelity measurement of the CPU cycle count.
        • Iterating over the eviction set in the probing phase forces the cache set yet again into an attacker-controlled state, thus preparing for the next round of measurement.

      How to defense against it

      Several countermeasures have been proposed at different levels: hypervisor, guest OS, hardware and application-layer approaches.

      1. Eliminating the side channels

      • Hypervisor-based approach.
          • Modify the Xen scheduler to limit the frequency in which an attacker can preempt the victim.
          • Locking cache lines to prevent preemption by an attacker and multiplexing the cache lines among VMs such that each has an access to its own.
          • Remove high resolution clock
            • Note the side-channels attacks relies on it
          • Add noise/latency
            • Periodic time-shared cache cleasing, in order to make the side channel noisy.
            • Hide the program execution time
            • Alter the timing exposed to an external observer.
              • e.g., add latency
            • Statistical multiplexing of shared resources to prevent eavesdropping.
        • Guest OS
          • Injecting noise into protected processes on L1 and L2 caches.
          • Hardware
            • Hardware design incorporates access randomization and resource partitioning.
              • e.g., avoid sharing of sensitive resources
            • Remove hypervisor, and use hardware mechanisms for the isolation of access to shared resources
          • These methods often require substantial changes to be made to existing cloud platforms, and hence are unlikely to be adopted by cloud providers any time soon.

            2. Increasing the difficulty of verifying co-residence

            • Existing works show that traceroute tool can be used to decide the IP address of a VM’s Dom0, which is a privileged VM that manages all VMs on a host. If two Dom0 IP addresses are the same, then the corresponding VMs are co-resident.
              • Cloud provider can prevent Dom0’s IP address from being exposed to customers. so that attackers will be forced to resort to other options that do not rely no network measurements.
              • However, as more and more methods of detecting co-residence have been proposed [10-12], simply hiding Dom0’s IP address is not sufficient. [9]

            3. Increasing the difficulty of steal information

            • Application-level
              • Partitioning a cryptographic key across multiple VMs.
                • E.g, divide the secrets using Shamir’s secret

            4. Detecting the features of co-resident attacks

            • When attackers use Prime+Probe technique to extract information from the victim, there are abnormalities in the CPU and RAM utilization, system calls, and cache miss behaviors. [13][14]

            5. Migrating VMs periodically

            • VM migration 
              • This approach is proposed in [4]. 
              • Pros
                • Other approaches are not suitable for immediate deployment due to the required modification to the cloud platforms, while VM migrations can be implemented immediately.

            6. Using VM allocation policies to make it difficult to achieve co-residence

            [1] Cross-VM side channels and their use to extract private keys, CCS 2012
            [2] Wait a Minute! A fast, Cross-VM Attack on AES, in Research in Attacks, Intrusions and Defenses, LCNS 2-14
            [3] The Spy in the Sandbox: Practical Cache Attacks in JavaScript and their Implications, CCS15
            [4] Nomad: Mitigating Arbitrary Cloud Side Channels via Provider-Assisted Migration, CCS15
            [5] Security Games for Virtual Machine Allocation in Cloud Computing, by Yi Han et al., in GameSec15
            [6] Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds, by Restenpart, T. et al., in CCS09
            [7] A Placement Vulnerability Study in Multi-Tenant Public Clouds, by Venkatanathan Varadarajan, in UnixSecurity15
            [8] A Measurement Study on Co-residence Threat inside the Cloud, by Haining Wang, in UnixSecurity
            [9] Using Virtual Machine Allocation Policies to Defend against Co-resident Attacks in Cloud Computing, by Yi Han et al, in Transactions on Dependable and Secure Computing
            [10] Detecting co-residency with Active Traffic Analysis Techniques, by A. Bates, in CCSW12
            [11] Detecting VMs co-residency in Cloud: Using Cached-based Side Channels Attacks, by S. Yu 2013
            [12] On Detecting Co-resident Cloud Instances Using Network Flow Watermarking Techniques, by A. Bates, in International Journal of Information Security, 2014
            [13] Detecting malicious Coresident Virtual Machines Indulging in Load-Based Attacks, by S. Sundareswaran, in Information and Communication Security 2013
            [14] An Approach with Two-stage Mode to Detect Cache-based Side Channel Attacks, by S. Yu, in ICOIN 2013