Уязвимость в uClibc и uClibc-ng, позволяющая подменить данные в кэше DNS

04.05.2022 12:55

В стандартных Си-библиотеках uClibc и uClibc-ng, применяемых во многих встраиваемых и портативных устройствах, выявлена уязвимость (CVE не присвоен), позволяющая подставить фиктивные данные в кэш DNS, что можно использовать для подмены в кэше IP-адреса произвольного домена и перенаправления обращений к домену на сервер злоумышленника.

Проблема затрагивает различные Linux-прошивки для маршрутизаторов, точек доступа и устройств интернета-вещей, а также Linux-дистрибутивы для встраиваемых систем, такие как OpenWRT и Embedded Gentoo. Отмечается, что уязвимость проявляется в устройствах многих производителей (например, uClibc используется в прошивках Linksys, Netgear и Axis), но так как в uClibc и uClibc-ng уязвимость остаётся неисправленной, детальные сведения о конкретных устройствах и производителях, в продуктах которых присутствует проблема, пока не разглашаются.

Уязвимость вызвана использованием в коде отправки DNS-запросов предсказуемых идентификаторов транзакции. Идентификационный номер запроса DNS выбирался путём простого увеличения счётчика без применения дополнительной рандомизации номеров портов, что позволяло добиться отравления кэша DNS через упреждающую отправку UDP-пакетов с фиктивными ответами (ответ будет принят, если он пришёл раньше ответа реального сервера и включает корректный ID). В отличие от предложенного в 2008 году метода Каминского, идентификатор транзакции даже не нужно угадывать, так как он изначально предсказуем (вначале выставляется значение 1, которое при каждом запросе увеличивается, а не выбирается случайным образом).

В спецификации для защиты от подбора идентификатора рекомендуется дополнительно применять случайное распределение номеров исходных сетевых портов, с которых отправляются DNS-запросы, что компенсирует недостаточно большой размер идентификатора. При включении рандомизации портов для формирования фиктивного ответа кроме подбора 16 битного идентификатора необходимо подобрать и номер сетевого порта. В uClibc и uClibc-ng подобная рандомизация не включалась явно (при вызове bind не указывался случайный исходный UDP порт) и её применение зависело от настроек операционной системы.

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

Наличие проблемы подтверждено во всех актуальных выпусках uClibc и uClibc-ng, включая самые свежие версии uClibc 0.9.33.2 и uClibc-ng 1.0.40. В сентябре 2021 года информация об уязвимости была отправлена в CERT/CC для согласованной подготовки исправлений. В январе 2022 года данные о проблеме были переданы более 200 производителям, сотрудничающим с CERT/CC. В марте была попытка отдельно связаться с сопровождающим проект uClibc-ng, но он ответил, что не в состоянии исправить уязвимость самостоятельно и рекомендовал публично раскрыть информацию о проблеме, рассчитывая получить помощь в разработке исправления от сообщества. Из производителей о выпуске обновления с устранением уязвимости объявил NETGEAR.

исправить +9 +/–

Лицензия: CC BY 3.0

Короткая ссылка: https://opennet.ru/57131-uclibc

Ключевые слова: uclibc, dns

При перепечатке указание ссылки на opennet.ru обязательно

Обсуждение (63)

1.1, Аноним (1), 14:40, 04/05/2022 [ответить] [﹢﹢﹢] [ · · · ]	+4 +/–
Никогда не было, и вот опять

2.43, Аноним (43), 22:46, 04/05/2022 [^] [^^] [^^^] [ответить]	+/–
Опять детский сад и школа виноваты? 👀 )

1.2, Аноним (2), 14:43, 04/05/2022 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ] [к модератору]	–6 +/–

2.7, Аноним (7), 15:04, 04/05/2022 Скрыто ботом-модератором [к модератору]	+3 +/–

3.13, НяшМяш (ok), 15:18, 04/05/2022 Скрыто ботом-модератором [к модератору]	+6 +/–

2.10, Аноним (10), 15:10, 04/05/2022 Скрыто ботом-модератором [к модератору]	+/–

....ответы скрыты (3)

1.3, Аниме (?), 14:44, 04/05/2022 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ] [к модератору]	+/–

2.8, Аноним (7), 15:06, 04/05/2022 Скрыто ботом-модератором [к модератору]	+/–

1.4, Аноним (4), 14:48, 04/05/2022 [ответить] [﹢﹢﹢] [ · · · ]	+2 +/–
Не, ну с printf было забавнее, я так понимаю у них у всех качество кода примерно одинаковое.

