Небезопасные C функции в среде HP-UX - PullRequest
0 голосов
/ 26 февраля 2020

Мы разрабатываем одно приложение планировщика на языке программирования C. Мы используем среду HP-UX для компиляции и развертывания кода. Во время ежегодного внешнего аудита заявки мы получили один отчет, который содержит следующее количество наблюдений.

  1. Опасные функции: strcpy, strlen, strcat et c.

  2. Переполнение буфера: memcpy

  3. Строка формата переполнения буфера: sprintf, snprintf et c.

  4. Строка формата: printf, sprintf et c.

Они также дают общую рекомендацию - Содержит некоторые безопасные функции:

  1. strncpy_s

  2. strnlen_s

  3. strncat_s

  4. memcpy_s et c ..

Теперь проблема в том, что для среды HP-UX нет такой библиотеки. Указанные выше функции поддерживаются только в среде Windows.

  1. Есть ли какая-либо альтернатива для опасных функций в среде Linux?
  2. Как мы можем уменьшить размер строки переполнения буфера и категорию формата строки?

1 Ответ

1 голос
/ 26 февраля 2020

См. Вы используете «безопасные» функции TR 24731? для обсуждения недостатков функций _s.

Такие функции, как strcpy(), безопасны если (и только если), вы знаете, насколько велики исходная и целевая строки. Если вы не знаете, вы играете с огнем.

Переполнения буфера с memcpy() - это прямые ошибки в вашей программе; Вы не можете использовать его надежно, если вы не знаете размеров или буферы не перекрываются (memmove() безопаснее; он обрабатывает перекрытия). Есть аргумент, который говорит: «Вам не нужны strcpy() или strcat() et c, потому что если у вас достаточно данных для их безопасного использования, вы можете вместо этого использовать memmove() или memcpy()». В целом, strlen() довольно безопасен - если вы передадите ему строку. Если вы не знаете, имеете ли вы дело со строками, тогда у вас много проблем; Вы должны знать, что имеете дело со строками для вызова функций манипуляции со строками.

Обратите внимание, что функции strncpy() и strncat() небезопасны. Проблема с strncpy() заключается в том, что он не завершает строку нулем, если источник слишком длинный. Проблема с strncat() состоит в том, что передача sizeof(dst) в качестве размера пункта назначения неверна, даже если строка пуста; он имеет один из самых странных, наиболее подверженных ошибкам интерфейсов из всех существующих C функций - gets() больше не считается существующим. Если вы знаете размеры всего, они вам не нужны. Если вы не знаете размеры, их использование не сделает вас в безопасности.

Использование sprintf() излишне опасно; использование snprintf() должно быть безопасным, если вы получите правильный размер и обратите внимание на усечение данных, проверяя возвращаемое значение. Проверьте, доступны ли asprintf() и vasprintf(), и рассмотрите возможность их использования, если они есть.

Уязвимости форматной строки возникают там, где у вас есть:

printf(fmtstr, value1, value2);

, где fmtstr аргумент может контролироваться или под влиянием пользователя. Если вы можете определить, откуда берется строка формата, и знаете, что она безопасна, тогда проблем нет, и это может помочь с интернационализацией вашего кода. Если вы не можете определить, что строка формата безопасна, вы рискуете. Насколько серьезны эти риски, зависит от контекста, в котором они используются. Если пользователь root будет запускать код, что, вероятно, для планировщика, то вы должны быть дотошными. Вы, возможно, сможете быть немного бодрее, если пользователи, использующие код, не будут root, но трудно гарантировать, что никто никогда не будет запускать код как root.

You ' Правильно, что функции _s недоступны, кроме Windows. Внешние аудиторы были совершенно бесполезны - предполагать, что использование функций, которые недоступны на целевой платформе, контрпродуктивно. Несмотря на это, есть место для споров о том, достаточно ли использования функций _s, Microsoft. Они могут быть использованы неправильно, как любая функция. См. Статью N1967, на которую есть ссылка в моем ответе на вопрос TR 24731. (Есть более поздние документы, доступные на веб-сайте C стандартного комитета по адресу http://www.open-std.org/jtc1/sc22/wg14/, которые не полностью согласны с N1967 - N2336, например, из рассылки до Лондона 2019 года. Я не уверен, что я полностью согласен с N2336.)

Подумайте, доступны ли strlcpy() и strlcat() и можно ли их использовать для strcpy(), strncpy(), strcat(), strncat().

...