SPECTRE.VARIANT1

Potential exploit of speculative execution

Spectre is a hardware vulnerability discovered and published by Google in early 2018 (https://googleprojectzero.blogspot.ca/2018/01/reading-privileged-memory-with-side.htm). The vulnerability results from hardware optimizations aiming at improving CPU performance while it's working with the different memory levels. Although spectre is a hardware vulnerability, for it to be exploited, certain code patterns still should be present in the software that is being run by that hardware. The original Google-published paper is available at https://spectreattack.com/spectre.pdf and shows a number of patterns exposing the vulnerability, as well as a sample program allowing to illegally access the secret data leaked via it. There are different variants of the vulnerability; the variant 1 that is excessively discussed in the original paper is of the main interest for static detection since, unlike other variants, it does not seem to be easily mitigated by general approaches and requires specific code patterns detection in the source. The variant 1 vulnerability allows to leak secret data from the victim's machine RAM via an array out-of-boundary reads. Below is the simplified code snippet demonstrating the high level overview of this vulnerability:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
   struct array {
       unsigned long length;
       unsigned char data[];
   };
    
   struct array *createArrayOfSize(unsigned int size);
    
   void vulnerable_pattern(unsigned long offset)
   {
      struct array *arr1 = createArrayOfSize(5);                  /* small array */
      struct array *arr2 = createArrayOfSize(0x500);              /* a large array */
      unsigned char secret_value;
   
      if (offset < arr1->length) {                                /* untrusted data controls the branch */
          secret_value = arr1->data[offset];                      /* out of boundary read in a mispredicted speculative execution */
   
          unsigned char value2 = arr2->data[secret_value * 256];  /* arr2->data[secret_value * 256] will be loaded to the CPU cache */
                                                                  /* resulting in a measurable side effect */
          /* some more code */
      } else {
          /* code for the else branch */
      }
  }

While no data is still accessible directly to the attacker, as a result of this execution, they leave a side effect in the CPU, i.e., the 'arr2->data[secret_value * 256]' value has been copied into the CPU L1 cache while other elements of 'arr2->data' array are still only available from the next level caches or DRAM (if extra details of hardware memory operations are ignored). To measure this side effect and finish data leaking, the attacker only needs to read the elements of 'arr2->data' one by one (with a step of 256 and yes, it is assumed that they have some convenient ways of doing so) and measure how long each read takes (this is claimed to be something easily achieved; see Timing Attack). All the reads except for the 'arr2->data[secret_value * 256]' will be slow while the read of 'arr2->data[secret_value * 256]' will be fast, and that reveals the value of the 'secret_data'.

The vulnerability can be mitigated by calling a special 'intrinsic' function anywhere in the branch before the access to 'arr2->data[secret_value * 256]' that forces the CPU to wait until all the values requested from the next level caches actually arrive in their registers. Intel compiler provides the function '_mm_lfence()' to achieve this on Intel architectures.

Code example

code.c:17:9: [SPECTRE.VARIANT1] Potentially untrusted data 'offset' can be used to read arbitrary data beyond boundary of array 'arr1->data' at line 15 in speculative branch execution.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
   struct array {
       unsigned long length;
       unsigned char data[];
   };
    
   struct array *createArrayOfSize(unsigned int size);
    
   void vulnerable_pattern(unsigned long offset)
   {
      struct array *arr1 = createArrayOfSize(5);                  /* small array */
      struct array *arr2 = createArrayOfSize(0x500);              /* a large array */
      unsigned char secret_value;
   
      if (offset < arr1->length) {                                /* untrusted data controls the branch */
          _mm_lfence();                                           /* serialization intrinsic that stops speculative execution */
          secret_value = arr1->data[offset];                      /* no vulnerability exists so no defect is reported */
   
          unsigned char value2 = arr2->data[secret_value * 256];  
                                                                  
          /* some more code */
      } else {
          /* code for the else branch */
      }
  }

function_name - FENCE

The above record will be interpreted by the checker that function 'function_name' will cause the CPU to wait until the cache is synchronized with the RAM state or make the data leakage in speculative executive a non-issue in any other way. Analysis along that path will be stopped.

External guidance

• CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
• CWE-1037: Processor Optimization Removal or Modification of Security-critical Code
• OWASP A1:2021 Broken Access Control
• https://googleprojectzero.blogspot.ca/2018/01/reading-privileged-memory-with-side.htm
• https://spectreattack.com/spectre.pdf
• Timing Attack

Security training

Application security training materials provided by Secure Code Warrior.

• Sensitive Data Exposure Training Video - Test your skills with a training example