1.5, timur.davletshin (ok), 14:54, 04/05/2022 [ответить] [﹢﹢﹢] [ · · · ]	+1 +/–
OpenWRT же на musl переезжал, нет?

2.11, Мохнатый пись (?), 15:11, 04/05/2022 [^] [^^] [^^^] [ответить]	+/–
Деды-пердуны на 19.07 могут иметь uClibc

3.16, timur.davletshin (ok), 15:47, 04/05/2022 [^] [^^] [^^^] [ответить]	+1 +/–
Там тоже musl.

2.18, Аноним (18), 16:19, 04/05/2022 [^] [^^] [^^^] [ответить]	+/–
> musl Там же тоже какие-то застаревшие проблемы с сетью, с тем же DNS, нет?

3.19, timur.davletshin (ok), 16:20, 04/05/2022 [^] [^^] [^^^] [ответить]

+/–

>> musl
> Там же тоже какие-то застаревшие проблемы с сетью, с тем же DNS,
> нет?

Нет.

4.21, Аноним (18), 16:31, 04/05/2022 [^] [^^] [^^^] [ответить]	+/–
А пишут, что musl = based but still immature with a lot of network issues, glibc = cringe but rock solid. Уже нет? :) Ура!

5.22, timur.davletshin (ok), 16:37, 04/05/2022 [^] [^^] [^^^] [ответить]	+3 +/–
Ты накидывай лучше сразу ссылки на уязвимости в DNS, а не языком по широкому холсту.

6.27, Nr (?), 17:03, 04/05/2022 [^] [^^] [^^^] [ответить]	+/–
Есть и musl, и glibc https://openwrt.org/releases/22.03/notes-22.03.0-rc1

7.33, timur.davletshin (ok), 18:23, 04/05/2022 [^] [^^] [^^^] [ответить]	+/–
> Есть и musl, и glibc https://openwrt.org/releases/22.03/notes-22.03.0-rc1 Это тулчейн. Как оно компиляется по большому счёту никому нет дела. А libc в самом OpenWRT от musl.

3.29, Аноним (29), 17:56, 04/05/2022 [^] [^^] [^^^] [ответить]	+/–
ага, например, musl не умеет в DNS через TCP

4.36, Аноним (18), 19:32, 04/05/2022 [^] [^^] [^^^] [ответить]	–1 +/–
То есть DoT/DoH в Alpine Linux не будет работать?

5.55, ilyafedin (ok), 06:45, 06/05/2022 [^] [^^] [^^^] [ответить]	+/–
DoT/DoH не через libc работают

1.6, Аноним (6), 15:02, 04/05/2022 [ответить] [﹢﹢﹢] [ · · · ]	–3 +/–
UDP маздай.

2.9, Аноним (7), 15:07, 04/05/2022 [^] [^^] [^^^] [ответить]	+/–
Однако, NAT он пробивает лучше, чем TCP.

3.12, Мохнатый пись (?), 15:13, 04/05/2022 [^] [^^] [^^^] [ответить]	–1 +/–
NAT не нужен, но UDP ещё и канал лучше утилизирует.

4.17, timur.davletshin (ok), 15:52, 04/05/2022 [^] [^^] [^^^] [ответить]	+/–
Он использует те же алгоритмы управления потоком, что и TCP. Просто напулять пакетов без проверки доставки можно больше, но кому такое нужно? Даже realtime видео нафиг не упало, если оно рассыпается на кашу из квадратов.

5.20, Мохнатый пись (?), 16:31, 04/05/2022 [^] [^^] [^^^] [ответить]	–1 +/–
QUIC может использовать свои алгоритмы для проверки доставки.

6.23, timur.davletshin (ok), 16:42, 04/05/2022 [^] [^^] [^^^] [ответить]	+/–
> QUIC может использовать свои алгоритмы для проверки доставки. Проверка доставки или всё же управление потоком? Так-то в подавляющем большинстве реализаций обычный CUBIC стоит в дефолте. Почему выносить из усерспейса VPN в ядро считается хорошим (Wireguard), а перенос realtime управления потоком из ядра в узерспейс (TCP → QUIC) не считается плохой идеей? Вам не кажется, что где-то в одном из двух случаев логика даёт сбой и создатели протокола просто "залечивают" без должного обоснования.

7.25, Аноним (7), 16:47, 04/05/2022 [^] [^^] [^^^] [ответить]	+1 +/–
QUIC - синдром NIH Гугли.

