forum.opennet.ru - "Уязвимости в Buildroot, позволяющие через MITM-атаку выполнить код на сборочном сервере" (32)

"Уязвимости в Buildroot, позволяющие через MITM-атаку выполнить код на сборочном сервере"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Уязвимости в Buildroot, позволяющие через MITM-атаку выполнить код на сборочном сервере"	+/–
Сообщение от opennews (??), 11-Дек-23, 15:48
В системе сборки Buildroot, нацеленной на формирование загрузочных Linux-окружений для встраиваемых систем, выявлены шесть уязвимостей, позволяющих в ходе перехвата транзитного трафика (MITM) добиться внесения изменений в генерируемые системные образы или организовать выполнение кода на уровне сборочной системы. Уязвимости устранены в выпусках Buildroot 2023.02.8, 2023.08.4 и 2023.11... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60270
Ответить \| Правка \| Cообщить модератору

Оглавление

какая-то чушь от свидетелей безопаснсти, во первых пакетики без хешей только сов, Аноним (1), 15:48 , 11-Дек-23, (1) –2

Там эпичность в том, что тулчейн RISC-V как самый модно-молодежный входит в на, 007 (??), 21:52 , 11-Дек-23, (12)

они в контейнерах и виртуалках тестируют, Аноним (14), 22:25 , 11-Дек-23, (14)

Это спасает от шуток типа rm -rf , но никак не от более-менее приличной целев, 007 (??), 13:01 , 12-Дек-23, (22)

каким образом если каждая запущенная сборочная задача тестирует свою локальную к, Аноним (14), 13:58 , 12-Дек-23, (23)

Не образом, а подсвешником Например, пробивается через - подстановку payload , 007 (??), 14:45 , 12-Дек-23, (24)

ты конкретно не понимаешь - есть кросскомпилятор для сборки для Linux а есть для, Аноним (14), 14:58 , 12-Дек-23, (25)

Ну , вы не спешите делать столь смелые выводы и давать ненужные пояснения Теор, 007 (??), 15:13 , 12-Дек-23, (26)

а как практически выполняют MITM на gitlab были примеры надо ещё sifive взломат, Аноним (14), 15:20 , 12-Дек-23, (27)

Гуглите Были дыры уже пофикшены , были примеры Зачем Для тех кто в танке - , 007 (??), 15:40 , 12-Дек-23, (28)

КАК подменить тулчейн на сервере sifive или в хранилище buildroot ты ходишь по, Аноним (14), 15:52 , 12-Дек-23, (29)

Лучше прочитайте текст новости еще раз Но в принципе можно и согласиться с форму, 007 (??), 17:04 , 12-Дек-23, (30)
какая б ть беспроводная сеть на гитлабе Шансов использовать это примерно ноль , Аноним (14), 17:56 , 12-Дек-23, (31)

И, собственно, чего Запустить майнер, спамер или ддосер на виртуалке ничуть не , Аноним (-), 09:37 , 13-Дек-23, (33)

осталось рассказать как это сделать, Аноним (14), 12:13 , 13-Дек-23, (34)

Мы забор ставим только там, где много людей ходит Где не ходят или один-два изр, YetAnotherOnanym (ok), 22:27 , 11-Дек-23, (15) +3

Занятная структура, читаешь - ну проходной двор просто , Аноним (2), 15:49 , 11-Дек-23, (2) +3

Ну дак RISC-V же, как задумано , 007 (??), 21:54 , 11-Дек-23, (13) +3

Нужно было просто дропнуть поддержку http без s Хочешл грузить, не пользуясь чу, Аноним (3), 16:07 , 11-Дек-23, (3)

Надо отдавать http 80 только по субдомену http, а на www, корень оставить только, Электрон (?), 17:46 , 11-Дек-23, (5)

Нахрена такие извращения Просто не TLS дропнуть и всё Я уже много лет в TLS-on, Аноним (7), 18:12 , 11-Дек-23, (7)

Казалось бы, как можно настолько извратить простое и лаконичное набор данных , Бывалый смузихлёб (?), 09:44 , 12-Дек-23, (18)

