Pull to refresh
313
0
Николай Шлей@CodeRush

Firmware Security Engineer

Send message
Пробовал ригидную вилку вместо стоявшей изначально Suntour NCX — и вернул обратно, потому что с блокировкой получается то же самое, практически, а без нее после пару часов езды по лесным тропинкам начинаются неприятные ощущения в руках от непогашенной вибрации.
Если ездить исключительно по хорошим дорогам, то это все — только лишний вес, конечно.
Добавлю еще про контактные педали — если катаетесь дальше 10 км за раз, то советую настоятельно, потому что усталость с ними наступает значительно позже. Недостатков два: нужна специальная обувь, которая обычно довольно жесткая и в которой не очень удобно ходить, и при падении от некоторых моделей контактов весьма непросто отстегнуться (нужно движение пяткой наружу-вбок, а инстинкт подсказывает рвать ногу вверх, что только усугубляет и так уже неприятное падение). Тем не менее, на контактах «катит» гораздо дальше и приятнее, на мой взгляд, и на велосипед без них уже не очень-то и хочется.
Всю статью можно свести к «покупайте велосипед и оборудование, подходящие к вашему стилю катания и вашим задачам», для города — citybike/cruiser/fixed-gear, для дальней дороги — trekking, для езды по шоссе — road, для разных горных дисциплин — MTB, для фанатов странного — tandem/unicycle/recumbent и т.п., а далее уже отталкиваться от типа при выборе оборудования и всего остального.
Сам катаю по лесным тропам и дорогам примерно 50\50, поэтому выбрал треккинговый велосипед со скоростями, амортизирующей вилкой с фиксатором, багажником для вещей, крыльями и передним фонарем. По городу катаю в обычной одежде, но в шлеме и перчатках, когда еду куда-то далеко и надолго — надеваю вело-форму и рюкзак с трубкой для питья.
А про шлем, оно личное дело каждого, конечно, но мне он однажды уже сохранил здоровье, поэтому теперь без шлема стараюсь не ездить вообще никуда.
Пожалуйста, приятно читать такие комментарии через несколько лет после написания самого цикла. Постараюсь писать еще, когда времени свободного будет чуть больше.
Это не совсем правда, потому что на современной микросхеме SPI хранится сразу несколько прошивок и управляют ей сразу несколько мастеров, каждый из которых хранит в своем регионе изменяющиеся во время загрузки и нормально работы данные, и если всю микросхему разом защитить от записи джампером, то все эти модифицируемые данные придется выносить в CMOS SRAM (15 лет назад именно там они и хранились), к которой очень просто получить доступ через CPU IO-порты 70h/71h или 74h/75h и у которой никаких защитных механизмов нет, а сама она в заметных объемах (256Кб, которые сейчас используют большая часть реализаций UEFI, а ведь есть еще ME, GbE и EC) стоит как самолет.
Можено попробовать разнести модифицируемые часто и модифицируемые только при обновлении данные по разным SPI-микросхемам и защитить «джампером» последнюю, но это удорожает производство и разработку платы и прошивки, поэтому массовый рынок этим не заморачивается и, скорее всего, никогда не будет.
Отличная статья и очень полезный реверс, теперь можно добавить разбор манифестов в UEFITool, не боясь праведного гнева Intel. По поводу контрольной суммы записей в FIT — ей управляет верхний бит Type, а считается она вот так.
В качестве продолжения предлагаю рассмотреть побольше реализаций цепочки доверия, включив Dell и HP, которые давно и относительно успешно занимаются безопасностью своих прошивок, плюс рассмотреть атаки на компоненты самой цепочки безотносительно BootGuard, который защищает только SEC и PEI.
Пёс бы с ним, с ритмом, хоть он и страдает, железо нельзя домой взять, вот где самая засада.
Работаешь над новыми продуктами, которые ни пощупать, ни осциллографом тыкнуть, ни перезагрузить, ни перепрошить, зависло — заходи на IP-розетку, дергай питание и молись, что прошивка и система после этого поднимутся. Не поднялись — ну что ж, дежурный инженер рад помочь тебе в свои 4 часа утра, первые раз несколько…
Вообще, я поработал 8 месяцев на 100% удаленно и снова хочу в офис, в лабораторию с нормальным оборудованием, которое домой купить не хватит денег, к коллегам, которые помогут быстрее разобраться с вещами, о которых ты пока не имеешь понятия, к митингам лицом к лицу, и вот этому всему.
По поводу Coverity — скорее всего Scan выдает еще раза в 4 больше предупреждений вида «unchecked input X taints
variable Y», и в потоке подобного рода сообщений тонут настоящие предупреждения.
Если еще не проверяли, попробуйте проверить ядро OpenBSD, разработчики которого давно уже хвалятся качеством кода и отсутствием эксплуатируемых уязвимостей (очень похоже на Неуловимого Джо, конечно, но тем не менее).
Автор упоминает Эппл, у которого имеется публичная политика поддержки Diversity, под которым в США понимают отсутствие дискриминации.
Когда я впервые столкнулся с этой политикой и графиками в конце страницы, я был искреннее шокирован.
Раньше работал в небольшой немецкой фирме (~100 человек), в которой были люди из ~30 стран, только в нашем отделе R&D на 10 человек разговаривали на 5 языках, но никому бы в голову не пришло посчитать, сколько у нас работает негров, белых, азиатов, и т.п. со статистикой и графиками, потому что в представлении европейцев — это вот самый махровый расизм и есть, осталось только черепа измерить и нашивки на одежду добавить.