7.30, Аноним (-), 18:02, 04/05/2022 [^] [^^] [^^^] [ответить]	–1 +/–
> Почему выносить из усерспейса VPN в ядро считается хорошим (Wireguard), а перенос realtime управления потоком из ядра в узерспейс (TCP → QUIC) не считается плохой идеей? Потому что это разные задачи. Разным задачам, разные решения. Ты не знал об этом? Всё ищешь серебряную пулю? Успехов в поисках, тогда.

8.31, timur.davletshin (ok), 18:16, 04/05/2022 [^] [^^] [^^^] [ответить]	+/–
Господин, вы бредите Когда-нибудь на досуге попробуй джиттер померять в userspa... текст свёрнут, показать

9.34, Аноним (-), 18:37, 04/05/2022 [^] [^^] [^^^] [ответить]	–1 +/–
Нет ты Во-первых, VPN и HTTPS -- это разные протоколы под разные задачи Если т... большой текст свёрнут, показать

10.37, timur.davletshin (ok), 19:42, 04/05/2022 [^] [^^] [^^^] [ответить]	+/–
Читай внимательно, что я написал Мне до твоего HTTPS дела нет, я писал про упра... текст свёрнут, показать

11.56, Онаним (?), 09:40, 06/05/2022 [^] [^^] [^^^] [ответить]	–1 +/–
Вирегад в ядро вытащен только по одной причине, по той же, по которой опенжпн св... текст свёрнут, показать

12.57, timur.davletshin (ok), 10:14, 06/05/2022 [^] [^^] [^^^] [ответить]	+/–
Т е QUIC в таком случае не должен существовать Спасибо, что хоть на таком уров... текст свёрнут, показать

13.58, Онаним (?), 13:49, 06/05/2022 [^] [^^] [^^^] [ответить]	+/–
Клюк в ядре не нужен Он вполне может существовать в юзерспейсе - пакеты приходя... текст свёрнут, показать

14.59, timur.davletshin (ok), 15:43, 06/05/2022 [^] [^^] [^^^] [ответить]	+/–
А чё он тогда на 30 жручее до CPU В чём профит тогда В обновляемости congesti... текст свёрнут, показать

15.60, Онаним (?), 17:06, 06/05/2022 [^] [^^] [^^^] [ответить]	+/–
Жручее по сравнению с чем ... текст свёрнут, показать

16.62, timur.davletshin (ok), 18:56, 06/05/2022 [^] [^^] [^^^] [ответить]	+/–
В сравнении с TCP ... текст свёрнут, показать

17.63, Онаним (?), 19:21, 06/05/2022 [^] [^^] [^^^] [ответить]	+/–
Э, а ничего, что там SSL сверху Тогда уж с HTTPS сравнивай ... текст свёрнут, показать

18.64, timur.davletshin (ok), 21:45, 06/05/2022 [^] [^^] [^^^] [ответить]	+/–
Сравнивали и не один раз https www fastly com cimages 6pk8mg3yh2ee 495gZP7Zpr... текст свёрнут, показать

19.65, Онаним (?), 22:04, 06/05/2022 [^] [^^] [^^^] [ответить]	+/–
Опять какое-то тёплое с мягким Можно CPU usage при одинаковом throughput, а не ... текст свёрнут, показать

20.67, timur.davletshin (ok), 22:25, 06/05/2022 [^] [^^] [^^^] [ответить]	+/–
Можно https conferences sigcomm org sigcomm 2020 files slides epiq 0 20QUIC 2... текст свёрнут, показать

21.68, Онаним (?), 18:20, 08/05/2022 [^] [^^] [^^^] [ответить]	+/–
Опять какие-то сферические гуглы в вакууме Но даже если попытаться из этой ахин... текст свёрнут, показать

21.69, Онаним (?), 18:22, 08/05/2022 [^] [^^] [^^^] [ответить]	+/–
Но кстати вот эта смузи-презенташка моё предположение подтвердила неожиданно, ра... текст свёрнут, показать

19.66, Онаним (?), 22:06, 06/05/2022 [^] [^^] [^^^] [ответить]	+/–
К слову, в том, что кряк - говно, я не сомневаюсь ни разу Но там дело не в том,... текст свёрнут, показать

15.61, Онаним (?), 17:06, 06/05/2022 [^] [^^] [^^^] [ответить]	+/–
И да, всё правильно В обновляемости алкоритмов, написанных с бодуна под смузи ... текст свёрнут, показать

10.38, timur.davletshin (ok), 19:47, 04/05/2022 [^] [^^] [^^^] [ответить]	+/–
Разрабы Google, выходит, у тебя лохи печальные, а в Wireguard ну просто гении Д... текст свёрнут, показать

