[Сетевые технологии, Разработка под Linux] Часто встречающиеся ошибки
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Решил написать о часто встречающейся ошибке в сетевых приложениях и сетевых устройствах.
Постараюсь объяснить проблему, на примере Linux стека. И буду больше рассуждать Абстрактно, пытаясь объяснить принцип. Ведь все приложения разные, хоть суть одна. (Переносят биты туда-сюда. ) И к каждому сетевому приложению, или к сетевому устройству нужен свой подход, чтоб исправить допущенные в нём ошибки. Проблема заключается в тех маленьких порциях данных, которыми обмениваются системы. Точнее не в самих этих порциях, а в том, как они далее собираются и обрабатываются.Например, одна система отправляет другой системе фразу «Hello World !» Как это можно сделать? Да как угодно. Выбирается любой протокол передачи данных: TCP, MPTCP, UDP. Данные разбиваются на части, которые мы назовём пакетами. И отправляются на конечную систему. (Как именно? Да это абсолютно не важно. )Важно то, что(и как) конечная система будет делать с полученными данными. Если строка «Hello World !» была разбита на два пакета: «Hello » - Это содержимое первого пакета. «World !» - А это, уже второй пакет.То после того, как сетевое устройство начнёт принимать пакеты (они могут быть обработаны самим сетевым устройством) при удачной обработке, они будут переданы далее в сетевой стек Операционной Системы (ОС). (О проблеме на этом этапе будет написано далее. )Если пакеты попали в Сетевой Стек, то ОС обрабатывает данные пакета последовательно. Это значит, что часть пакета будет указывать, как пакет был доставлен до системы. И мы эту часть, смело пропускаем т.к. это Не важно. Отбрасываем всю часть рассуждений вплоть до важного момента — до Сборки данных на транспортном уровне.В конечном итоге, система должна понять какова правильная последовательность пакетов. Ведь, до системы мог сначала дойти пакет «World !» - Второй пакет. А потом «Hello » - Первый пакета. И если, ОС не определяла правильную последовательность пакетов. То до приложения пользовательского уровня. Дойдёт такая строка: «World !Hello ». Разумеется такой подход большинство не устраивает и поэтому протоколы поддерживают номера последовательностей (а также временные метки, но это всё частности, мы будем говорить только о «номерах последовательностей» и назовём их «seq»).
Мы уже оперируем такими важными вещами: Данные и seq. Добавим к нашим знаниям, также «Размер Данных».
Данных и их размера, достаточно, чтоб произвести их отправку через сокет. Но зачем тогда упоминать seq?
Тут нужно осознать, что можно предугадать состояние второй системы, которая принимает наш «Hello World !»
Смотрим на примере Linux и протокола TCP ( Код привожу из ядра Linux-5.10.7 ) В файле «tcp_ipv4.c» есть функция tcp_v4_fill_cb , которая прольёт свет на происходящее на конечной системе. А точнее, нас интересует
TCP_SKB_CB(skb)->end_seq = (TCP_SKB_CB(skb)->seq + th->syn + th->fin +
skb->len - th->doff * 4);
end_seq — Это значение используется для указания конца данных пакета. (Любой следующий пакет, должен быть как минимум на единицу больше предыдущего (Для того, чтоб не быть отброшенным до начала копирования данных пакетов из сокета)Например: «Hello » - Первый пакета. Размер 6 байт. Первый пакет, имеет seq = 0x1 и end_seq = 0x7 «World !» - Второй пакет. Размер 7 байт. Второй пакет, имеет seq = 0x7 и end_seq = 0xE Тогда данные собирутся в строку «Hello World !»А вот если Второй пакет, имеет seq = 0x4 и end_seq = 0xB Тогда данные собирутся в строку «Hello ld !» Символы «Wor» Будут отброшены. (Это происходит при копировании данных из пакетов, при чтении сокета ) После копирования данных. Через функцию tcp_rcv_nxt_update файла «tcp_input.c» указывается значение rcv_nxt в структуре протокола struct tcp_sock. Это значение, будет равняться end_seq после копирования всех пакетов в общий буфер (после чтения данных из сокета). (Первое значение rcv_nxt будет установлено сразу после tcp рукопожатия)Короче говоря: сначала приходят пакеты и передвигается значение end_seq
Далее данные копируются в общий буфер, и передвигается значение copied_seq структуры tcp_sock. И после того, как данные из пакетов (буферов сокетов) будут скопированы в общий буфер, произойдёт установка rcv_nxt в end_seq.
И итерация повторяется. Теперь рассмотрим следующее. Что будет если
Первый пакет: seq = 0xFFFFFFF0 и размер 0x64 (100)
то
TCP_SKB_CB(skb)->end_seq = (0xFFFFFFF0 + 0x1 + 0 + 0x140 - 0x40);
(если doff = 5)
TCP_SKB_CB(skb)->end_seq = 0xFFFFFFF0 + 0x65 = 0x100000055
Т. е. произошло переполнение, и результат end_seq = 0x55 (85 в десятичной) при этом rcv_nxt = 0xFFFFFFF0 , т. к. ещё копирования данных из сокета не произошло. Здесь возникает ситуация, когда end_seq < seq
0x55 < 0xFFFFFFF0
А также, можно далее слать пакеты, имеющие большой порядковый номер и больший размер данных пакета. (для того, чтоб влиять на значение skb_len )
Например такой пакет будет корректен.
seq = 0xFFFFFC6E размером в 1000 байт (end_seq = 0x56 )
В этом нет ничего интересного, если не помнить о флаге URG . В Википедии сказано: 16-битовое значение положительного смещения от порядкового номера в данном сегменте. Это поле указывает порядковый номер октета, которым заканчиваются важные (urgent) данные.
И вот тут то, и находятся возможные ошибки. Всё зависит от того, как сетевое устройство обрабатывает urg пакеты. Ошибки могут быть в реализации драйверов. Или в аппаратной части. (при TCP Offload Engine )
При больших значениях seq (близких к целочисленному переполнению),
возможности регулировать размер буфера сокета (размером данных пакета),
возможностью указать смещение для urg в диапазоне 0-0xffff,
установкой значения rcv_nxt.
Можно влиять на дальнейшее поведение системы. (на уровне ядра)
Добавлю ещё такую информацию. Она не будет лишней.
Проверки номеров последовательностей пакетов, базируются на функциях: after и before. Которые проверяют, где находится число в последовательности "до" указанного числа, либо "после" или "равно". Вот результаты работы функций с некоторыми числами, как пример.
inline bool before(__u32 seq1, __u32 seq2)
{
return (__s32)(seq1-seq2) < 0;
}
#define after(seq2, seq1) before(seq1, seq2)
after( 0x80000000, 0x7fffffff ) = 1
after( 0x7fffffff, 0x80000000 ) = 0
after( 0x80000000, 0x80000000 ) = 0
before( 0x80000000, 0x7fffffff ) = 0
before( 0x7fffffff, 0x80000000 ) = 1
before( 0x80000000, 0x80000000 ) = 0
Как видно, сравнение больше или равно, сводится к вычитанию второго аргумента из первого и сравнения результата с нулём. В большинстве случаев, с помощью данных функций определяется, как следует поступить с пакетом. Если оказывается, что end_seq имеет номер меньший или равный последнему принятому пакету, то такой пакет отбрасывается. На примере end_seq < seq0x55 < 0xFFFFFFF0В тех случаях, когда происходят математические действия над двумя и более параметрами на которые можно влиять, и сравнение их с каким то числом, то
if(TCP_SKB_CB(skb)->end_seq - TCP_SKB_CB(skb)->seq >= какое то число) {
Можно зайти сюда } else { или сюда }
if(0x55 - 0xfffffff0 >= какое то число)
if(0xFFFFFF9B >= какое то число)
Привожу пример кода из файла chtls_cm.c который может содержать ошибку.В функция handle_urg_ptr присутствует такой код.
if (skb && tp->copied_seq - ULP_SKB_CB(skb)->seq >= skb->len)
chtls_free_skb(sk, skb);
В нем присутствуют три переменных: copied_seq, seq, skb->len на которые можно влиять.На самом деле нет (из-за особенностей работы устройства, нельзя влиять на ULP_SKB_CB(skb)->seq ). Еслиб можно было влиять на (skb)->seq, тогда можно подобрать такие значения seq, copied и skb->len при которых, сработает очистка буфера сокета и код драйвера, продолжит свою работу.Далее, рассмотрим такой пример: в файле chtls_cm.cЕсть функция chtls_recv_data в ней присутствует такой код
if (unlikely(hdr->urg))
handle_urg_ptr(sk, tp->rcv_nxt + ntohs(hdr->urg));
if (unlikely(tp->urg_data == TCP_URG_NOTYET &&
tp->urg_seq - tp->rcv_nxt < skb->len))
tp->urg_data = TCP_URG_VALID |
skb->data[tp->urg_seq - tp->rcv_nxt];
Сразу можно обратить внимание на вызов handle_urg_ptr(sk, tp->rcv_nxt + ntohs(hdr->urg)); Где находятся два аргумента tp->rcv_nxt + ntohs(hdr->urg) .rcv_nxt можно предсказать, а hdr->urg установить в пакете. Таким образом, пердав какое то число в функцию handle_urg_ptr для дальнейшей обработки. Но это не так кретично, как следущий код.
if (unlikely(tp->urg_data == TCP_URG_NOTYET &&
tp->urg_seq - tp->rcv_nxt < skb->len))
tp->urg_data = TCP_URG_VALID |
skb->data[tp->urg_seq - tp->rcv_nxt];
Тут снова видим tp->urgseq - tp->rcv_nxt < skb->len , два числи на которые может воздействовать отправитель пакетов, сравниваются с значением размера данных сокета, который также указывается отправителем (через количество отправляемых данных). А далее skb->data[tp->urg_seq - tp->rcv_nxt];Снова два значения, устанавливаемые удалённо tp->urg_seq - tp->rcv_nxt. Обратятся, к данным по индексу - ???
tp->urg_seq - tp->rcv_nxt < skb->len
Данное условие создаёт иллюзию, что при обращении к массиву skb->data
urg_seq - tp->rcv_nxt Будут находиться, внутри массива данных сокета.
И не могут быть больше skb->len, ведь чуть выше делалась проверка
tp->urg_seq - tp->rcv_nxt < skb->len
Вобщем, в суровой реальности индекс массива может быть
skb->data[0xffffffff];
skb->data[0xfffffff0];
skb->data[0xffffff00]; и тд.
Это приводит к чтению памяти, по указному индексу. Либо к зависанию системы. Далее ещё один пример.Но уже обработки данных пакета на сетевом устройстве (которую, я разобрать не могу). Можно предположить, что внутри устройства есть теже проблемы, что и у большого числа сетевых устройств(и программ). Это, проблема с проверками порядковых номеров в протоколах пакетов.Фактически, можно произвести тестирование "черного ящика" но с допущением, что проверяться будут различные условия для порядковых номеров пакетов.Когда устройство делает аппаратную обработку tcp пакетов, то предполагается что взаимодействие клиент/сервер происходит, по стандартному сценарию. Когда все действия систем перекладываются на сетевой стек. Все данные имеют, порядковые номера указываемые сетевой подсистемой (временные метки, размер пакетов и тд.). Но если, пакеты сформированы вне "системы", то есть огромная вероятность, что что-то пойдёт не так. Ведь, когда программист тестирует сетевое приложение (или аппаратуру), то он не выходит из стандартной схемы тестирования. Берёт приложение, или пишет его сам. Создаёт сокет и шлёт данные. Как именно шлются эти данные, программисту не важно. В этом проблема. Люди больше концентрируют внимание на том, какие именно данные шлются, а не на том, как они отправляются.Пример ошибки с индексом массива, невозможно найти в обычной схеме тестирования. Через отправку произвольных данных.А когда тестируется сетевое устройство, то после ошибки обработки данных (или не ошибки) в устройстве. Оно может передать в драйвер не корректные данные. Которые по сути, никак не могли появиться. (в теории) (Но если вспомнить о проблемах проверки порядковых номеров. То вероятность обнаружить ошибку, резко возрастает)Вот пример: в файле chtls_main.c Есть функция chtls_recv , она работает с пакетом который уже был обработан сетевым устройством.
void chtls_recv(struct chtls_dev *cdev,
struct sk_buff **skbs, const __be64 *rsp)
{
struct sk_buff *skb = *skbs;
unsigned int opcode;
int ret;
opcode = *(u8 *)rsp; // Тут находится ОШИБОЧНЫЙ ОПКОД
__skb_push(skb, sizeof(struct rss_header));
skb_copy_to_linear_data(skb, rsp, sizeof(struct rss_header));
ret = chtls_handlers[opcode](cdev, skb); // Вызов функции по, не правильному опкоду
if (ret & CPL_RET_BUF_DONE)
kfree_skb(skb);
}
После обработки пакета устройством, сетевая карта передаёт драйверу опкод операции которую должна выполнить система.opcode = *(u8 *)rsp; Содержит опкод инструкции, которую будет выполнять система.Но если, передать устройству определённые пакеты, которые пройдут все проверки по значениям seq и дополнить их urg, то устройство выставит определённый опкод для выполнения, который вообще не должен был никогда выставляться.В данном примере
ret = chtls_handlers[opcode](cdev, skb);
Будет выполнена функция по адресу NULL. Что приведёт к зависанию системы.И такие ошибки остаются не замеченными ГОДАМИ.Также скажу, что пытался рассказать о проблеме на примере TCP и флага urg. Но точно такие же проблемы, можно обнаружить и при сборке UDP пакетов (везде. не важно, драйвера или приложения прикладного уровня, или сетевые устройства). Сколько сетевых устройств подвержено данной проблеме, не знаю. Думаю, что очень не мало.Проверял всего одно устройство (которое было на руках). Результат, удалённый вызов нулевого указателя в ядре. Отказ в обслуживании. ( + доступ к памяти системы, в определённых диапазонах) Писал производителю о проблемах, но им это не интересно, проигнорировали и выпустили новый флагман) с теми же проблемами.На этом пока всё.
===========
Источник:
habr.com
===========
Похожие новости:
- [Open source, Разработка под Linux, Программирование микроконтроллеров, Софт] Поскольку на Raspberry Pi Pico не встанет Linux, умелец портировал на плату Fuzix
- [Информационная безопасность, Сетевые технологии, Исследования и прогнозы в IT, Искусственный интеллект, Интернет вещей] Top 7 Technology Trends to Look out for in 2021
- [Open source, Разработка под Linux, Софт] Бета версия OpenBSD поддерживает чип Apple M1
- [Сетевые технологии, Исследования и прогнозы в IT] Из-за пандемии потребление интернет-трафика превысило ожидаемые значения в 1,5 раза
- [IT-инфраструктура, Сетевые технологии, Бизнес-модели, IT-компании] «Ъ»: Компания, принадлежащая правительству Москвы, создаёт блокчейн-платформу за 500 млн рублей
- [.NET, C#, Разработка под Linux, Разработка под Windows] Путешествие в unmanaged code: туда и обратно
- [Open source, Виртуализация, Разработка под Linux, Openshift] 14 лучших практик разработки приложений на OpenShift
- [Информационная безопасность, Сетевые технологии, Разработка систем связи, Сотовая связь] Как не спалить закладку полиции?
- [Информационная безопасность, Сетевые технологии, IT-компании] От локального ПО до всероссийских инсталляций: как изменился ИКС за 17 лет
- [Сетевые технологии] nmap скрипты
Теги для поиска: #_setevye_tehnologii (Сетевые технологии), #_razrabotka_pod_linux (Разработка под Linux), #_oshibki_programmistov (ошибки программистов), #_setevye_tehnologii (
Сетевые технологии
), #_razrabotka_pod_linux (
Разработка под Linux
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:35
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Решил написать о часто встречающейся ошибке в сетевых приложениях и сетевых устройствах. Постараюсь объяснить проблему, на примере Linux стека. И буду больше рассуждать Абстрактно, пытаясь объяснить принцип. Ведь все приложения разные, хоть суть одна. (Переносят биты туда-сюда. ) И к каждому сетевому приложению, или к сетевому устройству нужен свой подход, чтоб исправить допущенные в нём ошибки. Проблема заключается в тех маленьких порциях данных, которыми обмениваются системы. Точнее не в самих этих порциях, а в том, как они далее собираются и обрабатываются.Например, одна система отправляет другой системе фразу «Hello World !» Как это можно сделать? Да как угодно. Выбирается любой протокол передачи данных: TCP, MPTCP, UDP. Данные разбиваются на части, которые мы назовём пакетами. И отправляются на конечную систему. (Как именно? Да это абсолютно не важно. )Важно то, что(и как) конечная система будет делать с полученными данными. Если строка «Hello World !» была разбита на два пакета: «Hello » - Это содержимое первого пакета. «World !» - А это, уже второй пакет.То после того, как сетевое устройство начнёт принимать пакеты (они могут быть обработаны самим сетевым устройством) при удачной обработке, они будут переданы далее в сетевой стек Операционной Системы (ОС). (О проблеме на этом этапе будет написано далее. )Если пакеты попали в Сетевой Стек, то ОС обрабатывает данные пакета последовательно. Это значит, что часть пакета будет указывать, как пакет был доставлен до системы. И мы эту часть, смело пропускаем т.к. это Не важно. Отбрасываем всю часть рассуждений вплоть до важного момента — до Сборки данных на транспортном уровне.В конечном итоге, система должна понять какова правильная последовательность пакетов. Ведь, до системы мог сначала дойти пакет «World !» - Второй пакет. А потом «Hello » - Первый пакета. И если, ОС не определяла правильную последовательность пакетов. То до приложения пользовательского уровня. Дойдёт такая строка: «World !Hello ». Разумеется такой подход большинство не устраивает и поэтому протоколы поддерживают номера последовательностей (а также временные метки, но это всё частности, мы будем говорить только о «номерах последовательностей» и назовём их «seq»). Мы уже оперируем такими важными вещами: Данные и seq. Добавим к нашим знаниям, также «Размер Данных». Данных и их размера, достаточно, чтоб произвести их отправку через сокет. Но зачем тогда упоминать seq? Тут нужно осознать, что можно предугадать состояние второй системы, которая принимает наш «Hello World !» Смотрим на примере Linux и протокола TCP ( Код привожу из ядра Linux-5.10.7 ) В файле «tcp_ipv4.c» есть функция tcp_v4_fill_cb , которая прольёт свет на происходящее на конечной системе. А точнее, нас интересует TCP_SKB_CB(skb)->end_seq = (TCP_SKB_CB(skb)->seq + th->syn + th->fin +
skb->len - th->doff * 4); Далее данные копируются в общий буфер, и передвигается значение copied_seq структуры tcp_sock. И после того, как данные из пакетов (буферов сокетов) будут скопированы в общий буфер, произойдёт установка rcv_nxt в end_seq. И итерация повторяется. Теперь рассмотрим следующее. Что будет если Первый пакет: seq = 0xFFFFFFF0 и размер 0x64 (100) то TCP_SKB_CB(skb)->end_seq = (0xFFFFFFF0 + 0x1 + 0 + 0x140 - 0x40);
(если doff = 5) TCP_SKB_CB(skb)->end_seq = 0xFFFFFFF0 + 0x65 = 0x100000055 0x55 < 0xFFFFFFF0 А также, можно далее слать пакеты, имеющие большой порядковый номер и больший размер данных пакета. (для того, чтоб влиять на значение skb_len ) Например такой пакет будет корректен. seq = 0xFFFFFC6E размером в 1000 байт (end_seq = 0x56 ) В этом нет ничего интересного, если не помнить о флаге URG . В Википедии сказано: 16-битовое значение положительного смещения от порядкового номера в данном сегменте. Это поле указывает порядковый номер октета, которым заканчиваются важные (urgent) данные. И вот тут то, и находятся возможные ошибки. Всё зависит от того, как сетевое устройство обрабатывает urg пакеты. Ошибки могут быть в реализации драйверов. Или в аппаратной части. (при TCP Offload Engine ) При больших значениях seq (близких к целочисленному переполнению), возможности регулировать размер буфера сокета (размером данных пакета), возможностью указать смещение для urg в диапазоне 0-0xffff, установкой значения rcv_nxt. Можно влиять на дальнейшее поведение системы. (на уровне ядра) Добавлю ещё такую информацию. Она не будет лишней. Проверки номеров последовательностей пакетов, базируются на функциях: after и before. Которые проверяют, где находится число в последовательности "до" указанного числа, либо "после" или "равно". Вот результаты работы функций с некоторыми числами, как пример. inline bool before(__u32 seq1, __u32 seq2)
{ return (__s32)(seq1-seq2) < 0; } #define after(seq2, seq1) before(seq1, seq2) after( 0x80000000, 0x7fffffff ) = 1 after( 0x7fffffff, 0x80000000 ) = 0 after( 0x80000000, 0x80000000 ) = 0 before( 0x80000000, 0x7fffffff ) = 0 before( 0x7fffffff, 0x80000000 ) = 1 before( 0x80000000, 0x80000000 ) = 0 if(TCP_SKB_CB(skb)->end_seq - TCP_SKB_CB(skb)->seq >= какое то число) {
Можно зайти сюда } else { или сюда } if(0x55 - 0xfffffff0 >= какое то число) if(0xFFFFFF9B >= какое то число) if (skb && tp->copied_seq - ULP_SKB_CB(skb)->seq >= skb->len)
chtls_free_skb(sk, skb); if (unlikely(hdr->urg))
handle_urg_ptr(sk, tp->rcv_nxt + ntohs(hdr->urg)); if (unlikely(tp->urg_data == TCP_URG_NOTYET && tp->urg_seq - tp->rcv_nxt < skb->len)) tp->urg_data = TCP_URG_VALID | skb->data[tp->urg_seq - tp->rcv_nxt]; if (unlikely(tp->urg_data == TCP_URG_NOTYET &&
tp->urg_seq - tp->rcv_nxt < skb->len)) tp->urg_data = TCP_URG_VALID | skb->data[tp->urg_seq - tp->rcv_nxt]; tp->urg_seq - tp->rcv_nxt < skb->len
Данное условие создаёт иллюзию, что при обращении к массиву skb->data urg_seq - tp->rcv_nxt Будут находиться, внутри массива данных сокета. И не могут быть больше skb->len, ведь чуть выше делалась проверка tp->urg_seq - tp->rcv_nxt < skb->len Вобщем, в суровой реальности индекс массива может быть skb->data[0xffffffff]; skb->data[0xfffffff0]; skb->data[0xffffff00]; и тд. void chtls_recv(struct chtls_dev *cdev,
struct sk_buff **skbs, const __be64 *rsp) { struct sk_buff *skb = *skbs; unsigned int opcode; int ret; opcode = *(u8 *)rsp; // Тут находится ОШИБОЧНЫЙ ОПКОД __skb_push(skb, sizeof(struct rss_header)); skb_copy_to_linear_data(skb, rsp, sizeof(struct rss_header)); ret = chtls_handlers[opcode](cdev, skb); // Вызов функции по, не правильному опкоду if (ret & CPL_RET_BUF_DONE) kfree_skb(skb); } ret = chtls_handlers[opcode](cdev, skb);
=========== Источник: habr.com =========== Похожие новости:
Сетевые технологии ), #_razrabotka_pod_linux ( Разработка под Linux ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:35
Часовой пояс: UTC + 5