Почему strlcpy и strlcat считаются небезопасными?

Я понимаю это strlcpyи strlcatбыли разработаны как безопасная замена для strncpyи strncat. Однако некоторые люди по-прежнему считают, что они небезопасны, и просто вызывают проблемы другого типа .

Может ли кто-нибудь привести пример того, как использование strlcpyили strlcat(то есть функция, которая всегда завершает свои строки нулевым значением) может привести к проблемам безопасности?

Ульрих Дреппер и Джеймс Антилл утверждают, что это правда, но никогда не приводят примеров и не поясняют этот момент.

Во-первых, strlcpyон никогда не задумывался как безопасная версия strncpy(и strncpyникогда не задумывался как безопасная версия strcpy). Эти две функции совершенно не связаны. strncpy- это функция, которая вообще не имеет отношения к C-строкам (т.е. строкам с завершающим нулем). То, что str...в названии есть приставка, - просто историческая ошибка. История и цель ), что на самом деле является полной чушью и приводит к плохой практике программирования. Стандартная библиотека C в ее нынешнем виде не имеет функции для копирования C-строки ограниченной длины. Вот где подходит. Это действительно настоящая функция копирования ограниченной длины, созданная для работы с C-строками.strncpy хорошо известны и задокументированы. Это функция, созданная для работы со строками так называемой «фиксированной ширины» (не с C-строками), используемыми в некоторых исторических версиях файловой системы Unix. Сегодня некоторые программисты сбиты с толку его названием и предполагают, что strncpyон каким-то образом должен служить функцией копирования C-строки ограниченной длины («безопасный» родственный элементstrcpystrlcpystrlcpystrlcpyправильно делает все, что должна делать функция копирования ограниченной длины. Единственная критика, на которую можно направить это, - это то, что это, к сожалению, нестандартно.

Во-вторых, strncatс другой стороны, это действительно функция, которая работает с C-строками и выполняет конкатенацию ограниченной длины (это действительно «безопасный» брат, который заботится об этих проблемах, изменяя интерфейс так, чтобы не требовались дополнительные вычисления. (по крайней мере, в вызывающем коде). Опять же, единственное основание, которое, как я вижу, можно критиковать, это то, что функция не является стандартной. Кроме того, функции из группы - это то, что вы не увидите в профессиональном коде очень часто из-за ограниченного удобство использования самой идеи конкатенации строк на основе повторного сканирования.strcat ). Чтобы правильно использовать эту функцию, программист должен проявить особую осторожность, так как параметр размера, который принимает эта функция, на самом деле не является размером буфера, который получает результат, а скорее размером его оставшейся части (также, символа терминатора засчитывается неявно). Это может сбивать с толку, поскольку для того, чтобы привязать этот размер к размеру буфера, программист должен не забыть выполнить некоторые дополнительные вычисления, которые часто используются для критики strncat.strlcatstrcat

Что касается того, как эти функции могут привести к проблемам с безопасностью ... Они просто не могут. Они не могут привести к проблемам безопасности в большей степени, чем сам язык C может «привести к проблемам безопасности». Видите ли, какое-то время было сильное мнение, что язык C ++ должен двигаться в направлении развития в какой-то странный вид Java. Это мнение иногда распространяется и на область языка C, что приводит к довольно невежественной и вынужденной критике функций языка C и возможностей стандартной библиотеки C. Я подозреваю, что мы можем иметь дело с чем-то подобным и в этом случае, хотя я, конечно, надеюсь, что все не так уж плохо.

Критика Ульриха основана на идее, что усечение строки, которое не обнаруживается программой, может привести к проблемам безопасности из-за неправильной логики. Следовательно, для обеспечения безопасности вам необходимо проверить усечение. Это для конкатенации строк означает, что вы выполняете проверку в соответствии со следующими строками:

if (destlen + sourcelen > dest_maxlen)
{
    /* Bug out */
}

Теперь strlcatэффективно выполняет эту проверку, если программист не забывает проверить результат - так что вы можете безопасно использовать его:

if (strlcat(dest, source, dest_bufferlen) >= dest_bufferlen)
{
    /* Bug out */
}

Позиция Ульриха заключается в том, что, поскольку вам нужно иметь destlenи sourcelenоколо (или пересчитать их, что strlcatэффективно и работает), вы можете в memcpyлюбом случае просто использовать более эффективное :

if (destlen + sourcelen > dest_maxlen)
{
    goto error_out;
}
memcpy(dest + destlen, source, sourcelen + 1);
destlen += sourcelen;

(В приведенном выше коде dest_maxlenэто максимальная длина строки, которая может быть сохранена dest- на единицу меньше размера destбуфера. dest_bufferlen- это полный размер строки dest buffer).

Когда люди говорят: « strcpy()Это опасно, используйте strncpy()вместо этого» (или аналогичные утверждения о strcat()и т. Д., Но я собираюсь использовать strcpy()здесь в качестве основного), они имеют в виду, что нет никаких ограничений strcpy(). Таким образом, слишком длинная строка приведет к переполнению буфера. Они правы. Использование strncpy()в этом случае предотвратит переполнение буфера.

Я чувствую, что это strncpy()действительно не исправляет ошибки: это решает проблему, которую может легко избежать хороший программист.

Как программист на C, вы должны знать конечный размер, прежде чем пытаться копировать строки. Это предположение strncpy()и в strlcpy()последних параметрах: вы указываете им этот размер. Вы также можете узнать исходный размер, прежде чем копировать строки. Затем, если пункт назначения недостаточно велик, не звонитеstrcpy() . Либо перераспределите буфер, либо сделайте что-нибудь еще.

Почему мне не нравится strncpy()?

• strncpy() - плохое решение в большинстве случаев: ваша строка будет усечена без какого-либо уведомления - я бы предпочел написать дополнительный код, чтобы выяснить это сам, а затем предпринять действия, которые я хочу предпринять, вместо того, чтобы позволить какой-то функции решить за мне о том, что делать.
• strncpy()очень неэффективно. Он записывает каждый байт в целевой буфер. Вам не нужны эти тысячи '\0'в конце пункта назначения.
• Он не записывает завершение, '\0'если место назначения недостаточно велико. Так что вы все равно должны сделать это сами. Сложность сделать это не стоит проблем.

Теперь мы подошли к strlcpy(). Изменения strncpy()делают его лучше, но я не уверен, strl*оправдывает ли конкретное поведение их существование: они слишком специфичны. Вам все равно нужно знать размер места назначения. Это более эффективно, чем strncpy()потому, что он не обязательно записывает каждый байт в месте назначения. Но это решает проблему , которую можно решить, выполнив: *((char *)mempcpy(dst, src, n)) = 0;.

Я не думаю, что кто-то говорит это strlcpy()или strlcat()может привести к проблемам с безопасностью, то, что они (и я) говорят, что они могут привести к ошибкам, например, когда вы ожидаете, что будет записана вся строка, а не ее часть.

Главный вопрос здесь: сколько байтов копировать? Программист должен знать это , и если он не делает, strncpy()или strlcpy()не спасет.

strlcpy()и strlcat()не являются стандартными, ни ISO C, ни POSIX. Поэтому их использование в переносимых программах невозможно. Фактически, strlcat()существует два разных варианта: реализация Solaris отличается от других для крайних случаев, включающих длину 0. Это делает ее даже менее полезной, чем в противном случае.

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

Есть две «проблемы», связанные с использованием функций strl:

1. Вы должны проверить возвращаемые значения, чтобы избежать усечения.

Авторы проекта стандарта c1x и Дреппер утверждают, что программисты не будут проверять возвращаемое значение. Дреппер говорит, что мы должны каким-то образом знать длину и использовать memcpy и вообще избегать строковых функций. Комитет по стандартам утверждает, что безопасный strcpy должен возвращать ненулевое значение при усечении, если иное не указано _TRUNCATEфлагом. Идея в том, что люди с большей вероятностью будут использовать if (strncpy_s (...)).

2. Не может использоваться с нестроковыми.

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

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

Я не думаю strlcpyи strlcatсчитаю их небезопасными, или, по крайней мере, это не причина, по которой они не включены в glibc - в конце концов, glibc включает strncpy и даже strcpy.

Их критиковали за то, что они якобы неэффективны, а не небезопасны .

Согласно статье Дэмиена Миллера о безопасной переносимости :

API-интерфейсы strlcpy и strlcat правильно проверяют границы целевого буфера, завершаются нулевым значением во всех случаях и возвращают длину исходной строки, что позволяет обнаруживать усечение. Этот API принят в большинстве современных операционных систем и во многих автономных программных пакетах, включая OpenBSD (там, где он был создан), Sun Solaris, FreeBSD, NetBSD, ядро ​​Linux, rsync и проект GNOME. Заметным исключением является GNU стандартной библиотеки C, Glibc [12], чьи Сопровождающий упорно отказывается включать эти улучшенные интерфейсы API, маркируя их «чудовищно неэффективная BSD дерьмо»[4], несмотря на предыдущие доказательства того, что они в большинстве случаев быстрее, чем API, которые они заменяют [13]. В результате более 100 программных пакетов, представленных в дереве портов OpenBSD, поддерживают свои собственные замены strlcpy и / или strlcat или эквивалентные API, что не является идеальным положением дел.

Вот почему они недоступны в glibc, но неверно, что они недоступны в Linux. Они доступны в Linux в libbsd:

• https://libbsd.freedesktop.org/

Они упакованы в Debian, Ubuntu и другие дистрибутивы. Вы также можете просто взять копию и использовать ее в своем проекте - она ​​короткая и под разрешающей лицензией:

• http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/string/strlcpy.c?rev=1.11

Безопасность не является логическим. Функции C не являются полностью «безопасными» или «небезопасными», «безопасными» или «небезопасными». При неправильном использовании простая операция присваивания в C может быть «небезопасной». strlcpy () и strlcat () можно использовать безопасно (надежно) так же, как strcpy () и strcat () можно безопасно использовать, когда программист предоставляет необходимые гарантии правильного использования.

Основным моментом всех этих строковых функций C, стандартных и нестандартных, является уровень, до которого они упрощают безопасное / надежное использование . Безопасное использование strcpy () и strcat () нетривиально; это подтверждается количеством раз, когда программисты C ошибались за эти годы, и в результате возникали опасные уязвимости и эксплойты. strlcpy () и strlcat () и, в этом отношении, strncpy () и strncat (), strncpy_s () и strncat_s () немного проще в использовании, но все же нетривиально. Они небезопасны / небезопасны? Не более чем memcpy () при неправильном использовании.