В системе сборки Buildroot, нацеленной на формирование загрузочных Linux-окружений для встраиваемых систем, выявлены шесть уязвимостей, позволяющих в ходе перехвата транзитного трафика (MITM) добиться внесения изменений в генерируемые системные образы или организовать выполнение кода на уровне сборочной системы. Уязвимости устранены в выпусках Buildroot 2023.02.8, 2023.08.4 и 2023.11...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60270
> выявлены шесть уязвимостей, позволяющих в ходе перехвата транзитного трафика (MITM) добиться внесения изменений в генерируемые системные образы или организовать выполнение кода на уровне сборочной системы.какая-то чушь от свидетелей безопаснсти, во первых пакетики без хешей только совсем малонужные и неиспользуемые - поэтому и нет хешей, и что мешает легально добавить сборочный сценарий с валидными хешами но с неизвестным содержимым в исходниках, как будто кто-то там проверяет все сценарии make
Там эпичность в том, что тулчейн RISC-V как самый "модно-молодежный" входит в набор, которым пользуются 80% меинтейнеров тамошних пакетов при локальном тестировании сборок.Ну а хеши этого горе-тулчейна там дропнули, ибо задолбались менять (и коммитить эти изменения в репу), так как ночвые бага-фичи в тулчейн добавляются быстрее чем исправляются старые.
> пользуются 80% меинтейнеров тамошних пакетов при локальном тестировании сборокони в контейнерах и виртуалках тестируют
> они в контейнерах и виртуалках тестируютЭто спасает от шуток типа "rm -rf /", но никак не от более-менее приличной целевой атаки.
Тут почти 100% вероятность возможности пробития и компрометации всей инфраструктуры buildroot, включая 50% мэинтейнеров.
Другое дело, что (скорее всего, пока еще) это никому не было нужно.
Хотя мэинтейнеров я бы подергал за причинные места - и для профилактики, ну и ради баловства.
> Тут почти 100% вероятность возможности пробития и компрометации всей инфраструктуры buildroot, включая 50% мэинтейнеров.каким образом если каждая запущенная сборочная задача тестирует свою локальную копию ?
https://linuxembedded.fr/2022/01/buildroot-gitlab-ci-testing
кросскомпилятор riscv вообще для барметал - сборку пакетов на нём не тестируют, он их просто не соберёт
https://gitlab.com/buildroot.org/buildroot/-/commit/58d7c712...
> каким образом если каждая запущенная сборочная задача тестирует свою локальную копию ?Не образом, а подсвешником ;)
Например, пробивается через:
- подстановку payload по статусу сборок в gitlab (периодически находят и фиксят, сейчас вроде-бы чисто);
- подстановку payload для пробития при разоре заголовков в proxy между серверами c CI-агентами и самим gitlab;
- эскалацию привилегий с пробитием через какой-нибудь драйвер/шлюз/namespace;
- побег из виртуалки, суммарно примерно десяток способов;
- а половина меинтейнеров запускает сборку просто на рабочей машине, это вообще примерно везде так... (а собрав ключи можно вообще всю инфраструктуру застелсить/заруткитеть).В целом, пока не показаны положительные результаты приличного аудита, можно считать что рeшет0.
За >10 лет практики ни разу не видел иначе.
Погуглите хвастовство Positive Technologies, Digital Security, Group-IB, Касперов и т.д.> кросскомпилятор riscv вообще для барметал - сборку пакетов на нём не тестируют, он их просто не соберёт
Buildroot он как-бы в принципе для bare metal и традиционных deb/rpm пакетов там нет.
А "пакеты" (ну или как их назвать) собираются именно тулчейнами для конечных платформ -- это примерно 90% объема "тестирования" как такового.
Где-то есть запуск тестов под qemu, кто-то из меинтейнеров использует железо, но в основном просто производится сборка, а тесты по конкретным жалобам пользователей.
> Buildroot он как-бы в принципе для bare metal и традиционных deb/rpm пакетов там нет.ты конкретно не понимаешь - есть кросскомпилятор для сборки для Linux а есть для bare metal, линуксовым можно собрать барметал а наборот - нет, этот барметал компилятор для конкретного загрузчика от процессора sifive потому что он какой-то кривой и линуксовым не собирается
> This commit adds a new package for a prebuilt bare-metal toolchain for
> RISC-V 64-bit. Indeed, some bootloader/firmware for the BeagleV (and
> potentially later for other platforms?) do not build with a
> Linux-capable toolchain.
> ты конкретно не понимаешьНу..., вы не спешите делать столь смелые выводы и давать ненужные пояснения.
Теоретически ничего не мешает подменить toolchain, встроив в него генерацию специфических гаджетов/дыр для целевого кода RISC-V (ибо количество специфических расширений, добавлений и т.п. обеспечивает необходимые предусловия).
Это отдельный вектор атаки, про который я вангую уже более 5 лет.Но первичный вектор атаки намного проще -- встроить троян в код самого тулчейна, который 50% меинтейнеров запускает на рабочей машине с x86 ;)
> Теоретически ничего не мешает подменить toolchainа как практически выполняют MITM на gitlab были примеры ?
> встроить троян в код самого тулчейна, который 50% меинтейнеров запускает на рабочей машине с x86 ;)
надо ещё sifive взломать или принести майнтейнеру на флешке
> а как практически выполняют MITM на gitlab были примеры ?Гуглите.
Были дыры (уже пофикшены), были примеры...> > встроить троян в код самого тулчейна, который 50% меинтейнеров запускает на рабочей машине с x86 ;)
> надо ещё sifive взломать или принести майнтейнеру на флешкеЗачем ?
Для тех кто в танке:
- есть набор тестов запускаемых скриптом;
- в одном из тестов скачивается упомянутый тулчейн и запускается без верификации;
- 50% меинтейнеров запускали, запускают и будут запускать всё это на своих ноутбуках.Короче, просто warez только легально.
> в одном из тестов скачивается упомянутый тулчейн и запускается без верификации;КАК подменить тулчейн на сервере sifive или в хранилище buildroot ? ты ходишь по кругу: чтобы совершить атаку надо подменить тулчейн чтобы совершить атаку. Я уж молчу что у майнтейнеров он давно скачан и лежит локально - нахер им по сто раз его скачивать, версия у него не менялась с момента появления этого пакета - откуда взялись фантазии про постоянную смену хеша я хз.
Лучше прочитайте текст новости еще раз.Но в принципе можно и согласиться с формулировкой, что в CVE ерунда ;)
> Лучше прочитайте текст новости еще раз.
> позволяет подменить содержимое данных пакетов, имея возможность вклиниться в трафик
> сборочного сервера (например, при подключении пользователя через беспроводную сеть,
> контролируемую атакующим)какая б..ть беспроводная сеть на гитлабе. Шансов использовать это примерно ноль.
>> пользуются 80% меинтейнеров тамошних пакетов при локальном тестировании сборок
> они в контейнерах и виртуалках тестируютИ, собственно, чего? Запустить майнер, спамер или ддосер на виртуалке ничуть не хуже чем на железке.
> Запустить майнер, спамер или ддосер на виртуалке ничуть не хуже чем на железке.осталось рассказать как это сделать
Мы забор ставим только там, где много людей ходит. Где не ходят или один-два изредка пройдёт - там забор не нужен.
Занятная структура, читаешь - ну проходной двор просто.
Ну дак RISC-V же, как задумано ;)
>возможности использования HTTP для загрузки файловНужно было просто дропнуть поддержку http без s. Хочешл грузить, не пользуясь чужими CA? Создай свой CA и залей серт. Не хочешь? Ну знаешь, куда идти.
Надо отдавать http/80 только по субдомену http, а на www, корень оставить только HTTPS.Хотя... митму ничто не мешает вклиниться в "отключенный" 80-ый порт. Вот вроде был certificate pinning :/ А постоянные редиректы вряд ли прикладным софтом запоминаются.
Нахрена такие извращения? Просто не TLS дропнуть и всё. Я уже много лет в TLS-only режиме. Поначалу с помощью HE, сейчас - нативно. HE правда зря дропнули. Их дэйтасет был полезен для массового автоматического переписывания ссылок в гитхаб-рееозиториях.
> дэйтасетКазалось бы, как можно настолько извратить простое и лаконичное "набор данных" / "база данных" / "база знаний"
Без дэйтасэтов не грести вам деньги дэйтасаентиста. Смузи - прошлое десятилетие.
Я же сам написал почему. Софт сам откатывается с 443 на 80. Ну или как минимум не перехрдит на 443. Значит MITM такое и будет провоцировать. Будь у вас хоть трижды только TLS1.2 включен.Про HTTPS Everywhere хорошая идея, запомню.
Вы простите, надеюсь вы меня услышите: что ваше решение - крайность, имхо, что оригинальное "нет хеша? Так просто его не проверяем".
У вас - "просто отрезать возможность https".
В оригинале - "сбилдить во чтобы-то не стало".
То, что вы предлагаете, это, кажется, нынче называется технофашизм? Т.е. "мне пох, как у вас там что, теперь только tls и сношайтесь как хотите". Решение неплохое, строгое... но радикальное.
Кажется, норм дефолтным вариантом было бы "всегда https, всегда проверять хеши, если хешей нет, стопиться". А для тех, кому это не подходит, возможность выставить ключики типа --https-only=false и skip-no-hash=true?
>пакеты aufs и aufs-util загружались по HTTP и не проверялись по хэшам
>Некоторые пакеты, такие как ядро Linux, U-Boot и versal-firmware, допускали загрузку последних версий, для которых ещё не сформированы проверочные хэшиИ как использование безопасных языков поможет боротся с такими уязвимостями?
Безопасных ножей не бывает. Только некоторые их типы чаще соскальзывают, когда не ждешь.
Все просто, мы просто перехватим ваш код встроенный в http(образно:) ) и скажем ошибка.
В безопасных языках такое поведение в принципе нормальное и допустимо в тулинге языка. Чтобы было проще и просто работало.
Ещё шесть уязвимостей публиковать не стали, сами пользуются.
Да остальные за деньги.
> позволяющих в ходе перехвата транзитного трафика (MITM) добиться внесения изменений в генерируемые системные образыа как это происходит - хаекры вычисляют сборщика buildroot, едут к нему из другой страны, нейтрализуют соседей и ждут в их квартире когда он начнёт прошивку собирать чтобы митмить его вафай ? а если он в текущем году не намерен собирать - ворвутся к нему и заставят собирать чтобы помитмить ?