Вопрос или проблема
Я смотрел на CVE-2024-53259, где злоумышленник может инъектировать сообщение ICMP Fragmentation Needed на хост с QUIC соединением, используя библиотеку quic-go. Причина в том, что quic-go устанавливает опцию сокета IP_PMTUDISC_DO при определении mtu своего пути.
Что меня действительно смущает, так это то, что, хотя страница CVE в основном говорит, что ядро получает пакет ICMP от злоумышленника и обновляет mtu пути, похоже, что ядро Linux обрабатывает пакеты отдельно по dst ip и src ip для полученной ошибки ICMP, строя ‘flow key’ (я смотрю на функцию ipv4_sk_update_pmtu):
void ipv4_sk_update_pmtu(struct sk_buff *skb, struct sock *sk, u32 mtu)
{
const struct iphdr *iph = (const struct iphdr *)skb->data;
struct flowi4 fl4;
struct rtable *rt;
struct dst_entry *odst = NULL;
bool new = false;
struct net *net = sock_net(sk);
bh_lock_sock(sk);
if (!ip_sk_accept_pmtu(sk))
goto out;
odst = sk_dst_get(sk);
if (sock_owned_by_user(sk) || !odst) {
__ipv4_sk_update_pmtu(skb, sk, mtu);
goto out;
}
// эта функция вызывает flowi4_init_output внутри, которая принимает src/dst адреса в качестве аргументов
__build_flow_key(net, &fl4, sk, iph, 0, 0, 0, 0, 0);
rt = dst_rtable(odst);
if (odst->obsolete && !odst->ops->check(odst, 0)) {
rt = ip_route_output_flow(sock_net(sk), &fl4, sk);
if (IS_ERR(rt))
goto out;
new = true;
}
...
}
Если пакеты обрабатываются на основе их src/dst адреса, пакет злоумышленника не должен прерывать существующее соединение, потому что у пакета другой адрес источника. Почему такая атака возможна?
заранее спасибо
Потому что RFC DHCP говорят, что мы должны принимать обновления MTU пути от любого.
Альтернатива заключалась бы в том, чтобы принимать обновления PMTU только от узлов вдоль пути, что может изменяться с каждым пакетом.
Учтите накладные расходы на заполнение и поддержание списка всех узлов вдоль пути отсюда туда, которым разрешено обновлять PMTU, для каждого TCP/IP пакета!
Вы можете обнаружить узлы вдоль пути, отправив пакет отсюда туда, с полем TTL (время жизни), установленным в 1, и зафиксировав хост, который вернул ошибку “Packet expired”, затем установить TTL на 2, 3, … пока не получите ответ от фактического назначения. И этот путь может измениться с следующим пакетом, который вы отправите.
Ответ или решение
Вопрос о возможности атаки через ICMP-сообщения "Fragmentation Needed" в контексте библиотеки quic-go является достаточно сложным и вызывает множество дискуссий среди специалистов в области сетевой безопасности. Давайте рассмотрим основные аспекты этого уязвимого места, затронутого в CVE-2024-53259.
Суть уязвимости
Уязвимость CVE-2024-53259 возникает из-за использования опции сокета IP_PMTUDISC_DO в библиотеке quic-go, которая предназначена для проб его пути максимального размера передачи (MTU). Использование этой опции позволяет системе автоматически настраивать MTU. При этом, если злоумышленник отправляет ICMP-сообщение о необходимости фрагментации, это может привести к изменению MTU до меньшего значения, чем реально необходимо, что вызывает проблемы с производительностью или даже потерю соединения.
Механизм ICMP и PMTU
Как вы правильно заметили, в ядре Linux пакеты обрабатываются на основании их IP-адресов источника и назначения. Функция ipv4_sk_update_pmtu действительно создает ключ потока (flow key), основываясь на адресах. Однако стоит учитывать следующее:
-
Обработка ICMP-сообщений: Правила обработки ICMP-сообщений заточены под то, что обновления MTU могут поступать от любых узлов, находящихся на пути передачи пакетов. Это основано на стандартах, таких как RFC 1191, которые рекомендуют принимать PMTU-обновления от любых источников. Отказ в принятии таких сообщений от переменных источников привел бы к ненужной сложности, так как необходимо было бы отслеживать всех узлов на пути передачи для корректной работы.
-
Изменение MTU: Когда злоумышленник отправляет ICMP-сообщение "Fragmentation Needed" с адресом, отличным от адреса целевого узла, соединение, возможно, не будет сразу прервано, но произойдут изменения в состоянии сети, что может снизить производительность. Может быть установлена MTU, которая не соответствует реальному состоянию сети и может быть ниже, чем требуемо для других соединений.
-
Динамичность путей в сети: Поскольку маршруты в сети могут меняться, обновления MTU могут происходить в ходе работы системы, и это может привести к неожиданным последствиям. Определение "дождаться ответа" от узлов при каждом пакете было бы неэффективно и нецелесообразно в реальных условиях эксплуатации.
Заключение
Таким образом, механизм об обновлении MTU, как описано в стандартных спецификациях, приводит к тому, что даже случайное или злонамеренное ICMP-сообщение может повлиять на установленные соединения, такие как те, которые использует библиотека quic-go. Это делает библиотеку уязвимой к атакам, основанным на ICMP, несмотря на то, что обработка ICMP идет по ключу потока.
Для борьбы с подобными атаками, разработчики и администраторы могут рассмотреть возможность улучшения фильтрации входящих ICMP-сообщений или внедрения других механизмов безопасности, таких как более строгая валидация PMTU-обновлений или использование дополнительных протоколов, таких как TCP, которые обладают своими средствами управления MTU.
В конечном итоге, понимание и учет всех аспектов безопасности на уровне сетевых протоколов, а также регулярное обновление библиотек и систем, критически важны для защиты от подобных уязвимостей.