Без дэйтасэтов не грести вам деньги дэйтасаентиста Смузи - прошлое десятилетие , Электрон (?), 09:55 , 12-Дек-23, (20)

Я же сам написал почему Софт сам откатывается с 443 на 80 Ну или как минимум н, Электрон (?), 09:54 , 12-Дек-23, (19)

Вы простите, надеюсь вы меня услышите что ваше решение - крайность, имхо, что о, Аноним (32), 20:13 , 12-Дек-23, (32)

И как использование безопасных языков поможет боротся с такими уязвимостями , Аноним (4), 16:24 , 11-Дек-23, (4) +1

Безопасных ножей не бывает Только некоторые их типы чаще соскальзывают, когда н, Электрон (?), 17:48 , 11-Дек-23, (6)
Все просто, мы просто перехватим ваш код встроенный в http образно и скажем , Alladin (?), 18:33 , 11-Дек-23, (8) –1
В безопасных языках такое поведение в принципе нормальное и допустимо в тулинге , Аноним (10), 21:45 , 11-Дек-23, (10)

Ещё шесть уязвимостей публиковать не стали, сами пользуются , Аноним (9), 20:56 , 11-Дек-23, (9) +3

Да остальные за деньги , Аноним (10), 21:45 , 11-Дек-23, (11)

а как это происходит - хаекры вычисляют сборщика buildroot, едут к нему из друго, Аноним (14), 09:57 , 12-Дек-23, (21) +1

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 11-Дек-23, 15:48 –2 +/–

> выявлены шесть уязвимостей, позволяющих в ходе перехвата транзитного трафика (MITM) добиться внесения изменений в генерируемые системные образы или организовать выполнение кода на уровне сборочной системы.
какая-то чушь от свидетелей безопаснсти, во первых пакетики без хешей только совсем малонужные и неиспользуемые - поэтому и нет хешей, и что мешает легально добавить сборочный сценарий с валидными хешами но с неизвестным содержимым в исходниках, как будто кто-то там проверяет все сценарии make

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #15

2. Сообщение от Аноним (2), 11-Дек-23, 15:49 +3 +/–

Занятная структура, читаешь - ну проходной двор просто.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #13

3. Сообщение от Аноним (3), 11-Дек-23, 16:07 +/–

>возможности использования HTTP для загрузки файлов
Нужно было просто дропнуть поддержку http без s. Хочешл грузить, не пользуясь чужими CA? Создай свой CA и залей серт. Не хочешь? Ну знаешь, куда идти.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #32

4. Сообщение от Аноним (4), 11-Дек-23, 16:24 +1 +/–

>пакеты aufs и aufs-util загружались по HTTP и не проверялись по хэшам
>Некоторые пакеты, такие как ядро Linux, U-Boot и versal-firmware, допускали загрузку последних версий, для которых ещё не сформированы проверочные хэши
И как использование безопасных языков поможет боротся с такими уязвимостями?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #8, #10

5. Сообщение от Электрон (?), 11-Дек-23, 17:46 +/–

Надо отдавать http/80 только по субдомену http, а на www, корень оставить только HTTPS.
Хотя... митму ничто не мешает вклиниться в "отключенный" 80-ый порт. Вот вроде был certificate pinning :/ А постоянные редиректы вряд ли прикладным софтом запоминаются.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #7

6. Сообщение от Электрон (?), 11-Дек-23, 17:48 +/–

Безопасных ножей не бывает. Только некоторые их типы чаще соскальзывают, когда не ждешь.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

7. Сообщение от Аноним (7), 11-Дек-23, 18:12 +/–

Нахрена такие извращения? Просто не TLS дропнуть и всё. Я уже много лет в TLS-only режиме. Поначалу с помощью HE, сейчас - нативно. HE правда зря дропнули. Их дэйтасет был полезен для массового автоматического переписывания ссылок в гитхаб-рееозиториях.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #18, #19

8. Сообщение от Alladin (?), 11-Дек-23, 18:33 –1 +/–