Умение программировать не зависит от пола, и в него люди любые не идут не потому, что там их притесняют по половому/расовому/иному признаку, а потому, что программирование — это сложно, затратно по времени и здоровью, требует одновременно и высокой квалификации, и постоянного обучения и переобучения, изобилует стрессовыми ситуациями, и практически во любой точке мира, кроме Кремниевой Долины, оплачивается далеко не так высоко, как это принято думать.

Не нужно пропагандировать, не нужно заставлять, пусть программируют те, кто готов бороться со всем вышеперечисленным потому, что ему или ей действительно «доставляет» программирование.
Этот первоапрельский пост написан кровью, потом и слезами нескольких поколений безопасников, спасибо автору огромное за него.
О том, что основная задача ИБ — сделать несанкционированный доступ к информации дороже самой информации (переформулировка закона Склярова) и о том, что security has no market value (оригинальная формулировка закона Березина) я и сам постоянно тут в комментариях пишу совершенно без шуток.
P.S. законы эти настолько фундаментальные, что на них отлично работает принцип Арнольда, известный также как закон Стиглера.
Отличный пост, почти все мифы об UEFI, в которые верят апологеты Linux, точно также начитавшиеся новостей, как и автор этой статьи.

Давайте по порядку: UEFI не решает проблему двойной инициализации ни на одной платформе, потому что создан был вовсе не для этого. EFI, вообще говоря — это просто интерфейс между прошивкой и ОС, и он не имеет никакого отношения к инициализации оборудования вообще, а пришел на смену интерфейса BIOS interrupt call, потому что для той платформы, для которой EFI изначально разрабатывался Intel с 1998 года (назывался он тогда Intel Boot Initiative) — IA64/Itanium совместимость с legacy BIOS реализовывать не стали из за отсутсвия поддержки 16-битного режима исполнения.
Еще раз: UEFI — это всего лишь интерфейс между ОС и прошивкой, избавленый от костылей вроде ресета через IO-порт клавиатуры и управления адресной линией A20.

То, что вы называете UEFI на деле представляет из себя комбинацию из двух относительно независимых компонентов: кода инициализации оборудования и кода, реализующего интерфейс с ОС. На большинстве современных ПК инициализацией оборудования теперь занимается либо Intel PI, либо AMD AGESA, либо вышеупомянутый coreboot, а на ARMах — uboot.
Еще раз: coreboot занимается только инициализацией оборудования, а для предоставления интерфейса с ОС ему нужен т.н. payload, который может реализовать как старый интерфейс BIOS int (SeaBIOS), так и более новый интерфейс UEFI (TianoCore), а может вообще никакого не реализовавывать и запускать ядро Linux напрямую.

