Realtek sdk что это

Уязвимости в SDK Realtek ставят под угрозу оборудование от 65 производителей

Уязвимости могут затрагивать устройства AsusTEK, Belkin, D-Link, Edimax, Hama, Logitech и Netgear.

Тайваньский производитель чипов Realtek сообщил о четырех уязвимостях в трех SDK своих сопутствующих модулей Wi-Fi, использующихся почти в 200 продуктах от более полусотни поставщиков.

Уязвимости позволяют удаленному неавторизованному атакующему вызывать отказ в обслуживании, выводить из строя устройства и внедрять произвольные команды.

CVE-2021-35392 – переполнение буфера в стеке через UPnP в Wi-Fi Simple Config;

CVE-2021-35393 – переполнения кучи через SSDP в Wi-Fi Simple Config;

CVE-2021-35394 – внедрение команд в инструменте для диагностирования MP Daemon;

CVE-2021-35395 – множественные уязвимости в web-интерфейсе управления.

Первые две уязвимости получили оценку 8,1 балла из максимальных 10 по шкале оценивания опасности CVSS, а вторые – 9,8 балла. Для их эксплуатации злоумышленник должен находиться в той же сети, что и устройство, или иметь доступ к нему через интернет.

Обнаружившая уязвимости немецкая компания IoT Inspector уведомила о них Realtek в мае нынешнего года, и производитель незамедлительно выпустил исправления.

С помощью данных уязвимостей удаленный неавторизованный злоумышленник может полностью скомпрометировать атакуемое устройство и выполнить произвольный код с привилегиями наивысшего уровня.

По словам специалистов, в продуктах более 65 производителей (в том числе AsusTEK, Belkin, D-Link, Edimax, Hama, Logitech и Netgear) используется модуль Realtek RTL819xD с функцией беспроводной точки доступа и одним из уязвимых SDK. В частности, уязвимости затрагивают Realtek SDK v2.x, Realtek “Jungle” SDK v3.0/v3.1/v3.2/v3.4.x/v3.4T/v3.4T-CT и Realtek “Luna” SDK до версии 1.3.2. Первому SDK уже 11 лет и он больше не поддерживается, а для второго готовы исправления, но их придется бэкпортировать. Для новых “Luna” SDK 1.3.2a все патчи полностью готовы.

Источник

Знакомство с возможностями свитч-процессора Realtek RTL 8332M

Мы продолжаем серию публикаций об электронных компонентах тайваньской компании Realtek, которые можно использовать для разработки мультимедийной и сетевой электроники.

На днях в нашем распоряжении оказалась демо-плата многопортового коммутатора RTL_8332M_DDR3_DEMO_P2L_V1.0 на базе свитч-процессора Realtek 8332M, а также фирменный комплект средств разработки. Под катом мы расскажем, что собой представляет эта плата, опишем процесс сборки и загрузки прошивки на основе Realtek SDK, а также протестируем пропускную способность полученного коммутатора с проверкой работоспособности QoS.

Демо-плата предназначена для разработки и отладки ПО для управляемого многопортового коммутатора c 24 портами Fast Ethernet и 4 портами Gigabit Ethernet. Основа используемых свич-процессоров — CPU MIPS-4KEc 32bit@500MHz, они позволяет управлять всеми функциями коммутатора.

Возможно, у читателя возникнет вопрос: для чего в наше время, «когда космические корабли бороздят просторы вселенной» может понадобиться разработка коммутатора Fast Ethernet. На наш взгляд, данное недорогое решение может быть востребовано в системах, где не требуется высокая скорость передачи данных. Например, подключение IP-телефонии и камер видеонаблюдения.

Функционал L2 VLAN

Максимальное количество VLAN 4096
Поддержка до 64 независимых процессов для MSTP (IEEE 802.1s), RSTP и STP
Тегирование Q-in-Q и VLAN

Длина сетевых пакетов до 10 КБ
Таблица на 8K L2 MAC-адресов
Таблица на 512 мультикаст-адресов
Поддержка IGMPv1/2/3 и MLDv1/2 snooping

Другая функциональность уровня L2

Контроль трафика broadcast, multicast, unknown- multicast и unknown-unicast
Поддержка зеркалирования траффика
Поддержка агрегации каналов (IEEE 802.3ad)
Поддержка распознавания и изоляции закольцованного траффика (RLPP/RLDP)

