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], так как последние активно используют прямые косвенные переходы.

Для обратных переходов возможно несколько подходов к реализации CFI[8].

Первый подход основывается на тех же предположениях, что и CFI для прямых переходов, то есть на возможности вычислить адреса возврата из функции[23].

Второй подход заключается в особом обращении с адресом возврата. Помимо того, чтобы просто сохранять его на стек, он сохраняется, возможно с некоторыми модификациями, ещё и в специально выделенное для него место (например, в один из регистров процессора). Также перед инструкцией возврата добавляется код, восстанавливающий адрес возврата и сверяющий его с тем, который лежит на стеке[8].

Третий подход требует дополнительную поддержку от аппаратной части. Совместно с CFI используется теневой стек (англ. shadow stack) — специальная недоступная злоумышленнику область памяти, в которую сохраняются адреса возврата при вызове функций[24].

При реализации схем CFI для обратных переходов возможно предотвратить атаку возврата в библиотеку и возвратно-ориентированное программирование (англ. return-oriented programming), основанные на изменении адреса возврата на стеке[23].

Indirect Function Call Checking (IFCC) включает в себя проверки косвенных переходов в программе за исключением некоторых «особенных» переходов, таких как вызовы виртуальных функций. При построении множества адресов, по которым может произойти переход, учитывается тип функции. Благодаря этому возможно предотвратить не только использование неправильных значений, указывающих не на начало функции, но и неверное приведение типов в исходном коде. Для включения проверок в компиляторе есть опция -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
              ^