Все просто, мы просто перехватим ваш код встроенный в http(образно:) ) и скажем ошибка.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

9. Сообщение от Аноним (9), 11-Дек-23, 20:56 +3 +/–

Ещё шесть уязвимостей публиковать не стали, сами пользуются.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11

10. Сообщение от Аноним (10), 11-Дек-23, 21:45 +/–

В безопасных языках такое поведение в принципе нормальное и допустимо в тулинге языка. Чтобы было проще и просто работало.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

11. Сообщение от Аноним (10), 11-Дек-23, 21:45 +/–

Да остальные за деньги.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

12. Сообщение от 007 (??), 11-Дек-23, 21:52 +/–

Там эпичность в том, что тулчейн RISC-V как самый "модно-молодежный" входит в набор, которым пользуются 80% меинтейнеров тамошних пакетов при локальном тестировании сборок.
Ну а хеши этого горе-тулчейна там дропнули, ибо задолбались менять (и коммитить эти изменения в репу), так как ночвые бага-фичи в тулчейн добавляются быстрее чем исправляются старые.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #14

13. Сообщение от 007 (??), 11-Дек-23, 21:54 +3 +/–

Ну дак RISC-V же, как задумано ;)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

14. Сообщение от Аноним (14), 11-Дек-23, 22:25 +/–

> пользуются 80% меинтейнеров тамошних пакетов при локальном тестировании сборок
они в контейнерах и виртуалках тестируют

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #22, #33

15. Сообщение от YetAnotherOnanym (ok), 11-Дек-23, 22:27 +3 +/–

Мы забор ставим только там, где много людей ходит. Где не ходят или один-два изредка пройдёт - там забор не нужен.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

18. Сообщение от Бывалый смузихлёб (?), 12-Дек-23, 09:44 +/–

> дэйтасет
Казалось бы, как можно настолько извратить простое и лаконичное "набор данных" / "база данных" / "база знаний"

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #20

19. Сообщение от Электрон (?), 12-Дек-23, 09:54 +/–

Я же сам написал почему. Софт сам откатывается с 443 на 80. Ну или как минимум не перехрдит на 443. Значит MITM такое и будет провоцировать. Будь у вас хоть трижды только TLS1.2 включен.
Про HTTPS Everywhere хорошая идея, запомню.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

20. Сообщение от Электрон (?), 12-Дек-23, 09:55 +/–

Без дэйтасэтов не грести вам деньги дэйтасаентиста. Смузи - прошлое десятилетие.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

21. Сообщение от Аноним (14), 12-Дек-23, 09:57 +1 +/–

> позволяющих в ходе перехвата транзитного трафика (MITM) добиться внесения изменений в генерируемые системные образы
а как это происходит - хаекры вычисляют сборщика buildroot, едут к нему из другой страны, нейтрализуют соседей и ждут в их квартире когда он начнёт прошивку собирать чтобы митмить его вафай ? а если он в текущем году не намерен собирать - ворвутся к нему и заставят собирать чтобы помитмить ?

Ответить | Правка | Наверх | Cообщить модератору

22. Сообщение от 007 (??), 12-Дек-23, 13:01 +/–

> они в контейнерах и виртуалках тестируют
Это спасает от шуток типа "rm -rf /", но никак не от более-менее приличной целевой атаки.
Тут почти 100% вероятность возможности пробития и компрометации всей инфраструктуры buildroot, включая 50% мэинтейнеров.
Другое дело, что (скорее всего, пока еще) это никому не было нужно.
Хотя мэинтейнеров я бы подергал за причинные места - и для профилактики, ну и ради баловства.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #23

23. Сообщение от Аноним (14), 12-Дек-23, 13:58 +/–

> Тут почти 100% вероятность возможности пробития и компрометации всей инфраструктуры buildroot, включая 50% мэинтейнеров.
каким образом если каждая запущенная сборочная задача тестирует свою локальную копию ?
https://linuxembedded.fr/2022/01/buildroot-gitlab-ci-testing
кросскомпилятор riscv вообще для барметал - сборку пакетов на нём не тестируют, он их просто не соберёт
https://gitlab.com/buildroot.org/buildroot/-/commit/58d7c712...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #24

