Control-flow integrity

Для прямых переходов допустимые адреса ограничены набором функций программы. С учётом системы типов и семантики языка программирования это множество может быть дополнительно сокращено^[16]. Например, в C++ по стандарту корректный указатель на функцию, используемый при косвенном вызове, обязан содержать адрес функции с совместимым типом^[17].

Методы реализации control-flow integrity для прямых переходов основаны на выделении множества легальных адресов для каждой косвенной инструкции^[1]. Для этого используется статический анализ кода на различных уровнях: исходный, внутреннее представление или машинный^[1][10]. На основании анализа, к инструкциям косвенного перехода добавляется проверочный код — он сравнивает вычисленный во время исполнения адрес с предвычисленным набором. При расхождении выполнение или аварийно прерывается, или обрабатывается по заданной политике^[18][19]. В результате граф потока управления ограничивается только разрешёнными рёбрами и вершинами^[1][16][20], поэтому попытка подмены указателя в целях атаки становится безуспешной.

Такой подход эффективно блокирует техники возвратно-ориентированного программирования на прямых переходах: jump-oriented programming^[21] и call-oriented programming^[22].

Для обратных переходов применяются различные методики^[8].

Один из подходов аналогичен методу для прямых переходов — статически вычисляются допустимые адреса возврата^[23].

Во втором подходе к адресу возврата применяется особая обработка: кроме сохранения в стек, он дополнительно помещается (в возможно изменённом виде) в специальную область памяти или, например, в регистр процессора; перед возвратом производится сравнение оригинала и копии^[8].

Третий способ требует аппаратной поддержки и использует так называемый «теневой стек» — особую, непривилегированную область памяти для сохранения адресов возврата при вызовах^[24].

Методы control-flow integrity для обратных переходов позволяют блокировать атаки возврата в библиотеку и возвратно-ориентированное программирование путём контроля адреса возврата на стеке^[23].

Indirect Function Call Checking (IFCC) обеспечивает контроль косвенных переходов в программе (за исключением некоторых особых, например, вызова виртуальных функций). При построении допустимых адресов учитывается тип функции, что препятствует не только выполнению перехода за пределы функций, но и некорректному приведению типов в коде. Для включения проверки в Clang используется опция -fsanitize=cfi-icall^[4].

// clang-ifcc.c
#include <stdio.h>

int sum(int x, int y) {
  return x + y;
}

int dbl(int x) {
  return x + x;
}

void call_fn(int (*fn)(int)) {
  printf("Result value: %d\n", (*fn)(42));
}

void erase_type(void *fn) {
  // Поведение не определено, если динамический тип fn не совпадает с int (*)(int).
  call_fn(fn);
}

int main() {
  // При вызове erase_type теряется статическая информация от типе.
  erase_type(sum);
  return 0;
}

Компиляция без проверок позволяет программе работать без ошибок, но результат неопределён и может различаться между запусками:

$ clang -Wall -Wextra clang-ifcc.c
$ ./a.out
Result value: 1388327490

С применённой опцией, контроль приводит к аварийному завершению исполнения при вызове call_fn:

$ clang -flto -fvisibility=hidden -fsanitize=cfi -fno-sanitize-trap=all clang-ifcc.c
$ ./a.out
clang-ifcc.c:12:32: runtime error: control flow integrity check for type 'int (int)' failed during indirect function call
(./a.out+0x427a20): note: (unknown) defined here

Этот метод контролирует интегритет виртуальных вызовов в C++. Для каждой иерархии классов с виртуальными функциями строятся битовые маски, отражающие допустимые функции по каждому статическому типу. Модификация таблицы виртуальных функций (например, при неправильном приведении типа либо ошибке памяти) приводит к невозможности совпадения динамического типа с предсказанными значениями^[10][25].

// virtual-calls.cpp
#include <cstdio>

struct B {
  virtual void foo() = 0;
  virtual ~B() {}
};

struct D : public B {
  void foo() override {
    printf("Right function\n");
  }
};

struct Bad : public B {
  void foo() override {
    printf("Wrong function\n");
  }
};

int main() {
  Bad bad;                          // Стандарт C++ позволяет делать приведение типов по следующей схеме:
  B &b = static_cast<B&>(bad);      // Derived1 -> Base -> Derived2.
  D &normal = static_cast<D&>(b);   // В результате динамический тип объекта normal
  normal.foo();                     // будет bad и вызовется неправильная функция.
  return 0;
}

Компиляция без проверок:

$ clang++ -std=c++11 virtual-calls.cpp
$ ./a.out
Wrong function

В данном случае вместо метода foo класса D вызывается foo из класса Bad. Активированный контроль с помощью -fsanitize=cfi-vcall предотвращает ошибку:

$ clang++ -std=c++11 -Wall -flto -fvisibility=hidden -fsanitize=cfi-vcall -fno-sanitize-trap=all virtual-calls.cpp
$ ./a.out
virtual-calls.cpp:24:3: runtime error: control flow integrity check for type 'D' failed during virtual call (vtable address 0x000000431ce0)
0x000000431ce0: note: vtable is of type 'Bad'
 00 00 00 00  30 a2 42 00 00 00 00 00  e0 a1 42 00 00 00 00 00  60 a2 42 00 00 00 00 00  00 00 00 00
              ^