Для какой ОС заточен UEFI — ни для какой, активно используется MacOS и Windows. Кто протащил его через монопольный сговор — Intel, начав предоставлять MRC в виде 32-битного блоба (который с 16-битным BIOS нужно было женить через жертвоприношения и танцы с бубном и барабанами), а потом вынудив IBV перейти на UEFI с релизом Sandy Bridge. Apple же использует EFI с 2007 года, потому что на момент перехода на x86 никаких альтернатив EFI на x86 не было уже тогда.

Про SecureBoot — вы можете подписывать все свое своими собственными ключами, и никто вам не мешает этой возможностью пользоваться, а не рассказывать очередной раз про ярмо, которое на пользователя якобы кто-то нацепил.

Линуксоиды, если вы хотите хоть немного разобраться прежде чем начинать в очередной раз обвинять производителей железа и ОС во всех смертных грехах, прочтите Beyond BIOS, авторы которой этот самый UEFI придумали и поддерживают уже почти 20 лет.
Ребят, у вас весь рассказ про EFI получился из серии «слышал звон, нагуглил новостей, теперь мнение имею»:
— никакой мастер-ключ у МС не утекал, иначе его давно уже заменили бы (утек подписаный кусок загрузчика, который позволял загрузить по цепочке что угодно только на ARM, и был затем успешно забанен добавлением хешей в переменную dbx).
— проблемы с Windows 7 у ASUS возникли потому, что ASUS до сих пор грубо нарушает спецификацию, позволяя включать SecureBoot вместе с CSM, что не имеет никакого смысла.
— чтобы бы там в MS не говорили, пока жив CSM, на десктопных системах всегда будет возможность отключения SecureBoot, потому что иначе CSM нормально не реализовать.

Если вам интересно, как работал SecureBoot во времена UEFI 2.4 - вот моя практическая статья о нем. С тех пор внесли немного изменений, добавив режим аудита для того, чтобы не мучатся с подписыванием ОРОМов доверенных устройств, но суть осталась та же.

В этой же статье вот это «введение в EFI» не нужно совершенно, потому что режим AHCI (вместо устаревшего native IDE и еще более древнего legacy IDE) появился раньше UEFI и не имеет к нему отношения, а GPT для EFI не является обязательным типом разметки. Написали бы лучше про необходимость драйвера NvmExpressDxe для загрузки с NVMe-накопителей и про опыт добавления этого драйвера в прошивку / загрузки его с ESP в случае, если прошивка старая и об NVMe еще ничего не знает.
Раньше AGESA поставлялась в исходниках и была доступна для модификации любому желающему, но теперь AMD ударилась в PSP, начиная с Beema/Mullins для APU и Ryzen для CPU, прошивка которого в свою очередь подписана и зашифрована, и занимается он на этих процессорах не только реализацией fTPM, но и тренировкой памяти, т.е. ни отключить его, ни заменить его прошивку своей нельзя. В итоге от AGESA осталась теперь только обертка вокруг PSP и его встроенной ОС, которая с каждым новым поколением все тоньше.
Дело ваше, но эта «война буллшитов» всегда заканчивается одинаково — на рынке не остается нормальных продуктов, т.к. все вообще начинают декларировать 100% защиту от всего, интеграцию со всем, встроенную кофе-машину и кнопку «сделай мне зашибись!». Как с антивирусами сейчас.