24. Сообщение от 007 (??), 12-Дек-23, 14:45 +/–

> каким образом если каждая запущенная сборочная задача тестирует свою локальную копию ?
Не образом, а подсвешником ;)
Например, пробивается через:
- подстановку 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, кто-то из меинтейнеров использует железо, но в основном просто производится сборка, а тесты по конкретным жалобам пользователей.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #25

25. Сообщение от Аноним (14), 12-Дек-23, 14:58 +/–

> 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.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #26

26. Сообщение от 007 (??), 12-Дек-23, 15:13 +/–

> ты конкретно не понимаешь
Ну..., вы не спешите делать столь смелые выводы и давать ненужные пояснения.
Теоретически ничего не мешает подменить toolchain, встроив в него генерацию специфических гаджетов/дыр для целевого кода RISC-V (ибо количество специфических расширений, добавлений и т.п. обеспечивает необходимые предусловия).
Это отдельный вектор атаки, про который я вангую уже более 5 лет.
Но первичный вектор атаки намного проще -- встроить троян в код самого тулчейна, который 50% меинтейнеров запускает на рабочей машине с x86 ;)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #27

27. Сообщение от Аноним (14), 12-Дек-23, 15:20 +/–

> Теоретически ничего не мешает подменить toolchain
а как практически выполняют MITM на gitlab были примеры ?
> встроить троян в код самого тулчейна, который 50% меинтейнеров запускает на рабочей машине с x86 ;)
надо ещё sifive взломать или принести майнтейнеру на флешке

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #28

28. Сообщение от 007 (??), 12-Дек-23, 15:40 +/–

> а как практически выполняют MITM на gitlab были примеры ?
Гуглите.
Были дыры (уже пофикшены), были примеры...
> > встроить троян в код самого тулчейна, который 50% меинтейнеров запускает на рабочей машине с x86 ;)
> надо ещё sifive взломать или принести майнтейнеру на флешке
Зачем ?
Для тех кто в танке:
- есть набор тестов запускаемых скриптом;
- в одном из тестов скачивается упомянутый тулчейн и запускается без верификации;
- 50% меинтейнеров запускали, запускают и будут запускать всё это на своих ноутбуках.
Короче, просто warez только легально.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #29

29. Сообщение от Аноним (14), 12-Дек-23, 15:52 +/–

> в одном из тестов скачивается упомянутый тулчейн и запускается без верификации;
КАК подменить тулчейн на сервере sifive или в хранилище buildroot ? ты ходишь по кругу: чтобы совершить атаку надо подменить тулчейн чтобы совершить атаку. Я уж молчу что у майнтейнеров он давно скачан и лежит локально - нахер им по сто раз его скачивать, версия у него не менялась с момента появления этого пакета - откуда взялись фантазии про постоянную смену хеша я хз.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #30

30. Сообщение от 007 (??), 12-Дек-23, 17:04 +/–

Лучше прочитайте текст новости еще раз.
Но в принципе можно и согласиться с формулировкой, что в CVE ерунда ;)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #31

31. Сообщение от Аноним (14), 12-Дек-23, 17:56 +/–

> Лучше прочитайте текст новости еще раз.
> позволяет подменить содержимое данных пакетов, имея возможность вклиниться в трафик
> сборочного сервера (например, при подключении пользователя через беспроводную сеть,
> контролируемую атакующим)
какая б..ть беспроводная сеть на гитлабе. Шансов использовать это примерно ноль.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

32. Сообщение от Аноним (32), 12-Дек-23, 20:13 +/–

Вы простите, надеюсь вы меня услышите: что ваше решение - крайность, имхо, что оригинальное "нет хеша? Так просто его не проверяем".
У вас - "просто отрезать возможность https".
В оригинале - "сбилдить во чтобы-то не стало".
То, что вы предлагаете, это, кажется, нынче называется технофашизм? Т.е. "мне пох, как у вас там что, теперь только tls и сношайтесь как хотите". Решение неплохое, строгое... но радикальное.
Кажется, норм дефолтным вариантом было бы "всегда https, всегда проверять хеши, если хешей нет, стопиться". А для тех, кому это не подходит, возможность выставить ключики типа --https-only=false и skip-no-hash=true?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

33. Сообщение от Аноним (-), 13-Дек-23, 09:37 +/–

>> пользуются 80% меинтейнеров тамошних пакетов при локальном тестировании сборок
> они в контейнерах и виртуалках тестируют
И, собственно, чего? Запустить майнер, спамер или ддосер на виртуалке ничуть не хуже чем на железке.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #34

34. Сообщение от Аноним (14), 13-Дек-23, 12:13 +/–

> Запустить майнер, спамер или ддосер на виртуалке ничуть не хуже чем на железке.
осталось рассказать как это сделать

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. Сообщение от Аноним (1), 11-Дек-23, 15:48	–2 +/–
> выявлены шесть уязвимостей, позволяющих в ходе перехвата транзитного трафика (MITM) добиться внесения изменений в генерируемые системные образы или организовать выполнение кода на уровне сборочной системы. какая-то чушь от свидетелей безопаснсти, во первых пакетики без хешей только совсем малонужные и неиспользуемые - поэтому и нет хешей, и что мешает легально добавить сборочный сценарий с валидными хешами но с неизвестным содержимым в исходниках, как будто кто-то там проверяет все сценарии make
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #12, #15

2. Сообщение от Аноним (2), 11-Дек-23, 15:49	+3 +/–
Занятная структура, читаешь - ну проходной двор просто.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #13

3. Сообщение от Аноним (3), 11-Дек-23, 16:07	+/–
>возможности использования HTTP для загрузки файлов Нужно было просто дропнуть поддержку http без s. Хочешл грузить, не пользуясь чужими CA? Создай свой CA и залей серт. Не хочешь? Ну знаешь, куда идти.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #5, #32

4. Сообщение от Аноним (4), 11-Дек-23, 16:24	+1 +/–
>пакеты aufs и aufs-util загружались по HTTP и не проверялись по хэшам >Некоторые пакеты, такие как ядро Linux, U-Boot и versal-firmware, допускали загрузку последних версий, для которых ещё не сформированы проверочные хэши И как использование безопасных языков поможет боротся с такими уязвимостями?
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #6, #8, #10

5. Сообщение от Электрон (?), 11-Дек-23, 17:46	+/–
Надо отдавать http/80 только по субдомену http, а на www, корень оставить только HTTPS. Хотя... митму ничто не мешает вклиниться в "отключенный" 80-ый порт. Вот вроде был certificate pinning :/ А постоянные редиректы вряд ли прикладным софтом запоминаются.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #3 Ответы: #7

6. Сообщение от Электрон (?), 11-Дек-23, 17:48	+/–
Безопасных ножей не бывает. Только некоторые их типы чаще соскальзывают, когда не ждешь.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #4

7. Сообщение от Аноним (7), 11-Дек-23, 18:12	+/–
Нахрена такие извращения? Просто не TLS дропнуть и всё. Я уже много лет в TLS-only режиме. Поначалу с помощью HE, сейчас - нативно. HE правда зря дропнули. Их дэйтасет был полезен для массового автоматического переписывания ссылок в гитхаб-рееозиториях.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #5 Ответы: #18, #19

8. Сообщение от Alladin (?), 11-Дек-23, 18:33	–1 +/–
Все просто, мы просто перехватим ваш код встроенный в http(образно:) ) и скажем ошибка.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #4

9. Сообщение от Аноним (9), 11-Дек-23, 20:56	+3 +/–
Ещё шесть уязвимостей публиковать не стали, сами пользуются.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #11

10. Сообщение от Аноним (10), 11-Дек-23, 21:45	+/–
В безопасных языках такое поведение в принципе нормальное и допустимо в тулинге языка. Чтобы было проще и просто работало.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #4

