В UEFI-прошивках на основе открытой платформы TianoCore EDK2, обычно используемых на серверных системах, выявлено 9 уязвимостей, получивших собирательное кодовое имя PixieFAIL. Уязвимости присутствуют в сетевом стеке прошивок, применяемом для организации сетевой загрузки (PXE). Наиболее опасные уязвимости позволяют неаутентифицированному атакующему организовать удалённое выполнение своего кода на уровне прошивки в системах, допускающих PXE-загрузку с использованием сети IPv6...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60449
Ждём маминых советчиков переписать на безопастный. Правда, само переписывание в ближайшие цать лет не свершится.
не, лучше переполнение, вверх, вниз, вбок, и с переворотом.
> Ждём маминых советчиков переписать на безопастный.Разумеется не нужно переписывать. Просто наслаждайтесь дыренями, стабильными еще с 80х годов прошлого века.
Чтобы было как у дидов!
> Ждём маминых советчиков переписать на безопастный. Правда, само переписывание в ближайшие цать лет не свершится.Т.е вариант "писать без типичных ошибок" даже не рассматривается?
Ну типа обмазать все что можно стат анализаторами, применить фаззинг, добавить проверки переполнений.
UEFI не требует супер быстрых вычислений, будет оно загружаться за 1 или 2 секунды, никто и не заметит.Но почему за 20 лет никто даже не почесался?
у них там заявленно что есть тесты и 1381 passed, 65 skipped, но что-то это не помогло.
> Т.е вариант "писать без типичных ошибок" даже не рассматривается?У "мамкиных советчиков" - никогда. Они раз и навсегда отказались от варианта "писать без ошибок", признав свою прирождённую неспособность правильно расчитывать размеры буфера, помнить об освобождении памяти и так далее.
да тут просто флеш рояль...
> да тут просто флеш рояль...Точнее флеш фирмварь. Но примерно то же самое в случае UEFI
а вот опенсорсный БИОС coreboot+SeaBIOS этим вашим UEFI-дырам не подвержен ;-) у него даже PXE обычно нет, т.к. в большинстве случаев пользователи собирают его без дополнения ipxe
> а вот опенсорсный БИОС coreboot+SeaBIOS этим вашим UEFI-дырам не подвержен ;-) у
> него даже PXE обычно нет, т.к. в большинстве случаев пользователи собирают
> его без дополнения ipxeКМК его пишут все же не настолько ушибленные индусские коты.
Если просто посмотреть бутлог линуха на типовой ГУАШи - например - парсинг ACPI таблиц - то видно что ГУАШ и его таблицы хреначили в состоянии расширенного сознания, не иначе. Или не приходя в сознание вообще, черт их там разберет.
> а вот опенсорсный БИОС coreboot+SeaBIOS этим вашим UEFI-дырам не подвержен ;-) у
> него даже PXE обычно нет, т.к. в большинстве случаев пользователи собирают его без дополнения ipxe"а вот опенсорсный БИОС" ?
Так эта штука и так опенсорсная уже 20 лет?А у coreboot есть свои уникальные, неповторимые дырки)
CVE-2022-29264 - arbitrary code execution с 4.13 по 4.16
Но
вынипанимаити - ета другое!
дыряшечное бинго
На автомате выпадает С С С С, музыка, звон монет, вы выиграли Джек-Пот!
а вот был бы раст!
> переполнение буфера
> на основе открытой платформы TianoCore EDK2Это кстати, эта штука не сильно и новая.
Интел ее открыл в 2004 году и подарил сообществу.
За 20 лет тысячи глаз и лучшие погромисты Сообщества™ старались и выдавливали из себя код.Итого
3 переполнения буфера,
2 бесконечных цикла,
2 использования предсказуемых "типа случайных" чисел
И мелочь типа утечки данных из области вне буфера, underflow и тдА как же так получилось?
Хм.... tianocore C 76.3%
Молодцы потомки! Не посрамили честь дидов, закладывающих уязвимости в х11 еще в 88 году!
Вариант тупо не использовать UEFI, всё-равно он не может быть безопасным из-за потери контроля управляемости не рассматривается?
А толку?
Берем тот же coreboot - и видим там CVE-2022-29264 - arbitrary code execution , с рейтом 9.8
Жило с версии 4.13 до 4.16.Так что победить можно только вводя какие-то стандарты на тестирование и надежность.
Например сделать обязательными тесты и стат анализ.
Не прошли - значит ты не мерджишь, пока не исправишь.Может предложенный закон об ответственности продаванов, за используемый код, как-то сдвинет подход "х-к-х-к и в продакшн, код ваv as-is in-ass"
Для критических к безопасности вещей писать на голой сишке - это шиза. Хоть с анализатором хоть без.Если использование какой-нибудь ады раста или хаскеля не рассматривается, то в крайнем случае пишется свой собственный велосипедный кодогенератор, который проверки на всё что можно вставляет сам.
> Для критических к безопасности вещей писать на голой сишке - это шиза.да, надо сразу на markdown "программировать". Это безопастно!
> Если использование какой-нибудь ады раста или хаскеля не рассматривается
код начальной инициации аппаратуры. На хаскеле. Успехов. Чао. Увидимся лет через пятьсот.
Та не в коде инициализации аппаратуры ошибки.
ну давай половину начального загрузчика напишем на си, а вторую на хаскеле. Удачи, все через те же лет 500.
Как раз и eeprom'ом на терабиты подвезут, чтоб оно как-то могло там поместиться.
Хаскель кстати в сишку компилируется, никакой спец магии ненужно для этого.
Размеры бинарников то отдельная тема, не нравится хаскель, других вариантов куча.
Во Фре вон вообще бутлоадер на луе написали.
сперва надо чтоб образовалось ЧТО компилировать - и именно в этом месте тебя ждут некоторые сложности.> Во Фре вон вообще бутлоадер на луе написали.
ниасилив разобраться в прежнем, который был на форте. (но учти, что таки форт _специально_ придумывали для бутлоадеров и прочих незамысловатых вещей поближе к голому железу)
> Хаскель кстати в сишку компилируется, никакой спец магии ненужно для этого.
> Размеры бинарников то отдельная тема, не нравится хаскель, других вариантов куча.
> Во Фре вон вообще бутлоадер на луе написали.Встретились 2 очень всех нужным штуки как-то, и стали меряться - кто же из них человечеству нужнее? Человечество ушло вперед, а они так и остались спорить дальше. Где-то там.
> Хаскель кстати в сишку компилируется, никакой спец магии ненужно для этогоТы потом в этом коде разбираться будешь?
Погоди-погоди, а мы зачем на хаскель-то собрались переписывать?!Никто не может разобраться - нет и увизгвимостей, шах и мат, кульхаксоры!
Правда все недосуг поинтересоваться - владельцы инфры pgp keyservers таки осилили залатать феерическую дыру в коде на ocaml?
Или до сих пор в позе "ну прочитать-то этот код мы могем, все буковки вроде понятные, вот угадать слова пока плохо получается" ?
А на чем писать? Ты со своим с# мозг что ли высушил? Какой хаскель? Ты видимо на нем ничего серьёзного не писал.Нужно тестирование усилить, фазинг, сделать обязательным использование санитайзеров.
> А на чем писать? Ты со своим с# мозг что ли высушил?На Лиспе.
На Vlang, например.
Практически всё Сообщество (89% согласно отчётам board_status) использовало SeaBIOS в качестве коребутовского дополнения, а не Tianocore. И правильно делало! ;-)
Не зря гугля в своих материнках в ДЦ использует coreboot
гугля старается писать на богомерзком расте. куда им до настоящих сишников.
В том то и дело что старается, но ничего не напишет.
>В том то и дело что старается, но ничего не напишет.Так делают все, кто пытался писать на расте! ;)
> В том то и дело что старается, но ничего не напишет.не, ну как же - пятнадцать прослоек к прокладкам уже написал.
шитотатам "80% новаго кода в ведроид"...стоп, а какой такой НОВЫЙ код есть вообще в ведроиде? Очевидно не код ведра линукса, гугль его не считает "кодом ведроида", так, само приползло.
Что там такого меганужного и полезного понаписано за последние пять версий?Ну вот этого ничего - 80% нахрустели. Но инвесторы в таких тонкостях не разбираются.
Ну так речь же про новый код андройдов, а не ядра.
Ядро оно дыряшечное - там фанатиков и растохейтеров хватает.
речь идет про новое никому ненужно.Причем объемы этого нового ненужно - микроскопические, нет в ведроиде никаких мегадостижений за последние годы (и хвала Всевышнему). Но вам главное ж прокукарекать и красивую цифирь показать.
А при попытке делать что-то полезное - опять эскопета с кривым стволом только и выходит.
> шитотатам "80% новаго кода в ведроид"звиздишь как Троцкий. Не с той стороны проценты взял, там было 21% (год назад)
> а какой такой НОВЫЙ код есть вообще в ведроиде?там ниже частично перечислено, если тебе _ПРАВДА_ интересно (но тебе же этого не надо, тебе набросить):
"...In Android 13, about 21% of all new native code (C/C++/Rust) is in Rust. There are approximately 1.5 million total lines of Rust code in AOSP across new functionality and components such as Keystore2, the new Ultra-wideband (UWB) stack, DNS-over-HTTP3, Android’s Virtualization framework (AVF), and various other components and their open source dependencies..."
но куда-а-а-а-а там этим хэлловолдам до твоей "Мега Крутой СуперПрограммы Контроля Всего мира"(ц), написанной на Си.
> Очевидно не код ведра линукса, гугль его не считает "кодом ведроида"
Не боись, они мечтают и туда залезть:
"With support for Rust landing in Linux 6.1 we’re excited to bring memory-safety to the kernel, starting with kernel drivers."
Тебе от раста не сбежать, уа-ха-ха-ха-ха!!!!!
> ...In Android 13, about 21% of all new native code (C/C++/Rust) is in Rustведроид представляет собой линукс с кучкой прослоек и прокладок. И jvm краденую у орацла поверх.
Какой такой еще "new native code" принадлежащий гуглю в нем есть?
И не надо мне цитировать, глупый попугайчик, то, о чем ты не знаешь, что это.А, во, dns-over-http3 ? В нем аж 21 процент понахрустели?
Т.е. все это и есть хеловроты причем в области прослоечек и прокладочек, ненужных примерно никому и низачем или вовсе вредных.Гуглю нечем занять своих обезьянок, не умеющих в системное программирование. Но признавать это гуглевые пмы очень не любят, могут и уволить.
> Не боись, они мечтают и туда залезть:
они "excited". То есть на радостях обмочили штанишки. Писать они ничего кроме прослоек и прокладок не будут, потому что во-первых уже некому там давно, во-вторых и главных не для того шва...6епшплатноевзятьвзять чтоб потом самим в это вкладывать ресурсы.
Офигенно получается. Так им понравилось это дело, что заявляют о стремлении всё больше отказываться от си/плюсов в пользу раста:"What’s next?
Migrating away from C/C++ is challenging, but we’re making progress. Rust use is growing in the Android platform, but that’s not the end of the story. To meet the goals of improving security, stability, and quality Android-wide, we need to be able to use Rust anywhere in the codebase that native code is required. We’re implementing userspace HALs in Rust. We’re adding support for Rust in Trusted Applications. We’ve migrated VM firmware in the Android Virtualization Framework to Rust. With support for Rust landing in Linux 6.1 we’re excited to bring memory-safety to the kernel, starting with kernel drivers.
As Android migrates away from C/C++ to Java/Kotlin/Rust, we expect the number of memory safety vulnerabilities to continue to fall. Here’s to a future where memory corruption bugs on Android are rare!"
Красиво пошли.
А qemu проблеме подвержена? OVMF вроде бы тоже на EDK2 основана.
А кого там ломать самого себя?
в QEMU коребутовский образ тоже с SeaBIOS'ом идёт вместо UEFI-жирноты
>Languages
>C 76.3%Это был вопрос времени. Выделить буфер фиксированного размера, а потом записать туда данные превышающие этот размер, стало притчей во языцех.
Нужно было использовать Эльбрус ...
Как ты гору используешь? Будешь сбрасывать нерадивых разработчиков с вершины?
да там у самих вершин полого все, далеко не улетят.
Можно просто их там бросать - побродят-побродят, да и околеют. -50 с ветрищем под сотку - нормальная погода, да и деваться оттуда особо некуда. Но это зимой. До конца мая надо успеть закрыть таск.
> для организации сетевой загрузки (PXE). Наиболее опасные уязвимости позволяют неаутентифицированному атакующему организовать удалённое выполнение своего кода на уровне прошивкиинтересно, много ли серверных позволяют попасть неаутентифицированному пользователю во внутренний периметр, где происходит загрузка по PXE?
полно таких, возьми любой хостинг ДЦ, везде есть возможность загрузить дедик по сети в рескуе ос
вот и не бери помойкохостинги в помойкодц.Там где мои коробочки тарахтят - ничего подсунуть между гейтом и твоей коробкой не получится.
Еще от тыщи и одной болячки помогает.А не фильтровать траффик разных клиентов друг от друга - ну могут позволить себе либо очень глупые, либо владельцы собственной площадки.
> ничего подсунуть между гейтом и твоей коробкой не получитсяКак реализуете?
port isolationшироковещательный траффик просто никуда не дойдет кроме маршрутизатора (поэтому перехватить начальный бродкаст не получится), целевой дойдет - но через маршрутизатор, а это палево да и фильтры там.
Незачем пользовательским коробкам между собой общаться. Ничего хорошего они все равно таким путем не передают.
Не, ну не изолировать клиентов, а особенно не изолировать сеть управления - это вообще очень странно.
pxe - это не сеть управления, это сеть клиента.
ЩАЗ.
Не, если бареметал клиент хочет PXE с откуда попало - его право. Изоляция портов тут не спасёт.А если речь о загрузке аппаратной ноды с PXE - клиенты которые попадут на эту ноду, вообще не в курсе, откуда оно загрузилось.
тупой вопрос: и даже vlan не спасёт?
не напасешься. Но port isolation - таки да.
точно, про него забыл, спасибо
Да почему не напасёшься-то? Более 4000 портов на свитч? :)
Мы даже с port isolation не заморачиваемся - тупо влан на порт.
> Мы даже с port isolation не заморачиваемся - тупо влан на порт.а дальше? Выделять на каждое корыто отдельную адресацию и отдельно маршруты - п-ц, собирать потом вланы кучкой на один svi - здравствуй proxy arp когда не ждали.
Ды ладно, всё не так плохо и сложно.
Отдельная адресация и отдельные маршруты делаются, факт.
Зачем вланы на один SVI собирать? /31, и никаких проксиарпов.
> Ды ладно, всё не так плохо и сложно.
> Отдельная адресация и отдельные маршруты делаются, факт.
> Зачем вланы на один SVI собирать? /31, и никаких проксиарпов.то есть ПОЛОВИНА адресов багровой шляпой накрыты? Ну...ок...
А можешь отсыпать /23, по братски? А то я тут плачу за /28 совершенно нев...нные деньги, а у тебя, смотрю, лишинх-то дохрена?
/23 не могу, /30 запросто.Невдолбенные деньги - это сколько? Десять баксов в месяц?
мля, ну куда мне совать твой /30 ? Мне надо что-то что можно хотя бы попросить анонсить хороших (нет) ребят.> Невдолбенные деньги - это сколько? Десять баксов в месяц?
мля... как бы это так сформулировать... ааааа, да хрен с ним - как тебе нравится
/24 IP subnet (254 usable IPs) € 435.20 monthly / € 659.00 setup(эх... кажется, мои шансы что-то поиметь нахаляву теперь равны нулю)
P.S. я надеюсь ты понимаешь почему 254 и что это означает?
Ну что это означает. Да ничего не означает, если не PI.
Всё так же будешь гоняться через единственный аплинк.Речь вроде про конские деньги за /28 шла?
А за /24 435 в месяц - это очень даже нормально.
мне не нужен PI, мне нужна возможность анонсить блок не с твоих железок, чего неясного-то. Для этого нужен блок приличных размеров, а AS мы и твою предъявим, я же говорю что они не совсем "хорошие" пацаны.Сервер-то я двигать никуда не буду, он нетранспортабелен.
Те вот чо, жалко, когда ты по /30 на одного вшивого клиента с физическим тазиком выкидываешь?У тебя там этих ненужных /23 должны сотни пропадать просто так, на вланах per client, и наверняка есть запас на годы вперед. Ну чо тебе, одной жалко, даааа?
/28 это € 27.20 monthly / € 59.90 setup (да вы там уху ели?! Чтоб я столько за пять секунд работы получал!) и с тем же нае.. "14 usable" - т.е. ты и ЕЩЕ за одну /30 заплатишь, падла бохатая, одного адреса ей вишь мало. У меня старый сервер, где не было этого "setup", но в результате я ничего поменять там не могу.
> /28 это € 27.20 monthly / € 59.90Абсолютно нормально. Я бы сказал даже дёшево, у нас recurring дороже. Правда без сетапа.
Мы конечно в этом плане беднота уже.
/24 и шире вообще не даём, максимум /28.
/27 только по особому запросу и особо крупным.
Хотя в прошлый раз целую пачку /30 отдали особо крупному клиенту, спецзаказ. Я плакал кровавыми слезами, но ack'нул.
(это не значит, что один клиент в теории не может себе нажрать /30 на целую /25 например через 16 портов, но это с учётом портов выйдет достаточно дорого)
/26 то бишь
Ну и за шмот поясню: у нас NAT до сих пор кроме как на мобилке - нет нигде.
Феерично, но факт. Поэтому риходится экономить даже имея резервы.
Yes, даже у массы физиков нет NAT :)
Ну это для металла же. Где-то даже /30, а не /31.
VPS конечно сидят на /32 в аннамбередах.
но зачем? У вмвари все в порядке с port isolation, "это бесплатно". Еще и promisc включить на виртуальном интерфейсе никто не даст.
Но зачем, если проще положить клиента в совершенно изолированную подсеть "насквозь", не полагаясь на софт?
И промиск включать бесполезно, даже если у него собственное железо. Ну а в виртуалках никто не даст, да.
> Но зачем, если проще положить клиента в совершенно изолированную подсеть "насквозь", не
> полагаясь на софт?а зачем нужен такой микроменеджмент? Где я это делал - швыряли /24 на пару стоек, считать проще по цельным октетам, и не парились. "следи же, чтоб число их было нечетным" Клиент всвитча все равно ничегошеньки лишнего не увидит.
(ну да, с клиентами таки хотевшими видеть, грусть, печаль, миграция в отдельную стойку с другими конфигами - но это была старая вмварь, еще до пришествия nsx. В отдельной стойке был виртуальный nexus с полноценной лицензией.)
Я кстати могу предположить вариант, при котором клиент даже промиск в своём влане в вм может получить и поюзать, всё равно ничего, кроме летящего в этом влане, он не увидит, но пока что никто не просил.
Есть варианты и без /31, есть варианты с /32 unnumbered, там тоже изоляция by default, да и собирать особо ничего не приходится, и проксиарпа нет.Для клиентов, которым нужна распределённая сеть - есть транзитные диапазоны UNI, которые с одинаковым NNI приводятся на все роутеры.
Для совсем любителей есть VPLS.
и чем оно нам тут поможет?
Оно тоже про изоляцию, на самом-то деле. Порты ходят с меткой, и никого, кроме клиента, в них нет. Где-то оно вываливается на всю клиентскую /28-/29 в BVI, и уже оттуда уходит наружу.
Это конкретно в тех местах, где свитчей либо ещё нет, либо уже нет.
В случае VPS - VLAN на VPS.
Всё управление естественно отдельно ходит, туда вообще ничего и никак не подсунешь.