Устранение ошибок безопасности в «Написание безопасного кода»

Question

Я изучаю безопасность кода и пытаюсь выполнить анализ безопасности на следующих 2 фрагментах, взятых из «Написание безопасного кода», 2-е издание:

http://www.di.uniba.it/~ndm/corsi/sa/materiale/lab/StackOverrun.c

http://www.di.uniba.it/~ndm/corsi/sa/materiale/lab/FormatString.c

В первом я думаю, что единственным небезопасным утверждением является strcpy(buf, input);, которое должно быть strncpy(buf, input, sizeof(buf-1)); Все остальные printf безопасны: даже если они используют меньше аргументов, чем они говорят, ониделают это специально.

Во втором снова printf безопасны, но fprintf(stdout, buf); нет и должны быть заменены следующим кодом: fprintf(stdout, "%s", buf);

Моя проблемаявляется то, что pFile = fopen(argv[1], "r"); также считается небезопасным программами анализа из-за возможного состояния гонки, но я не вижу способа, которым это может быть использовано в этом коде.Если файл открывается только для чтения, может ли злоумышленник сделать с ним что-нибудь неприятное?Я думаю, что нет.

Итак, вопрос в том, считаете ли вы этот анализ правильным?Можете ли вы найти другие недостатки или мои рассуждения прослушиваются?

Спасибо!

Answer 1

С сайта Apple Development приходит это четкое описание:

если вы открываете файл и затем читаете из него, даже если ваше приложение ничего не делало между этими двумя операциями, какой-то другой процесс может изменить файл после открытия файла и до его чтения. Если бы два разных процесса (в одном и том же или разных приложениях) выполняли запись в один и тот же файл, не было бы никакой возможности узнать, какой из них будет записан первым, а какой перезапишет данные, записанные другим. Такие ситуации вызывают уязвимости в безопасности.

Существует два основных типа состояния гонки: время проверки - время использования (TOCTOU) и обработка сигнала.

Кроме того, вызов fopen (), как показано , не выполняет никакой очистки файла . Конечно, ты бы не стал этого делать, верно? Имя обязательно должно быть проанализировано, проверено, и просто нельзя доверять , так как это аргумент для программы. В идеале вы должны использовать более одного атрибута для идентификации файла

Answer 2

Моей первой мыслью было, что неправильно передавать необработанный программный ввод в вызовы libc.Было слишком много случаев переполнения libc, и разработчики не должны передавать аргументы, которые превышают ожидания libc (например, строка должна быть

Но так как вы упомянули условие гонки, ядумаю, что, хотя в данном конкретном случае особой проблемы нет, использование fopen () в целом не одобряется, так как оно подвержено условиям гонки.Если вы обращаетесь к файлу, к любому файлу, используя функции, которые принимают имя файла, а не его дескрипторы.Если вы ссылаетесь на файл по его пути, с помощью одной или другой операции, состояние файла может измениться, и предположение программы об этом состоянии может оказаться неправильным.Это лучше объяснить в следующих статьях.

http://www.sans.edu/research/security-laboratory/article/race-cndtns

http://www.unixprogramming.info/s_isregfile-race-conditions