4.24, Аноним (7), 16:44, 04/05/2022 [^] [^^] [^^^] [ответить]	+/–
Скажи это провайдерам.

5.28, Мохнатый пись (?), 17:20, 04/05/2022 [^] [^^] [^^^] [ответить]	+/–
Говорю каждый раз, пора бы уже ipv6 внедрять. Внедрение ipv6 во всём постсовсовке на уровне стран африки.

6.45, Онаним (?), 23:58, 04/05/2022 [^] [^^] [^^^] [ответить]	+/–
Открою тебе секрет - и не только в постсовке. У нас есть полтора пользователя IPv6, Европа, причём западная. Они даже им вроде как пользуются. Но абсолютное и подавляющее большинство им не интересуется вообще. Не взлетело.

6.46, Онаним (?), 00:00, 05/05/2022 [^] [^^] [^^^] [ответить]	+/–
(нет, мы можем всем выдать по /64 автоматом, и даже пробовали на все серверы его развесить (не зашло, поубирали) - и после бодро отрапортоваться о 100% пенетрации, но клиентам от этого будет только хуже - жалобы на откровенно хреновую работу при попытке подобное делать были, есть, и будут есть)

7.47, Онаним (?), 00:02, 05/05/2022 [^] [^^] [^^^] [ответить]	+/–
А не зашло потому, что какому-то <beep> пришло в дурную голову AAAA при резолве DNS сделать приоритетным. В итоге некоторые внешние юзеры того же хостинга начинают вместо 30-40мс отклика иметь 80-120, а то и вообще ничего не иметь, и начинают жаловаться.

8.49, Мохнатый пись (?), 00:34, 05/05/2022 [^] [^^] [^^^] [ответить]	+1 +/–
Кулстори какие-то Сижу через туннель, ибо провайдер дебил, пинг из-за европейск... текст свёрнут, показать

9.51, Онаним (?), 22:05, 05/05/2022 [^] [^^] [^^^] [ответить]	+1 +/–
Эдак у вас число пользователей уменьшаться начнёт, а не вырастет ... текст свёрнут, показать

9.52, Онаним (?), 22:21, 05/05/2022 [^] [^^] [^^^] [ответить]	+/–
Ну а чего кулстори Есть провайдеры в местных ну, не местных, соседние страны ... текст свёрнут, показать

10.53, Онаним (?), 22:22, 05/05/2022 [^] [^^] [^^^] [ответить]	+/–
Это сейчас ещё хецнеровские туннели убились - стало полегче, раньше можно было л... текст свёрнут, показать

1.15, pashev.ru (?), 15:40, 04/05/2022 [ответить] [﹢﹢﹢] [ · · · ]	+1 +/–
Теперь народ начнёт понимать, почему glibc такая "жирная" 🙂

2.32, Аноним (32), 18:20, 04/05/2022 [^] [^^] [^^^] [ответить]	–1 +/–
Думаешь в glibc нет бэкдоров? Поверь мне, их там еще больше.

3.39, Онаним (?), 19:53, 04/05/2022 [^] [^^] [^^^] [ответить]	+/–
Системы с glibc обычно не проблема обновить. А вот то, где uclibc - многое из этого уже (древнющее и не очень) легаси, в т.ч. разряда хоаксного iot, для которого вендор прошивку выпускать уже не будет, да и есть ли он.

4.41, Аноним (41), 22:31, 04/05/2022 [^] [^^] [^^^] [ответить]	+/–
Обновишь и получишь еще больше бэкдоров, руткитов, вирусов, телеметрии, малвари и фингерпринтинга. Сомнительное преимущество.

5.42, Онаним (?), 22:33, 04/05/2022 [^] [^^] [^^^] [ответить]	+1 +/–
Всё ещё сидишь на ядре 2.0?

2.35, Аноним (-), 18:44, 04/05/2022 [^] [^^] [^^^] [ответить]	+/–
Все кто любят юникс, первым делом выпиливают юниксовые "убства" в первую очередь. Либси должна содержать наборчик макросов 90% скопипащеных с ядра и неболее ящитаю.

1.40, Аноним (40), 21:30, 04/05/2022 [ответить] [﹢﹢﹢] [ · · · ]	+1 +/–
Гордый суффикс "-ng" прикрутили, а на прикрутить рандом "не в состоянии исправить"? :D

игнорирование участников | лог модерирования

Добавить комментарий

Текст: