Аудит безопасности системного кода — бесплатный тест онлайн

Вопрос 1 из 30

С чего начать аудит демона, который принимает файлы по сети и запускает внешнюю утилиту?

network_bytes -> parse_archive -> write_path -> exec_helper

С переименования локальных переменных С карты границ доверия, прав процесса и пути данных от сети до файлов и `exec` С поиска всех вызовов `strcpy`, не рассматривая поток данных С удаления комментариев из исходных файлов С оптимизации самых длинных циклов

Вопрос 2 из 30

Какие активы особенно важны у привилегированного сервиса обработки архивов?

uid=0; input=network; output=/var/lib/service;

Права на файлы, секреты процесса и безопасность создаваемых путей Имя функции `main` и порядок локальных переменных Доступное процессорное время и число рабочих потоков Формат и цвет строк диагностического журнала Объём исходного кода и число подключённых заголовков

Вопрос 3 из 30

Почему данные от авторизованного пользователя всё равно считают недоверенными?

if(authenticated(user)) parse_untrusted(upload,upload_len);

Учётная запись может быть злонамеренной или взломанной, а клиент — прислать ошибочные данные TLS повреждает все переданные байты Любая авторизация обязательно перестаёт работать после первого запроса Авторизованные пользователи технически не могут отправлять файлы Язык C не поддерживает проверку учётных записей

Вопрос 4 из 30

Что приоритетнее: редкая авария в недостижимом тестовом коде или переполнение длины в сетевом пути до аутентификации?

Всегда редкая авария в тестовом коде Оба дефекта равны без анализа достижимости и ущерба Тестовый код по определению опаснее рабочего сетевого пути Приоритет определяется только числом строк функции Удалённо достижимое переполнение до аутентификации

Вопрос 5 из 30

Какие входы должны войти в модель угроз парсера сложного формата?

len=UINT32_MAX; depth=MAX_DEPTH; fields=MAX_FIELDS;

Предельные длины и глубина, повторы, усечение, NUL и структурно допустимые дорогие сочетания Пустой файл и документ без обязательных полей как единственные отрицательные случаи Набор корректных документов среднего размера, повторяющий примеры документации Документы, созданные текущей версией программы, без старых и враждебных вариантов Поток случайных байтов без генерации почти корректных структур

Вопрос 6 из 30

Какой дефект безопасности возникает при таком преобразовании недоверенной длины перед выделением памяти?

size_t bytes = count * sizeof(struct item);
struct item *p = malloc(bytes);
if (!p) return ERR_OOM;
for (size_t i = 0; i < count; ++i) read_item(&p[i]);

Проблема исчезнет, если `count` сделать знаковым: отрицательные значения автоматически отвергаются Умножение безопасно, потому что `sizeof(struct item)` вычисляется во время компиляции Цикл не может выйти за блок, поскольку условие `i < count` совпадает с числом запрошенных элементов `count * sizeof(struct item)` может переполниться и привести к выделению слишком маленького буфера `malloc` получает исходный `count` из метаданных и сам повторяет проверку произведения

Вопрос 7 из 30

Почему обнуление указателя в одной переменной не исправляет обращение после освобождения памяти через другие алиасы?

char *a=malloc(16);
char *b=a;
free(a); a=NULL;
use(b);

Стандарт C запрещает создавать несколько указателей на один динамический объект Присваивание `NULL` одному указателю распространяется на все копии того же адреса Другие копии адреса остаются прежними и могут быть разыменованы Опасны только глобальные копии адреса; локальный `b` автоматически становится недействительным и нулевым `free` меняет сохранённые значения всех указателей на освобождённый блок

Вопрос 8 из 30

Где в этом фрагменте происходит двойное освобождение?

buf=malloc(n);
if(parse(buf)<0){ free(buf); goto cleanup; }
...
cleanup: free(buf);

Ветка ошибки освобождает `buf`, а общий `cleanup` освобождает тот же адрес повторно Оператор `return` гарантированно пропускает метку `cleanup` Общий блок `cleanup` выполняется ровно один раз, поэтому ошибки нет Проблема в том, что `malloc` вызван только один раз Двойной вызов `free(NULL)` в двух ветках

Вопрос 9 из 30

Почему результат `realloc(p, n)` нельзя сразу присваивать обратно в `p`?

p = realloc(p, n);
if (!p) return ERR;

После успешного `realloc` нужно дважды освобождать старый адрес Исходный указатель обязан быть объявлен `const` `realloc` всегда перемещает блок, даже если места достаточно `realloc` не принимает новый размер При отказе старый блок остаётся жив, а прямое присваивание теряет его адрес

Вопрос 10 из 30

Какой риск создаёт поверхностная копия структуры с владеющим указателем?

struct packet b=a; /* a.data и b.data совпадают */

Размер второй структуры увеличивается на размер динамического блока, на который указывает поле Две копии разделяют один блок и могут совместно менять или дважды освободить его Присваивание структуры выполняет глубокое копирование, но забывает скопировать длину блока При присваивании поле-указатель преобразуется во встроенный массив внутри каждой копии структуры Обычное присваивание структуры запрещено, если хотя бы один её член имеет указательный тип

Вопрос 11 из 30

Почему проверка существования файла через `access()` перед `open()` создаёт уязвимость?

Функция `access` устарела и удалена из POSIX.1-2008, поэтому код не компилируется Между вызовами `access` и `open` атакующий может подменить путь другим объектом Проблема возникает только при отсутствии суперпользовательских привилегий Ядро кэширует результат `access`, поэтому `open` всегда получает устаревшие права Оба вызова используют одинаковые права и успех `access` всегда гарантирует успех `open`

Вопрос 12 из 30

Как встроенный NUL создаёт расхождение между проверкой и использованием данных?

/* bytes: "safe.txt\0../secret" */
validate_bytes(buf,n);
open(buf,O_RDONLY);

Проверка с длиной видит весь массив, а строковый вызов — только префикс до NUL Системный вызов удаляет файл, если внутри пути встречается нулевой байт `strlen` возвращает длину всего массива, включая хвост после первого NUL Встроенный NUL влияет только на UTF-16; для байтовой строки он передаётся как обычный символ Нулевой байт считается пробелом как при проверке, так и в системном вызове

Вопрос 13 из 30

Что означает полное потребление поля парсером?

Входной буфер заполнен до всей вместимости Парсер прочитал только первый символ поля Парсер вызвал `free` после чтения После значения нет неожиданных байтов или токенов `strlen` равен размеру выделенного буфера

Вопрос 14 из 30

Когда нормализовать путь относительно проверки доступа и открытия объекта?

Проверять путь только после закрытия файла Сначала передать путь оболочке Вообще не проверять доступ к пути Нормализовать и проверять тот же объект, который будет открыт Проверить сырой путь, затем изменить его и открыть уже другой объект

Вопрос 15 из 30

Почему лимит вложенности нужен даже для формально корректного ввода?

if(depth >= MAX_DEPTH) return ERR_NESTING;

Глубокая допустимая структура исчерпает стек или время `malloc` сам ограничивает глубину разбора Любая грамматика запрещает рекурсию Лимит глубины меняет порядок байтов Вложенность бывает только в JSON

Вопрос 16 из 30

Как исправить переполнение при записи имени в `char name[64]`?

int set_name(obj *o, const char *s, size_t n) {
    memcpy(o->name, s, n);
    o->name[n] = '\0';
    return 0;
}

Объявить массив `volatile`, чтобы компилятор не удалил проверку границы Перехватывать `SIGSEGV` и считать его признаком слишком длинного имени Принять длину, проверить вместимость и задать поведение превышения Увеличить массив и сохранить `strcpy`: большой фиксированный запас устраняет необходимость в контракте Добавить задержку, чтобы копирование завершалось до возможного изменения источника

Вопрос 17 из 30

В каком состоянии должен остаться объект, если обновление третьего поля не удалось?

Скрыть код ошибки от вызывающего кода Сохранить прежнее состояние либо полностью инвалидировать объект Оставить часть новых полей без отметки об ошибке Повторять обновление бесконечно Освободить только первое поле объекта

Вопрос 18 из 30

Почему подавление предупреждения явным приведением типа не является исправлением?

size_t n=read_len();
int m=(int)n; /* warning подавили, диапазон не проверили */

Любые явные приведения запрещены стандартом Приведение скрывает предупреждение, но ничего не доказывает Компилятор полностью игнорирует оператор приведения Предупреждения не связаны с реальными дефектами Приведение всегда превращает значение в ноль

Вопрос 19 из 30

Как безопасно исправить обращение после освобождения памяти в асинхронной функции обратного вызова?

Освобождать объект после фиксированной задержки, рассчитанной по среднему времени выполнения обработчика Передавать обработчику копию адреса и освобождать исходный объект сразу после постановки задачи в очередь Отменить регистрацию обратного вызова и дождаться его завершения либо ввести явное совместное владение объектом Публиковать адрес через `volatile`-указатель, сохранив прежний порядок освобождения Проверять адрес на `NULL` непосредственно перед доступом, не синхронизируя время жизни объекта

Вопрос 20 из 30

Что проверить после исправления ошибки расчёта размера?

Одну сборку Windows как замену проверке других моделей данных и компиляторов Повтор исходного сценария после увеличения размера буфера Сравнение времени работы до и после исправления без проверки результата Границу и соседние размеры, арифметическое переполнение, отказ памяти, санитайзеры и соответствие формату Успешную компиляцию патча без предупреждений в одной конфигурации

Вопрос 21 из 30

Почему фаззер без санитайзера пропускает часть ошибок памяти?

clang -fsanitize=fuzzer parser.c -o fuzz_parser

Фаззер вообще не выполняет исследуемый код Санитайзер сам генерирует все входные данные Фаззинг поддерживает только C++ Операционная система предотвращает любые ошибки памяти Санитайзер проявляет ошибку, которая могла не вызвать аварию

Вопрос 22 из 30

Что на самом деле означает 100% покрытия строк?

Покрыты строки, но не все значения, ветви и состояния Все требования проверены: покрытие исходника эквивалентно покрытию спецификации Все ошибки памяти найдены, поскольку опасная операция обязательно находится на отдельной строке Дальнейший фаззинг не даст новых путей, если строковое покрытие достигло 100% Все свойства безопасности доказаны, если каждая строка была выполнена хотя бы один раз

Вопрос 23 из 30

Какой вход нужно добавить в корпус тестов после находки фаззера?

Минимизированный вход и соседние варианты как регрессионный тест Добавить несколько других входов той же длины, не сохраняя конкретный файл, который вызвал сбой Заменить находку пустым файлом, если обработчик поддерживает вход нулевой длины Сохранить исходный крупный вход без минимизации: так регрессионный тест воспроизведёт весь контекст обнаружения Удалить вход после исправления и оставить только описание причины в журнале изменений

Вопрос 24 из 30

Почему статический анализ и AddressSanitizer дополняют друг друга?

Статический анализ запускает готовый эксплойт ASan проверяет только стиль исходного кода Оба инструмента выполняют одну и ту же проверку Оба инструмента лишь компилируют программу Анализатор видит пути, ASan точно указывает выполненную ошибку

Вопрос 25 из 30

Какой режим компиляции полезен для проверки безопасности до фаззинга?

cc -std=c17 -Wall -Wextra -Wconversion -Wformat=2 \
  -fsanitize=address,undefined -fstack-protector-strong -g ...

`-DNDEBUG`: убрать утверждения и ручные проверки до запуска фаззера Строгие предупреждения, санитайзеры, защита платформы и символы `-E`: ограничиться препроцессированным текстом и не выполнять типовую проверку `-s`: удалить символы, чтобы отчёты не раскрывали внутреннюю структуру программы `-w -O3`: отключить предупреждения и проверять только выпускную оптимизацию

Вопрос 26 из 30

Почему парсер недоверенного формата полезно запускать с минимальными правами?

Минимальные права делают сам язык C безопасным Ограничение прав исправляет переполнение буфера Права влияют только на файл журнала Парсер обязательно станет быстрее Права процесса ограничат доступ к файлам, сети и вызовам

Вопрос 27 из 30

Что означает защита в глубину применительно к переполнению буфера?

Только один защитный маркер стека без проверки размера Сокрытие исходного кода от пользователя Исправление причины, тесты, защита бинарника, изоляция и минимальные права Увеличение буфера без изменения расчёта длины Две одинаковые проверки условия подряд

Вопрос 28 из 30

Как ограничить вход, похожий на архивную бомбу?

if(total_out>MAX_TOTAL || files>MAX_FILES || depth>MAX_DEPTH) abort_unpack();

Проверить размер сжатого файла: он однозначно ограничивает объём распакованных данных Лимиты объёма, числа файлов, глубины, времени и диска Игнорировать имена файлов: ресурсная атака зависит только от путей извлечения Запустить процесс с правами root, чтобы ограничения диска и числа файлов не мешали Выделить больше памяти перед распаковкой и не прерывать операцию при превышении ожиданий

Вопрос 29 из 30

Почему внешнюю утилиту безопаснее запускать с фиксированным `argv` и очищенным окружением?

char *const argv[]={"helper","--input",path,NULL};
char *const envp[]={"PATH=/usr/bin",NULL};
execve("/usr/libexec/helper",argv,envp);

`execve` автоматически выдаёт права `root` Массив `argv` шифрует все строки Не использовать оболочку и сократить влияние PATH и окружения Окружение вообще не передаётся дочерним процессам Чтобы утилита увидела меньше аргументов

Вопрос 30 из 30

Какой интерфейс уменьшает поверхность атаки библиотеки парсинга?

Использовать один глобальный буфер без поля длины, чтобы сократить число параметров Разрешить библиотеке открывать произвольный путь с полномочиями процесса Малый API с явной длиной, лимитами и единым освобождением Скрыть вычисление размера в макросе, который может вычислить аргумент несколько раз Открыть внутренние структуры, чтобы вызывающий мог исправлять состояние парсера напрямую