Функционал Access Control List (ACL)

Поддержка формата L2/L3/L4 (DMAC, SMAC и Ether-Type)
IPv6 ACL

8 очередей на порт
Обработка очередей по алгоритмам Strict Priority (SP), Weighted Fair Queue (WFQ) и Weighted Round Robin (WRR)

Комплект поставки RTL_8332M_DDR3_DEMO_P2L_V1.0

На фото ниже представлен вид платы сбоку, на нем хорошо видно порты:

Полученные нами средства разработки включают в себя toolchain, SDK с исходниками Linux и u-boot, а также некоторую документацию.

Сборка прошивки из Realtek SDK

Распаковываем toolchain и сразу прописываем пути к нему в PATH, чтобы bash знал, где его искать:

Распаковываем SDK, а также исходники u-boot и uClinux:

Выбираем версию linux и uClibc:
В SDK было 2 версии ядра Линукс – 2.6.19 и 2.6.32.58. С версией ядра 2.6.19 используется uClibc 0.9.28, а с версией 2.6.32.58 – uClibc 0.9.30. Мы использовали последнюю версию.

С версией ядра 2.6.19 используется uClibc 0.9.28, а с версией 2.6.32.58 – uClibc 0.9.30.

В настройках SDK включаем поддержку свитч-процессора 8332M:

В опциях Chip Support и SDK Driver указываем чип 8380:

В menuconfig-е ядра нужно изменить параметры загрузки на ”debug console =ttyS0,115200 mem=128M”, т.к. у нас используется чип с 128M памяти:

Сборка (сборка проходит успешно только с правами рута, поэтому нужно экспортировать вышеуказанные пути также и в PATH рута):

При сборке, не смотря на проведенную настройку в menuconfig-е, в консоль высыпается пара вопросов по настройке RTK BSP. Указываем чип 8380:

Если всё сработало, на экране выводится информация о собранном образе, результаты сборки кладутся в image/:

Загрузка собранного ядра

1) На хосте необходимо установить сервер tftp. Установка и настройка например под Ubuntu описана здесь: http://askubuntu.com/questions/201505/how-do-i-install-and-run-a-tftp-server.

2) В расшаренную через tftp папку скинуть собранный образ ядра:

3) Подключиться к плате через UART, настройки для minicom следующие:

4) На плате грузится u-boot, нужно из него загрузить собранное ядро через tftp:

После загрузки Линукса запускаем DiagShell – command line interface для управления настройками свича.
В нем включаем нужные порты (или все):

Прошивка запущена, коммутатор работает.

Тестирование скорости

Замеры скорости мы проводили, подключив к плате 2 ПК c помощью программы iperf в двух режимах –LAN- и VLAN-подключение свича.

Через DiagShell VLAN был настроен следующим образом (например, настройка для портов 25, 26, 27 и vlan >
При тестировании VLAN проявляется интересный эффект: если VLAN настроить на диапазон портов, включающий порты 100М и 1000М, то скорость будет ограничена на уровне 100 Мбит/с, даже если оба ПК подключены в гигабитные порты.

Вот такие получились результаты тестирования:

Можно сказать, что пропускная способность соответствует заявленной.

Теперь попробуем настроить QoS. Данная функция очень пригодится при настройке офисной IP-телефонии.

Как мы уже говорили, коммутатор поддерживает два алгоритма обработки очередей: Strict Priority и WFQ.
Мы ограничились проверкой Strict Priority. Для проверки подключили к плате три ПК. На одном из ПК запустили iperf-сервер:

На двух других ПК — клиенты:

Результаты замеров пропускной способности показали, что трафик распределился примерно поровну.
Теперь попробуем настроить QoS. Для этого зададим для DSCP 0x8 максимальное значение приоритета (7).

В результате маркированный трафик занял всю полосу пропускания. Что ж, похоже, QoS действительно работает.

Добавим несколько слов про DiagShell. На наш взгляд, этот CLI довольно функционален и вполне может использоваться при разработке готового устройства. Конечно, в идеале хотелось бы иметь некий интуитивный веб-интерфейс, который на данный момент отсутствует в SDK. Для конечного устройства его придется разрабатывать.

В целом можно сказать, что в результате мы получили тестовую плату многопортового коммутатора с возможностью разработки ПО. Такую программно-аппаратную платформу можно использовать для разработки недорогих управляемых коммутаторов Fast Ethernet для подключения к основной сети через порты Gigabit Ethernet.

Источник

Миллионы IoT-устройств в опасности из-за багов, найденных в Realtek Wi-Fi SDK

Xakep #271. Сила четырех байтов

Тайваньский производитель Realtek предупредил о четырех уязвимостях, обнаруженных в трех SDK для модулей Wi-Fi. Данные модули используются почти в 200 моделях IoT-устройств как минимум 65 производителей.

Обнаруженные недостатки затрагивают Realtek SDK v2.x, Realtek Jungle SDK v3.0, v3.1, v3.2, v3.4.x, v3.4T, v3.4T-CT, а также Realtek Luna SDK вплоть до версии 1.3.2. Данные баги можно было использовать для полной компрометации целевого устройства и выполнения произвольного кода с наивысшим уровнем привилегий.

В перечисленных SDK были найдены следующие уязвимости:

Эти проблемы могут представлять угрозу для множества устройств, использующих Wi-Fi модули компании. В их числе: роутеры для путешествий, Wi-Fi репитеры, IP-камеры для шлюзов lightning, «умные» игрушки и другие девайсы таких как производителей как AIgital, ASUSTek, Beeline, Belkin, Buffalo, D- Link, Edimax, Huawei, LG, Logitec, MT-Link, Netis, Netgear, Occtel, PATECH, TCL, Sitecom, TCL, ZTE, Zyxel, а также собственная линейка маршрутизаторов Realtek.

Исследователи немецкой компании IoT Inspector, обнаружившие баги, пишут, что общее количество уязвимых устройств близко или превышает миллион, так как в среднем было продано около 5000 копий каждого уязвимого девайса. Список проблемных гаджетов можно найти в блоге компании.

Сообщается, что найденные проблемы присутствовали в кодовой базе Realtek более десяти лет. В настоящее время уязвимости исправлены, однако дойдут ли патчи до конечных устройств и как быстро это произойдет, остается лишь догадываться.

Источник

Ботнет атакует уязвимые устройства с Realtek SDK на борту

Xakep #271. Сила четырех байтов

Специалисты компании SAM, специализирующейся на безопасности IoT-устройств, обнаружили ботнет, атакующий устройства, использующие SDK Realtek, в которых недавно нашли уязвимости.

Напомню, что баги в SDK Realtek были найдены компанией IoT Inspector, и они затрагивают около миллиона устройств, в числе которых: роутеры для путешествий, Wi-Fi репитеры, IP-камеры для шлюзов lightning, «умные» игрушки и другие девайсы. Суммарно уязвимы более 200 моделей как минимум 65 поставщиков, включая AIgital, ASUSTek, Beeline, Belkin, Buffalo, D- Link, Edimax, Huawei, LG, Logitec, MT-Link, Netis, Netgear, Occtel, PATECH, TCL, Sitecom, TCL, ZTE, Zyxel, а также собственную линейку маршрутизаторов Realtek.

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

Наиболее серьезным из найденных багов смело можно назвать уязвимость CVE-2021-35395, которая набрала 9,8 балла из 10 возможных по шкале CVSS. Данная проблема позволяет удаленному злоумышленнику подключаться к веб-панели, используя искаженный URL-адрес, обходить аутентификацию и запускать вредоносный код с наивысшими привилегиями.

Хотя Realtek выпустила патчи за день до того, как представители IoT Inspector опубликовали результаты своих исследований, этого времени не хватило, чтобы поставщики устройств успели развернуть обновления. То есть подавляющее большинство проблемных устройств по-прежнему используют устаревшую прошивку (и устаревший Realtek SDK), и уязвимы перед атаками. По данным SAM, чаще всего в сети встречаются следующие уязвимые девайсы:

Аналитики SAM пишут, что теперь уязвимые девайсы атакует тот же ботнет на базе Mirai, который недавно был замечен в атаках на устройства с прошивкой Arcadyan.

Источник

Запуск Linux на медиапроцессоре Realtek RTL-1185

Попалась нам сегодня в руки отладочная плата на базе SoC RTD1185 — RTK300 Rev. C1 — для разработки мультимедийных устройств. В рамках этой статьи мы познакомимся с техническими параметрами этой SDK, cоберем и запустим на ней базовое ядро Linux и rootfs, успешно решив в процессе несколько проблем.

Disclaimer: данная статья рассчитана на опытных линуксоидов, по крайней мере, мы не останавливались на второстепенных подробностях. Если возникнут вопросы, добро пожаловать в комментарии.

Данная система на кристалле от наших друзей из Realtek c кодовым названием Jupiter, как и её брат RTD1186, предназначена для мультимедийных приложений, которые декодируют видео в форматах HD MPEG 1/2/4, H.264, VC1, RM/RMVB. Также в медиапроцессоре реализована поддержка разъемов USB 2.0 и SATA, шины PCI-Express и сетевого интерфейса Gigabit Ethernet.

Наличие Ethernet в связке с соответствующим сетевым контроллером обеспечивает возможность передачи данных по проводной сети со скоростью до 1 Гбит/с. Хоть данное устройство имеет по современным меркам небольшую частоту CPU, но этот параметр компенсируется мощными декодерами видео, что вполне оправдывает использование данного чипа в мультимедиа приложениях.

Комплект Realtek RTL-1185

Плата идет в комплекте с ИК-пультом дистанционного управления. От Realtek был получен «полурабочий» SDK, который якобы должен был решить все проблемы со сборкой прошивки. «Полурабочим» мы его назвали потому, что у нас получилось собрать без «бубна» linux-2.6.12 и базовую rootfs. Но когда дело дошло до приложений аудио- и видеоплеера, пришлось все-таки взять «бубен». Ну что же, и на этом спасибо. Кит изображен на фотографии ниже.

Работаем с китом

Ну что же, мы познакомились с платой, попробуем что-нибудь на ней запустить. Изначально на ките стояла прошивка Realtek, по всей видимости, она работала поверх QT4.7.

Когда мы получили этот SDK, казалось, что все — птица в кармане. Но не тут то было. Собирается, конечно, не все. Документации нет ни к отладочной плате, ни к самой системе на кристалле (SoC). Гугл тоже не помог. Но об этом далее.

Получаем консоль

С помощью осциллографа была выяснена распиновка UART на плате (возле кнопки восстановления): (USB HOST) GND – RX — TX — VCC.

Подключаемся с помощью minicom на хосте:

Включаем плату и нас встречает «приветливый» загрузчик:

После чего начинается загрузка ядра.

Что примечательно, firmware загружаются не драйвером в память, а самим загрузчиком.

Обновление прошивки

Ладно, что поделать. Пробуем по-другому.

Эту защиту можно обойти кривохаками, но нам пока это не нужно. Если кому-то интересно, то у утилиты прошивки loader_a есть аргумент — nonsecure который отключает проверку хэшем. Но для этого нужно собрать busybox для данной платформы и скопировать его тоже на USB-накопитель, загрузить плату в recovery-режиме и в shell’e линукс на ките выполнить:

Busybox пришлось собирать, потому что в recovery initramfs нету ничего, чем можно было бы кильнуть процесс loader_a. Но это не основная причина. С ним было намного проще изучить внутренности recovery-режима, используя тот же ash, ls, cat из его состава, чем без них.

Собираем базовое ядро Linux и rootfs

Ядро копируем на tftp сервер в /srv/tftp/vmlinux.develop.avhdd.jupiter.nand.loongtle.bin.

Запускаем сервера tftp и nfs на хосте. Конфигурируем NIC хоста подключенный по ethernet к отладочной плате: Ipv4 192.168.0.1/24.

Запуск свежесобранного Linux

Перезагружаем плату и сразу же зажимаем ESC для того, чтобы перейти в monitor-режим:

Commandline загрузчика немного напоминает uboot, но это не он. Видно, что можно выгрузить файл по tftp, что мы и сделаем чтобы выгрузить ядро Linux из сети.

Таким образом, мы получили базовую рабочую систему.

Что дальше?

Попытаться собрать QT, gstreamer. Найти и собрать в SDK или разработать cамостоятельно плагины для gstreamer для использования аппаратных декодеров. Возможно, придется избавиться от сборочной системы в SDK в пользу Buildroot. О чем еще, возможно, придется написать — шифрование ядра и firmware. Но это уже другая история для другой части статьи.

Источник