Если вы будете писать «мы устранили уязвимости в открытом ПО», не удивляйтесь, что от вас отвернутся и те, кто действительно ищет и устраняет уязвимости, и те, кто разрабатывает открытое ПО. Буллшит рекламный не любит никто, и даже если конкуренты уже вовсю обмазываются им — присоединяться, на мой взгляд, не стоит.
С этим я не спорю, это правильное применение статического анализатора и я тоже применяю его для тех же целей. Спорю я с использованием в рекламных материалах слова «vulnerability», которое слишком сильное в данном случае. Плюс еще с тем, что «дефект безопасности» — это хороший термин для CWE. Дефект, на самом деле, не безопасности, а ПО, и ищет анализатор дефекты/недостатки/изъяны/слабости именно в коде, а не в «безопасности».
Я на одной стороне с разработчиками, но считаю, что продавать статический анализатор с лозунгом «stop vulnerabilities», и использовать это очень сильное слово в статьях и пулл-реквестах — хороший способ создать о себе негативное впечатление продавцов воздуха.
Нельзя называть уязвимостью то, что не участвует в атаке. Критерий — наличие PoC, если а PoC нет, это слабое место, недостаток (а не «дефект безопасности», чтобы не значил этот странный термин), что угодно, только не уязвимость.
Я понимаю, что вы хотите сказать, и даже понимаю, зачем именно, но называть любую обнаруженную «weakness» словом «vulnerability» — это буллшит чистой воды, потому что это максимум «potential security issue».
Мужики, у вас отличный продукт без дураков, и хорошая рекламная стратегия (была, по крайней мере) со всеми этими статьями, но не скатывайтесь, прошу вас, в рекламу змеинного масла.
PVS-Studio находит не «уязвимости», а «слабые места в коде, которые могут привести (или не привести) к уязвимости». По настоящему с уязвимостями борятся технологии предотвращения эксплуатации вроде VBS, CFG, RAP, и т.п. Вот слайды с недавнего доклада специалистов из Microsoft о них.
Я не о том, что вы их не ищите, а о том, чтобы маркировать их сильнее в списке ошибок, потому что их потенциальный вред сильнее. Хотя бы не по умолчанию, а в качестве настройки.
Вы пишете слово «vulnerability» на своих КДПВ, хотя речь идет о «weakness». Первое — это то, что на русский язык переводится словом «уязвимость», она же немного слабее «security issue», т.е. «проблема безопасности». Второе — это то, что вы переводите как «дефект», а я — как «слабость» или «недостаток». Словосочетание «дефект безопасности», в которое превратилось «weakness» — оно очень странное, и я действительно путаюсь в нем. «Дефект», мне кажется — намного более сильное слово, чем «слабость» или «недостаток», но я могу ошибаться. «Потенциальная проблема безопасности» — вот что такое «weakness», на мой взгляд.
В общем, я про то, что лучше добавлять слово «потенциальные» ко всем вашим «дефектам безопасности», пока к каждому из них не написан PoC-эксплоит.
СиПроВер, пожалуйста, не путайте CWE и CVE, хоть оба списка и ведет одна и таже MITRE, но именно к настоящим проблемам безопасности первый список имеет весьма опосредованное отношение.
Для того, чтобы ошибка в программе стала настоящей проблемой безопасности, она должна быть эксплуатируема, т.е. для нее должно быть найден способ использования в целях, которые ставит перед собой атакующий. И пока такой способ не найден, все эти вышеописанные вещи так и остаются «слабостями», а не проблемами безопасности. Широко известный в узких кругах журнал PoC||GTFO не зря называется именно так. ;)
Если вы действительно хотите помочь пометить серьезные проблемы, связанные с безопасностью, начните предупреждать громче, чем обычно (т.е. с приоритетом 0 вместо 1 и красным цветом) хотя бы о следующих вещах:
  • use-after-free, в прямых руках это практически гарантированный WWW с последующии грабежом, убийством и надругательством над гусями
  • проблемах с потоком управления (goto fail)
  • чтении неинициализированных переменных и областей памяти (Heartbleed/Cloudbleed) и записи за границы массивов (слишком длинный список примеров, чтобы его тут приводить)

Information

Rating
Does not participate
Date of birth
Registered
Activity

Specialization

Инженер встраиваемых систем, Системный инженер
Ведущий