Я понимаю, что этот сегмент кода должен иметь проблемы уязвимости переполнения буфера:Printf и% s в C
printf("File %s", my_file_name);
printf("File %s");
Однако, я не получаю, почему именно это считается рискованным. Кто-нибудь сможет пролить свет на это?
Приведенные ниже код выводит содержимое my_file_name на стандартный вывод:
printf("File %s", my_file_name);
Если my_file_name получен от вредоносного источника и программных выходов на терминал, то возможно для вредоносного источника поставило escape-последовательностей в my_file_name, которые говорят терминалу о выполнении нетривиальных задач, таких как отправка содержимого терминала через стандартный ввод. Трудно, но возможно, что злоумышленник может извлечь полезную информацию из такой атаки или даже попытаться испортить данные с помощью команд, как если бы они были введены пользователем.
Конечно, второй вызов вызывает неопределенное поведение, поскольку вы не передаете действительный указатель строки как второй аргумент printf.
Вышеупомянутый сценарий, вероятно, не является тем, о чем вы ссылаетесь уязвимость переполнения буфера. Нет такой уязвимости в коде printf, но это недостаток переполнения буфера существует где-то еще в вашем коде, и фактическая строка формата может быть исправлена через это переполнение, злоумышленник может воспользоваться возможностями printf, особенно %n, чтобы вывести любое значение почти в любое место в памяти программы. Это является обоснованием для удаления %n в printf_s, как показано в документе безопасности Microsoft.
Спасибо! Это очищает его. –
Ну, это не «уязвимость переполнения буфера». Он также будет работать только для конкретных терминалов и операционных систем, а также для вывода, который действительно подходит к терминалу. Типичные сервисы, такие как ftp, http-серверы, обычно перенаправляются на stdout. Интерактивные программы, otoh, ususlly имеют пользователя, сидящего на терминале в любом случае, поэтому никакой выгоды. Маловероятный сценарий. У вас есть пример? –
Питер, я не был уверен, когда сказал, что проблема с переполнением буфера. Это было только мое рудиментарное понимание. Независимо от того, все еще так, я понятия не имею. Но этот ответ объясняет уязвимость безопасности довольно красиво. (Edit: Я вижу, что это было отредактировано в ответ.) –
Первый звонок в порядке. (Проблемы существуют, когда вы используете строку формата, предоставленную пользователем, как в printf(s), где s находится под воздействием пользователя. Здесь вы используете стробированную строку формата "File %s", которая не является уязвимой. Содержимое строки my_file_name будет обрабатывается как обычная строка C и просто копируется на стандартный вывод. Конечно, он должен быть завершен нулем, и если выход перенаправляется на что-то другое, там могут быть побочные эффекты, но это не проблема с печатью.)
Второй вызов - это просто неопределенное поведение, потому что количество параметров после строки формата (0) не соответствует числу, которое требует строка формата (1).
Что вы опубликовали здесь, проблема с нехваткой буфера. Вы скажете printf, что в стеке есть строка, но не дайте ее. Если my_file_name указывает на большее количество данных, чем пространство, выделенное для него, это не является проблемой переполнения буфера –
Это кажется хорошим ответом: http://security.stackexchange.com/questions/43574/how-is-printf-in -cca-buffer-overflow-уязвимость –
Mmm .. ответ printf есть уязвимость строки формата, а не переполнение буфера @crclayton –