11. Сообщение от Аноним (10), 11-Дек-23, 21:45	+/–
Да остальные за деньги.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #9

12. Сообщение от 007 (??), 11-Дек-23, 21:52	+/–
Там эпичность в том, что тулчейн RISC-V как самый "модно-молодежный" входит в набор, которым пользуются 80% меинтейнеров тамошних пакетов при локальном тестировании сборок. Ну а хеши этого горе-тулчейна там дропнули, ибо задолбались менять (и коммитить эти изменения в репу), так как ночвые бага-фичи в тулчейн добавляются быстрее чем исправляются старые.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1 Ответы: #14

13. Сообщение от 007 (??), 11-Дек-23, 21:54	+3 +/–
Ну дак RISC-V же, как задумано ;)
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2

14. Сообщение от Аноним (14), 11-Дек-23, 22:25	+/–
> пользуются 80% меинтейнеров тамошних пакетов при локальном тестировании сборок они в контейнерах и виртуалках тестируют
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #12 Ответы: #22, #33

15. Сообщение от YetAnotherOnanym (ok), 11-Дек-23, 22:27	+3 +/–
Мы забор ставим только там, где много людей ходит. Где не ходят или один-два изредка пройдёт - там забор не нужен.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1

18. Сообщение от Бывалый смузихлёб (?), 12-Дек-23, 09:44	+/–
> дэйтасет Казалось бы, как можно настолько извратить простое и лаконичное "набор данных" / "база данных" / "база знаний"
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #7 Ответы: #20

19. Сообщение от Электрон (?), 12-Дек-23, 09:54	+/–
Я же сам написал почему. Софт сам откатывается с 443 на 80. Ну или как минимум не перехрдит на 443. Значит MITM такое и будет провоцировать. Будь у вас хоть трижды только TLS1.2 включен. Про HTTPS Everywhere хорошая идея, запомню.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #7

20. Сообщение от Электрон (?), 12-Дек-23, 09:55	+/–
Без дэйтасэтов не грести вам деньги дэйтасаентиста. Смузи - прошлое десятилетие.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #18

21. Сообщение от Аноним (14), 12-Дек-23, 09:57	+1 +/–
> позволяющих в ходе перехвата транзитного трафика (MITM) добиться внесения изменений в генерируемые системные образы а как это происходит - хаекры вычисляют сборщика buildroot, едут к нему из другой страны, нейтрализуют соседей и ждут в их квартире когда он начнёт прошивку собирать чтобы митмить его вафай ? а если он в текущем году не намерен собирать - ворвутся к нему и заставят собирать чтобы помитмить ?
Ответить \| Правка \| Наверх \| Cообщить модератору

22. Сообщение от 007 (??), 12-Дек-23, 13:01	+/–
> они в контейнерах и виртуалках тестируют Это спасает от шуток типа "rm -rf /", но никак не от более-менее приличной целевой атаки. Тут почти 100% вероятность возможности пробития и компрометации всей инфраструктуры buildroot, включая 50% мэинтейнеров. Другое дело, что (скорее всего, пока еще) это никому не было нужно. Хотя мэинтейнеров я бы подергал за причинные места - и для профилактики, ну и ради баловства.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #14 Ответы: #23

23. Сообщение от Аноним (14), 12-Дек-23, 13:58	+/–
> Тут почти 100% вероятность возможности пробития и компрометации всей инфраструктуры buildroot, включая 50% мэинтейнеров. каким образом если каждая запущенная сборочная задача тестирует свою локальную копию ? https://linuxembedded.fr/2022/01/buildroot-gitlab-ci-testing кросскомпилятор riscv вообще для барметал - сборку пакетов на нём не тестируют, он их просто не соберёт https://gitlab.com/buildroot.org/buildroot/-/commit/58d7c712...
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #22 Ответы: #24

24. Сообщение от 007 (??), 12-Дек-23, 14:45	+/–
> каким образом если каждая запущенная сборочная задача тестирует свою локальную копию ? Не образом, а подсвешником ;) Например, пробивается через: - подстановку 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, кто-то из меинтейнеров использует железо, но в основном просто производится сборка, а тесты по конкретным жалобам пользователей.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #23 Ответы: #25

25. Сообщение от Аноним (14), 12-Дек-23, 14:58	+/–
> 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.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #24 Ответы: #26

26. Сообщение от 007 (??), 12-Дек-23, 15:13	+/–
> ты конкретно не понимаешь Ну..., вы не спешите делать столь смелые выводы и давать ненужные пояснения. Теоретически ничего не мешает подменить toolchain, встроив в него генерацию специфических гаджетов/дыр для целевого кода RISC-V (ибо количество специфических расширений, добавлений и т.п. обеспечивает необходимые предусловия). Это отдельный вектор атаки, про который я вангую уже более 5 лет. Но первичный вектор атаки намного проще -- встроить троян в код самого тулчейна, который 50% меинтейнеров запускает на рабочей машине с x86 ;)
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #25 Ответы: #27

27. Сообщение от Аноним (14), 12-Дек-23, 15:20	+/–
> Теоретически ничего не мешает подменить toolchain а как практически выполняют MITM на gitlab были примеры ? > встроить троян в код самого тулчейна, который 50% меинтейнеров запускает на рабочей машине с x86 ;) надо ещё sifive взломать или принести майнтейнеру на флешке
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #26 Ответы: #28

28. Сообщение от 007 (??), 12-Дек-23, 15:40	+/–
> а как практически выполняют MITM на gitlab были примеры ? Гуглите. Были дыры (уже пофикшены), были примеры... > > встроить троян в код самого тулчейна, который 50% меинтейнеров запускает на рабочей машине с x86 ;) > надо ещё sifive взломать или принести майнтейнеру на флешке Зачем ? Для тех кто в танке: - есть набор тестов запускаемых скриптом; - в одном из тестов скачивается упомянутый тулчейн и запускается без верификации; - 50% меинтейнеров запускали, запускают и будут запускать всё это на своих ноутбуках. Короче, просто warez только легально.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #27 Ответы: #29

29. Сообщение от Аноним (14), 12-Дек-23, 15:52	+/–
> в одном из тестов скачивается упомянутый тулчейн и запускается без верификации; КАК подменить тулчейн на сервере sifive или в хранилище buildroot ? ты ходишь по кругу: чтобы совершить атаку надо подменить тулчейн чтобы совершить атаку. Я уж молчу что у майнтейнеров он давно скачан и лежит локально - нахер им по сто раз его скачивать, версия у него не менялась с момента появления этого пакета - откуда взялись фантазии про постоянную смену хеша я хз.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #28 Ответы: #30

30. Сообщение от 007 (??), 12-Дек-23, 17:04	+/–
Лучше прочитайте текст новости еще раз. Но в принципе можно и согласиться с формулировкой, что в CVE ерунда ;)
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #29 Ответы: #31

31. Сообщение от Аноним (14), 12-Дек-23, 17:56	+/–
> Лучше прочитайте текст новости еще раз. > позволяет подменить содержимое данных пакетов, имея возможность вклиниться в трафик > сборочного сервера (например, при подключении пользователя через беспроводную сеть, > контролируемую атакующим) какая б..ть беспроводная сеть на гитлабе. Шансов использовать это примерно ноль.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #30

32. Сообщение от Аноним (32), 12-Дек-23, 20:13	+/–
Вы простите, надеюсь вы меня услышите: что ваше решение - крайность, имхо, что оригинальное "нет хеша? Так просто его не проверяем". У вас - "просто отрезать возможность https". В оригинале - "сбилдить во чтобы-то не стало". То, что вы предлагаете, это, кажется, нынче называется технофашизм? Т.е. "мне пох, как у вас там что, теперь только tls и сношайтесь как хотите". Решение неплохое, строгое... но радикальное. Кажется, норм дефолтным вариантом было бы "всегда https, всегда проверять хеши, если хешей нет, стопиться". А для тех, кому это не подходит, возможность выставить ключики типа --https-only=false и skip-no-hash=true?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #3