Компания Oracle объявила (https://blogs.oracle.com/wim/entry/secure_boot_support_with_...) о реализации в выпуске дистрибутива Oracle Linux 7.1 возможности верификации процесса загрузки на системах с UEFI Secure Boot. Мэтью Гаррет (Matthew Garrett), один из разработчиков ядра Linux, активно занимающийся обеспечением загрузки Linux на системах с UEFI, выступил (http://www.theregister.co.uk/2015/03/15/oracle_adds_secure_b.../) с критикой поддержки UEFI Secure Boot в Oracle Linux и указал на серьёзные проблемы с безопасностью, позволяющие выполнить произвольный код, незаверенный цифровой подписью.
Механизм UEFI Secure Boot позволяет гарантировать использование на этапе загрузки системы только оригинальных компонентов, заверенных цифровой подписью. В RHEL и Oracle Linux, при использовании UEFI Secure Boot, обеспечивается проверка загрузчика, ядра, загружаемых ядром драйверов и модулей ядра. Для обеспечения защиты от выполнения непроверенных компонентов, при загрузке с верификацией в ядре необходимо отключить ряд возможностей, таких как вызов kexec и интерфейсы, позволяющие вносить изменения в память ядра из пространства пользователя. В частности, кexec предоставляет возможность загрузки нового ядра из уже запущенного ядра Linux, что может быть использовано для обхода UEFI Secure Boot путём замены проверенного ядра на другое ядро, не снабжённое цифровой подписью.
Как известно, в Oracle Linux кроме клона ядра из состава RHEL также поставляется собственный вариант ядра Unbreakable Enterprise Kernel (https://www.opennet.ru/opennews/art.shtml?num=41398), поддерживаемый силами Oracle. Проблема состоит в том, что цифровые подписи для обоих ядер созданы с использование одного ключа. Если в клоне ядра RHEL при загрузке в UEFI Secure Boot производится отключение опасных компонентов ядра, то в ядре Unbreakable Enterprise Kernel остаётся активен kexec, что сводит на нет всю цепочку доверия. Даже при использовании ядра RHEL в Oracle Linux, атакующий имеет возможность загрузить имеющее корректную цифровую подпись ядро Unbreakable Enterprise Kernel, а затем через kexec запустить модифицированный вариант ядра с бэкдором.
Интересно также то, что ключ для создания цифровой подписи для Oracle Linux назван "oracle301", при том, что число 301 выбрано так как ключ в RHEL тоже оканчивается на 301, но без учёта того, что 301 не имеет принципиального значения и является лишь порядковым номером сгенерированного в Red Hat ключа.URL: http://www.theregister.co.uk/2015/03/15/oracle_adds_secure_b.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=41852
На третий день Зоркий Глаз заметил что у сарая нет стены...
...только три стены
> Интересно также то, что ключ для создания цифровой подписи для Oracle Linux назван "oracle301", при том, что число 301 выбрано так как ключ в RHEL тоже оканчивается на 301, но без учёта того, что 301 не имеет принципиального значения и является лишь порядковым номером сгенерированного в Red Hat ключа.Вывод отсюда какой? Правильно, Oracle копипастит из RHEL, даже не понимая как это работает. Еще и суппорт какой-то оказывать пытаются.
возможно у них тупо есть подписка на суппорт от RH и они форвардят обращения туда от своего имени)
> Вывод отсюда какой? Правильно, Oracle копипастит из RHEL, даже не понимая как это работает. Еще и суппорт какой-то оказывать пытаются.Подождём и посмотрим как поступят ВНИИНС со своим МСВС?
Идеально!
Лет через 15 узнаем, раньше врядли
Предлагаю переименовать ключ oracle301 в oracle42
что-то мне кажется, что имеется намного больше способов обхода UEFI Secure Boot, просто вопрос слабо изучен
Ну грубо говоря если ты можешь переписать uefi то и Secure Boot обойти не проблема.
>UEFI Secure BootОно не для безопасности создано. А для того чтобы запретить пользователям устанавливать ОС отличные от микрософтовских.
> Оно не для безопасности создано. А для того чтобы запретить пользователям устанавливать ОС отличные от микрософтовских.Однако если контроль над ключами в руках у пользователя - то это хорошая, годная технология по hardening-у ОС.
> Однако если контроль над ключами в руках у пользователя - то это
> хорошая, годная технология по hardening-у ОС.Единственная проблема: Boot Guard от интеля подразумевает однократное вшивание хэша мастерключа в чипсет. Далее этот мастерключ заверяет бутблок, который проверяет BIOS/UEFI, ну и так далее. Поэтому предлагается на честное слово поверить проприерасам с мутным бэкдореным уефанством что их мутный блоб делает по части ключей именно то что вы попросили, а не что-нибудь еще. А попытки взять управление на себя путем прошивания своего BIOS по типу опенсорсного coreboot - безнадежно зарублены.
Поэтому ваше условие в большинсве случаев false в случае х86, как минимум на поздних процах и чипсетах интеля. Как максимум проприерасы выдают вам фэйк-абстракцию делая вид что вы управляете вашими ключами. Но проверить без сорца вы не можете, равно как и использовать например опенсорсное фирмваре где все заведомо честно.
Ну так Boot Guard - это другая технология, при чём здесь он?
> Ну так Boot Guard - это другая технология, при чём здесь он?Вот именно.
> Ну так Boot Guard - это другая технология, при чём здесь он?А при том что
1) Без него секурбут не полный. Ведь недруг может потенциально перелить фирмваре на пропатченое.
2) Поэтому появляется BootGuard. И когда вопрос становится ребром: на кого залочить железку, при том что лок прописывается в фюзы 1 раз и навсегда - ВНЕЗАПНО оказывается что мастерключ не ваш и вам его давать никто не собирается. Девайс лочится на вендыря и рулится вендырем. А вы там можете верить ему на честное слово что его мутный многометровый блоб делает то что показывает в настройках сетапа, а не что-нибудь другое. А можете и не верить, все-равно вы никуда не денетесь с подводной лодки.
Угу. Только в отличие от UEFI, худо-бедно ставшего стандартом, Secure Boot - это факультативная дурь интела. Причём на десктопе и сервере, где заведомо съёмный проц (а то и самосбор), эта "фича" вообще вряд ли когда-либо появится. На приличныйх ноутах тоже процессор меняется - так что в худшем случае обойдётся в стоимость нового камня. В общем, даже если ограничиваться интелом вариантов предостаточно. А для юзерских повседневных нужд - проблем никаких. Да и у гиков я как-то не вижу повальной смены биосов на открытые. Я бы понял стоны, если хотя бы одна десятая (да хоть сотая!) процента биосов перешивалась на что-то. Но этого же и близко нет.
А UEFI - такой же стандарт как ACPI. В смысле, реализуется какими-то левыми блобами без сорцов, с кучей багов, по принципу "винда вроде как-то работает, ну и ладно". Нафиг-нафиг таких стандартизаторов, они себя дискредитировали по всем фронтам.
> На приличныйх ноутах тоже процессор меняется - так что
> в худшем случае обойдётся в стоимость нового камня.Насколько я понимаю, шьется в чипсет. Удачи тебе в перепайке BGA...
ну на счёт "опенсорсное фирмваре где все заведомо честно" ты конечно чуток переборщил..
> ну на счёт "опенсорсное фирмваре где все заведомо честно" ты конечно чуток переборщил..Пока-что авторов coreboot, u-boot и прочая как-то не ловили на вещах типа AWARD_SW и мастер-пароля на управление через BMC как у супермикры.
> Пока-что авторов coreboot, u-boot и прочая как-то не ловили на вещах типа
> AWARD_SW и мастер-пароля на управление через BMC как у супермикры."В пьянстве замечен не был, но по утрам жадно пил холодную воду"
такого беспредела, как ты написал, конечно быть не должно.
Но это не отменяет возможности различных подстав ввиду "анонимизма" авторов и IOCCC
и поди потом докажи что это "кнопкой ошибся", а не целенаправленно пилил под поставленную кем-то задачу.
>> Пока-что авторов coreboot, u-boot и прочая как-то не ловили на вещах типа
>> AWARD_SW и мастер-пароля на управление через BMC как у супермикры.
> "В пьянстве замечен не был, но по утрам жадно пил холодную воду"
> такого беспредела, как ты написал, конечно быть не должно.
> Но это не отменяет возможности различных подстав ввиду "анонимизма" авторов и IOCCC
> и поди потом докажи что это "кнопкой ошибся", а не целенаправленно пилил
> под поставленную кем-то задачу.Но это уже запилить и оставить ненайденным намного сложнее, чем в открытую запихать скрытый вход по "правильному стуку"
> Но это уже запилить и оставить ненайденным намного сложнее, чем в открытую
> запихать скрытый вход по "правильному стуку"судя по результатам (где-то новость на опеннете проскакивала, не могу найти)
ва-аще не сложно
> судя по результатам (где-то новость на опеннете проскакивала, не могу найти)
> ва-аще не сложноЭто вы не про то как в линухе при попытке коммита бэкдора он был запален? :)
> Это вы не про то как в линухе при попытке коммита бэкдора
> он был запален? :)не, не оно
> такого беспредела, как ты написал, конечно быть не должно.Более того - проприерасы себя уже дискредитировали и на честное слово им верить теперь нет оснований. А когда они еще при этом еще наручниками к батарее имени boot guard'а приковывают - сразу такая безопасность, такая безопасность.
> Но это не отменяет возможности различных подстав ввиду "анонимизма" авторов и IOCCC
Там по крайней мере код видно. А как бы НеАнонимные сотрудники аварда, ами, супермикры и прочих - вкатили бэкдоры и ... и что им за это было? Аааась?!
> и поди потом докажи что это "кнопкой ошибся", а не целенаправленно пилил
> под поставленную кем-то задачу.Ну а блоборасы даже и не скрывают уже что это бэкдоры. В лучшем случае вяло отбрехиваются про инженерные парли (в эту идиoтию еще кто-то верит?).
> Там по крайней мере код видно. А как бы НеАнонимные сотрудники аварда,
> ами, супермикры и прочих - вкатили бэкдоры и ... и что
> им за это было? Аааась?!ну, а что будет анонимному патчеру? аась?
и кстати, что было автору хартблида? аась?
Короче, не парьте мне мозги.
А поклонники фразы "опенсорсное фирмваре где все заведомо честно" могут смело выставлять технологические порты в инет - у них же всё честно
> ну, а что будет анонимному патчеру? аась?Потеря доверия и как минимум нужда убить заново кучу времени (годы!!!) на выращивание нового виртуала и втирание в доверие. Которое будет продолбано после очередной попытки.
В результате вкатить бэкдор ну не то что фундаметально невозможно, но намного выше риск запала и сильно выше затраты. По поводу чего на старте я по умолчанию доверять открытому коду буду зело больше чем закрытому.
> и кстати, что было автору хартблида? аась?
Во первых, автор серьезно подмочил свою репутацию. Известно кто он и прочая. И думаю теперь у него будут сложности с коммитами в security-sensitive проекты.
Во вторых, проект в целом репутацию подмочил прилично и аудит пошел изрядный. Появилась пара версий с менее ДЛБ-ским управлением и большей тщательностью приема коммитов. Вон всякие либрссл и так далее.
Но на самом деле это высветило намного более иные проблемы.
- SSL/TLS сложен и содержит кучу опций и легаси. Ну ясен фиг там будет куча багов. В любой реализации. Даже в polarssl нашли, что уж там про этого монстра говорить.
- OpenSSL вообще ДЛБскя либа. С неадекватным апи и кучей багов. И неадекватом в крипто. И дурной лицензией. Я не знаю чего все за это ГЭ так ухватились. Наверное buzzword "open" так действует.> Короче, не парьте мне мозги.
Ну так валите на течнет и там вас поймут с рассказами о проприерасах.
> А поклонники фразы "опенсорсное фирмваре где все заведомо честно" могут
> смело выставлять технологические порты в инет - у них же всё честноДля начала, когда BMC имеет доступ к "сетевому интерфейсу вообще" - при этом достаточно воткнуть провод с выходом в сеть. И все, вас можно поиметь. И фаер в OS на основном проце от этого не спасет.
И да, что вы хотите сказать? Что поднасироны от блобмейкеров это так и надо? Нет, мне так нафиг не надо. По поводу чего я совершенно искренне желаю блобмейкерам именно того чего они заслуживают.
> старте я по умолчанию доверять открытому коду буду зело больше чем
> закрытому.ты вообще читал о чём я говорил?
> Во первых, автор серьезно подмочил свою репутацию. Известно кто он и прочая.
> И думаю теперь у него будут сложности с коммитами в security-sensitive
> проекты.а я думаю он мог на ней уже озолотиться - и коммиты в эти проекты ему уже нафик не нужны
> Ну так валите на течнет и там вас поймут с рассказами о
> проприерасах.ты вообще читал о чём я говорил?
> Для начала, когда BMC имеет доступ к "сетевому интерфейсу вообще" - при
> этом достаточно воткнуть провод с выходом в сеть. И все, вас
> можно поиметь. И фаер в OS на основном проце от этого
> не спасет.спасибо за уточнение, я в курсе. Фраза была для примера (неудачного)
> И да, что вы хотите сказать? Что поднасироны от блобмейкеров это так
> и надо?ещё раз, ты вообще читал о чём я написал выше?
> Поэтому предлагается на честное слово поверить проприерасам с
> мутным бэкдореным уефанством что их мутный блоб делает по части ключей
> именно то что вы попросили, а не что-нибудь еще. А попытки
> взять управление на себя путем прошивания своего BIOS по типу опенсорсного
> coreboot - безнадежно зарублены.А что ещё их мутный блоб может делать с ключами?
Он должен проверять подпись загружаемой системы. Можете проверить, что проверяет, и неправильно подписанное не загружается.
Может статься, что там есть возможность обойти ваш ключ. Но если её туда вставил производитель... То он в общем-то скорее и так не имел бы сложностей сделать замену БИОС... (если имел бы доступ)...
Хотя технология и по-моему слишком явно оставляет желать лучшего так сказать.
Хы! Да кто же им, зверькам то есть, позволит что-то там контролировать и тем более отключать? Это все их влажные мечты и не более того. Ничего они не контролируют и полезность этой технологии для них - со знаком минус.Ну позволят им какое-то время побаловаться со своими ключами... пока производители матерей не подсели на UEFI полностью и окончательно... а потом жестко заблокируют. Придумают оправдание или оговорку какую и залочат смену ключей. Раз есть пушка, - то грех не пальнуть из нее, верно? Тем более что пальба ведется по карману потребителя. Да еще и с большущим профитом для стрелков.
> Хы! Да кто же им, зверькам то есть, позволит что-то там
> контролировать и тем более отключать? Это все их влажные мечты и
> не более того. Ничего они не контролируют и полезность этой технологии
> для них - со знаком минус.
> Ну позволят им какое-то время побаловаться со своими ключами... пока производители матерей
> не подсели на UEFI полностью и окончательно... а потом жестко заблокируют.
> Придумают оправдание или оговорку какую и залочат смену ключей. Раз есть
> пушка, - то грех не пальнуть из нее, верно? Тем более
> что пальба ведется по карману потребителя. Да еще и с большущим
> профитом для стрелков.Стрелки рискуют лишиться пачек бабла. Сделает интель - АМБ начнёт гарцевать своим кор бутом и активно занимать полки в серверных, а интель будет продавать свои процы в гейбуки и вспоминать с тоской о бодром прошлом.
А если они договорятся так не делать, а? Или "АМБ" тупо подсчитает, что если интел залочит, то и им выгоднее будет все-таки залочить, чем разлочивать?
> А если они договорятся так не делать, а? Или "АМБ" тупо подсчитает,
> что если интел залочит, то и им выгоднее будет все-таки залочить,
> чем разлочивать?Легко. Это бизнес и первое место это интересы бизнеса. Клиент всего лишь на втором месте. Ну так, по чесноку.
>>UEFI Secure Boot
> Оно не для безопасности создано. А для того чтобы запретить пользователям устанавливать
> ОС отличные от микрософтовских.UEFI позволяет использовать свою собственную связку ключей, чтобы запретить установку ОС, отличных от Linux.
>>>UEFI Secure Boot
>> Оно не для безопасности создано. А для того чтобы запретить пользователям устанавливать
>> ОС отличные от микрософтовских.
> UEFI позволяет использовать свою собственную связку ключей, чтобы запретить установку
> ОС, отличных от Linux.Ещё раз - UEFI ничем таким не занимается в принципе. Етим занимается SecureBoot, чсх не везде он есть и не везде тем более включен. МС секьюр бут толкал чтобы попытаться решить проблему лоадеров винды дабы продолжать махать веслом на ветряные мельницы, но сейчас у них проблемы похлеще чем пираты и вся их монополия начинает трещать по швам ибо казуальные юзвери дружно бегут на иОСы с Андроидами.
Да, вы правы, просто UEFI не живёт без Secure Boot, как мне казалось.
> Да, вы правы, просто UEFI не живёт без Secure Boot, как мне
> казалось.Живёт и ещё как. Это наоборот - SecureBoot живёт только на UEFI. Производителям секьюр бут требуется только для сертификации восьмой винды, что допустим, для серверных стоек - как собаке пятая нога и второй хвост, там производители могут вообще забить на реализацию этой фигни. На лэптопах и рабочих станциях меня куда больше стремают дугие технологии интеля с TPM, anti-theft с 3Г модемчиком, локом всех функций и т.д. А пока что в спецификацию секьюр бута входит требование иметь возможность это отключить. Не помню есть ли требование к укправлению ключами но на всех виденых реализациях это было (выпилиываешь ключи МС, вставляешь свои, живёшь долго и счастливо, пока не узнаёшь что у тебя на уровне ЦПУ бэкдор :) ).
> и рабочих станциях меня куда больше стремают дугие технологии интеля с
> TPM, anti-theft с 3Г модемчиком, локом всех функций и т.д.Ну так интель дает понять что это они рулят железкой, а не ты. Зато очень удобно. США ввели санкции. Количество theft'ов увеличилось вдвое...
> UEFI позволяет использовать свою собственную связку ключей, чтобы запретить установку
> ОС, отличных от Linux.Точнее, для мутного проприетарного блоба фирмвари номинально декларируется что оно вот так. А насколько это по факту соответствует действительности и какие там AWARD_SW для себя оставил производитель - извольте дизассемблить ...цатимеговое фирмваре, типа.
Маркетинг решает. Все забудут зачем UEFI. И что она плохо работает, тоже забудут.
Не путайте UEFI и Secure Boot. Это НЕ одно и тоже.
Вот и я о том же не путайте. UEFI работает плохо.
А с secure boot сложнее получить загрузочный вирус.
> Вот и я о том же не путайте. UEFI работает плохо.
> А с secure boot сложнее получить загрузочный вирус.всё это смахивает на эволюционную борьбу за пользователя между бэкдорами производителей и загрузочными вирусами.
Кто победит интересно?
> Кто победит интересно?Победила "Дружба" - пробурчал дровосек. В смысле, вся эта живность будет иметь юзерье, а воевать друг с другом им в общем то и не особо надо.
> Вот и я о том же не путайте. UEFI работает плохо.
> А с secure boot сложнее получить загрузочный вирус.Если супермикро внаглую шьет бэкдор прямо в фирмварь BMC - удачи вам в вашей защите от вирусов :)
железо с uefi нужно было байкотировать, а теперь приходится терпеть и тратить время впустую
Правильное железо дает возможность эту гнойную заразу выключить. А не правильное - у есть 14 дней на возврат товара, по причине - нет возможности использовать по прямому назначению из-за "Vendor Lock".
> Правильное железо дает возможность эту гнойную заразу выключить.Простите, но в поздних интеловских процах и чипсетах есть countermeasure который не даст сменить черти-какой bios делающий черт знает что на опенсорсную фирмварь которой реально можно доверять по части того что boot sequence - именно такой как ожидается, а не что-нибудь еще, с сюрпризами и бэкдорами. Никаких оснований доверять производителям AWARD_SW - нет. А заменить западло от западлостроителей теперь не даст проц и чипсет.
Как-то я слабо представляю вшитый ключ в процессорах, купленных отдельно в магазине, а не впаянных в мать, так что при желании эта проблема решается тривиально.
> Как-то я слабо представляю вшитый ключ в процессорахА зря. Потому что именно это интеловцы и тащщють на рынок сейчас. Вот полюбуйтесь http://hi-news.ru/hardware/mobilnye-processory-intel-merrifi...
Речь пока идет правда только о мобильных процессорах, но ведь лиха беда начало, верно?
Ну так я ж написал дальше - "Купленных отдельно в магазине". Какой именно ключ туда шить, если не известно, в какую мать его сунут? А то, что впаяно в мать - ну, беда-печаль тем, кто такое купил. Есть альтернативы - от AMD до ARM.
> Как-то я слабо представляю вшитый ключ в процессорах, купленных отдельно в магазине,Оно IIRC вшивается в чипсет. А так - купил ты ноут. А он залочен не на тебя и твой ключ, а на ключ вендора. И ты делаешь deep throat вендору и его биосу.
Насколько я читал - вшивается в CPU. И да, в приличных ноутбуках (хотя ноутбук, конечно, всегда урод) так и так процессор меняется. Плюс есть AMD и ARM. Учитывая, что смена биоса и сейчас, мягко говоря, не слишком распространена - по-моему шум по этому поводу слишком велик.
> Насколько я читал - вшивается в CPU.А вроде coreboot'овцы говорили что фьюзы в чипсете.
> И да, в приличных ноутбуках (хотя ноутбук, конечно, всегда урод) так и
> так процессор меняется.Да я не сомневаюсь что интел продаст новые чипсет, проц и даже весь ноут. За отдельное баблo. А то что купил по дефолту - залоченая троянская коняшка, работающая на левых хренов за бугром.
> говоря, не слишком распространена - по-моему шум по этому поводу слишком велик.
Шум по поводу того что PC под оправданиями защиты от плохих парней заканчивает существование как открытая промышленная платформа, превращаясь в walled garden имени микрософта. А ты думал что эти бут-гады и секурбуты для защиты тебя от чего либо? То как это сделано - прозрачно намекает для чего этого.
> железо с uefi нужно было байкотировать, а теперь приходится терпеть и тратить
> время впустуюЕщё один путающий UEFI c SecureBoot-ом? Прицепить замок не дающий сменить прошивку можно и на биос, чем уже давно и успешно занимаются Леново и Деллы.
Лично я давно путаю UEFI с говном. Достаточно оправданно.
"байкотировать" - это на байках, что-ли? Откуда у вас байки, нестирано-сальножелёзные?
А кто должен был бойкотировать? Оба твоих нездоровых друга? Ну, они и бойкотируют и даже бубунту на улице как-то раздавали. Ну и чо?
Байкотировать! А также Килобайкотировать, Мегабайкотировать и Гигабайкотировать!
> Байкотировать! А также Килобайкотировать, Мегабайкотировать и Гигабайкотировать!Ну и сидите с лучиной, кому хуже-то?!
http://www.youtube.com/watch?v=ths65a9LH6Y
А может ну его нафиг этот Secure Boot?
Уже может пора понять, что на уровне доступа к железу надо реализовать безопасность?
> А может ну его нафиг этот Secure Boot?
> Уже может пора понять, что на уровне доступа к железу надо реализовать
> безопасность?Естественно, помню крепили провода от мышек и клав + замок на корпус. Единственная острая проблема была с шариковыми мышками, воровали шарики по страшному.
> А может ну его нафиг этот Secure Boot?
> Уже может пора понять, что на уровне доступа к железу надо реализовать
> безопасность?SecureBoot реализует защиту от замены ядра ОС и подмены её на липовый загрузчик. Естественно делает это коряво и с дырами. :)
перечисляйте дыры.
> перечисляйте дыры.Проприетарь же. Вон у супермикры нашелся инженерный логин в фирмвари BMC. Всего ничего. А AWARD и AMI сто лет как делали мастер-пароли на BIOS, по типу AWARD_SW (через который я однажды лично вломился на запароленый биос). Доверять этим блобмейкерам на слово? Нет пути.
>> перечисляйте дыры.
> Проприетарь же. Вон у супермикры нашелся инженерный логин в фирмвари BMC. Всего
> ничего. А AWARD и AMI сто лет как делали мастер-пароли на
> BIOS, по типу AWARD_SW (через который я однажды лично вломился на
> запароленый биос). Доверять этим блобмейкерам на слово? Нет пути.То есть по сути ответить нечего? раз идет переход на какие-то странные утверждения.
Еще раз - у вас просили список багов.. где этот список?а award_sw - это некоторые производители материнок - не выключили дефолт при сборке под себя.
Правда в этом виноват производитель биоса? или может производитель материнок?
> То есть по сути ответить нечего? раз идет переход на какие-то странные
> утверждения.Вы просили перечислить. Я привел два вопиющих бэкдора, реально существующих. Чем вы недовольны? :)
> Еще раз - у вас просили список багов.. где этот список?
Я привел список бэкдоров. Это даже суровее.
> а award_sw - это некоторые производители материнок - не выключили дефолт
Ну да, а вон тот лох, чьи кишки висят на дереве - забыл миноискатель дома и не выключил мину, которую добрый сосед активировал по дефолту. Так чтоли получается?
> Правда в этом виноват производитель биоса?
Нет, ну что вы, это Вася Пупкин мастерпароль встроил. Правда странно почему пароль не PUPKIN_SW получился ;). А то что бэкдором мог пользоваться еще и производитель - ну, круто. Но кодил бэкдор таки Award проприерастический.
> или может производитель материнок?
Не, вот извините. Фичу накодил Award, как впрочем и AMI и еще некоторые. К ним и вопросы - нафига они это кодили. И супермикро, пхающий бэкдоры - тоже блин нечаянно забыли мастер пароль в коде. Интересные такие случайности у проприерасов. Пусть они тоже случайно упадут кому-нибудь лицом на кулак за такие фокусы. Пять раз подряд.
Кому надо такое - запретит запуск kdump через нужный kernel command line. И поставит запрет на изменение.
Что-то отдает какой-то желтизной новость.
В Linux всегда оставляли все ручки, для того чтобы настроить под конкретный случай. В чем проблема то? Кто-то не знает, где эта _возможность_ отключается? Тогда о какой безопасности может идти речь с таким админом? Будем как в винде ориентироваться только на домохозяек? Так они возьмут другой дистрибутив - более домохозяекфрендли (тот же минт, например). Но на сервере важнее иметь возможность сменить ядро без перезагрузки. Ораклу однозначно плюс, а UEFI пусть идет лесом, пока закрыт
> Что-то отдает какой-то желтизной новость.
> В Linux всегда оставляли все ручки, для того чтобы настроить под конкретный
> случай. В чем проблема то? Кто-то не знает, где эта _возможность_
> отключается? Тогда о какой безопасности может идти речь с таким админом?
> Будем как в винде ориентироваться только на домохозяек? Так они возьмут
> другой дистрибутив - более домохозяекфрендли (тот же минт, например). Но на
> сервере важнее иметь возможность сменить ядро без перезагрузки. Ораклу однозначно плюс,
> а UEFI пусть идет лесом, пока закрытВопрос не в домохозяйках, а в том, что Оракл тырит код не врубаясь в то что копирует. Если уж включать secureboot (а его нужно включить, он от сырости не заводится сам по себе у хорошего админа), то тогда и опцию ядра надо отключать, а тут оракл вроде скопировал реализацию, но не до конца, сделав включение секьюр бута бесполезным, оставив дырку позволяющую перезагрузить ядро другим. Причём бездумность копирования доходит тупо до замены redhat -> oracle, если даже в имени ключа порядковый номер генерации не сменили, а заменили только редхат на оракл. Какой уж тут ораклу плюс? За кривые руки, за бездумность или за что?
Это у оракула бзик на "совместимости". Они даже настоящую версию ядра долго говорили старую, чтобы программы какие-то не сломались.
Как неожиданно... От оракла я такого не ожидал.
Новость-то ни о чем :) Еще "спецы" пытаются над Ораклом смеяться, типа копипастят рэдхатовский код, сами ничего не понимают. Поверьте, в такой компании по определению не может быть сотрудников, чей уровень знаний ниже ваших.
> Новость-то ни о чем :) Еще "спецы" пытаются над Ораклом смеяться, типа
> копипастят рэдхатовский код, сами ничего не понимают. Поверьте, в такой компании
> по определению не может быть сотрудников, чей уровень знаний ниже ваших.Talk is cheap, show me the code.
Какой бы не был уровень этих сотрудников, результат их работы налицо и он говорит об их уровне куда больше чем ваше "поверьте".
да? новость не о чем. kdump надо еще специально включить.Новость однозначно попытка шапки дискредитировать Oracle.
уборщицы с высшим образованием...
А у тебя специализация "уборщик"? :) Возможно, что и там тебе фору дадут в некоторых моментах:) Сравнивай себя с людьми, которые занимаются тем же делом, что и ты, а не с уборщиками или Ларри Эллисоном :)
Да, как комменты с опнета почитаешь - такое впечатление, что здесь самая кодерская косточка собирается. А на деле кунсткамера, маги пхп и пистона, гении верной расстановки переменных при сборке.
> Поверьте, в такой компании
> по определению не может быть сотрудников, чей уровень знаний ниже ваших.хорошо лизнул.
> Компания Oracle объявила (https://blogs.oracle.com/wim/entry/secure_boot_support_with_...)
> о реализации в выпуске дистрибутива Oracle Linux 7.1 возможности верификации процесса
> загрузки на системах с UEFI Secure Boot. Мэтью Гаррет (Matthew Garrett),
> один из разработчиков ядра LinuxЗаменяем слово "разработчик ядра" - на "сотрудник redhat" и все становится на свои места. Просто черный пиар - в попытке оттянуть клиентов. Жаль что Opennet - ориентируется на сильно аганжированные новости.
То есть в Oracle Linux нет включенного kexec? А если есть это не позволяет обойти цепочку доверия? Вас так надо понимать?
> То есть в Oracle Linux нет включенного kexec? А если есть это
> не позволяет обойти цепочку доверия? Вас так надо понимать?Надо понимать - что если в руководстве написано - что если вам надо макс безопастность - вам надо зайти и отключить kexec - то это фича а не бага.
А вот то что у RedHat перестает работать kexec автоматом - это уже бага. Случись что и получить отладочную инфу никак.Или это сильно сложно для вас?
>> То есть в Oracle Linux нет включенного kexec? А если есть это
>> не позволяет обойти цепочку доверия? Вас так надо понимать?
> Надо понимать - что если в руководстве написано - что если вам
> надо макс безопастность - вам надо зайти и отключить kexec -
> то это фича а не бага.
> А вот то что у RedHat перестает работать kexec автоматом - это
> уже бага. Случись что и получить отладочную инфу никак.
> Или это сильно сложно для вас?Надо понимать - что если в руководстве написано - что если вам
надо макс безопастность - вам надо зайти и отключить telnet с
рут доступом без пароля, то это фича, а не бага.А вот то что у RedHat перестает работать telnet автоматом - это
уже бага. Случись что и зайти по сети поправить никак.Так лучше? Если человеку не нужен SecureBoot - он его не включает. Если он хочет чтобы в загрузке каждый элемент проверял следующий загружаемый - то он его включает и ожидает что ОС будет действовать соответственно. Если Оракл хотели сделать поддержку загрузки на системах с SecureBoot оставив возможность грузить что угодно (предположим, что админ-наркоман купил сервер-удобрение, где криворукие китайцы сделали неотключаемый секьюр бут), то тогда ставится заглушка, которая грузит любое ядро и не задаёт вопросов. А тут мы имеем вроде как и проверку подписей ядра и прочую фигню, но рядом лежит неотключенный способ это обойти.
> То есть в Oracle Linux нет включенного kexec? А если есть это
> не позволяет обойти цепочку доверия? Вас так надо понимать?Нет. Не позволяет это обойти. Цепочку....
> Заменяем слово "разработчик ядра" - на "сотрудник redhat" и все становится на
> свои места.Matthew Garrett уже лет пять как не сотрудник Red Hat.
>> Заменяем слово "разработчик ядра" - на "сотрудник redhat" и все становится на
>> свои места.
> Matthew Garrett уже лет пять как не сотрудник Red Hat.С кем ты разговариваешь? Эти тормоза за пределы своих уютненьких не выходят никогда, они даже на портале Оракловом по жизни не были - им рабинович напел - а пойти туда глянуть религия не позволяет.
а гугл говорит что еще год назад был им.. что-то мне вам не верится.
> а гугл говорит что еще год назад был имСадись, двойка. Предыдущий оратор хоть гугли-фу не размахивал.
Last day at Red Hat
Nov. 9th, 2012
http://mjg59.dreamwidth.org/19695.html
Оракл всё правильно делает - секьюрбут это вредная технология, и поддержка её если и должна быть, то чисто формальная, чтобы обеспечить загрузку при включённом секурбуте.А по мне - его вообще не нужно реализовывать, нужно отключать везде и всё.
> Оракл всё правильно делает - секьюрбут это вредная технология, и поддержка её
> если и должна быть, то чисто формальная, чтобы обеспечить загрузку при
> включённом секурбуте.
> А по мне - его вообще не нужно реализовывать, нужно отключать везде
> и всё.Ну не смешите мои тапочки. Оракл - бунтари против системы, ага, три раза. В продакшне админам как раз очень удобно было бы знать что ядра на системе запустятся только те, которые подписаны их ключами, тут же элементарный косяк. Для галочки реализовали, кстати, канониклы - efi-shim, заглушка которая подписана ключом и запускает что угодно.
> заглушка которая подписана ключом и запускает что угодно.Только оно следует неким правилам. И автоматически и без спросу черти-что запускать не станет.
>> заглушка которая подписана ключом и запускает что угодно.
> Только оно следует неким правилам. И автоматически и без спросу черти-что запускать
> не станет.Оно загрузит груб, который загрузит любой кернел, который ему скажут, то есть проверки подписей не происходит и тут именно "обходится" secure boot, вместо использования его. В Федоре, например, при включении секьюр бута првоерка кернела происходит и кернел проверяет подписи модулей при загрузке, что выкидывает модуль невидии (нет в официальном репо, никто его подписывать не будет) - это реализация secureboot как оно задумывалось.
Кому-то может быть такое надо, но большинству проще выключить и забыть как страшный сон.
> Оно загрузит груб, который загрузит любой кернел, который ему скажут,Вроде как если грузится секурный загрузчик то и тот должен проверять что грузит. И упомянутый загрузчик требует или ручное подтверждение запуска, или прописывание ключа в доверяемые. По поводу чего незаметно запустить неподписанный код AFAIK не выйдет.
А если кто подписал grub который позволяет запустить что попало, без подтверждения и проверки подписей - при чем тут этот убунтуйский загрузчик то?
> происходит и кернел проверяет подписи модулей при загрузке, что выкидывает модуль
> невидии (нет в официальном репо, никто его подписывать не будет) -Ну так федора - тестлаб энтерпрайза, так что федорасы будут редхату все стены своим лбом сносить, для чего инужны. В убунте менее жесткая политика - ядро вгрузит левый модуль, но выставит taint и ругнется в лог, позволив админу узнать что система работает в недоверяемом режиме.
А реально с подписями те еще лулзы. Если пересобрать майнлайновый кернель, билдсистема с подписыванием модуелей немного косячит - ключ генерится, проверка есть. Но подпись некоторых модулей - отваливается. Что уж от остальных при этом хотеть...
> Кому-то может быть такое надо, но большинству проще выключить и забыть как
> страшный сон.На самом деле, поставить нвидию в позу - фича, а не баг :)
Ваще понять не могу о чем идет речь.Не пойму - есть железки где нельзя отрубить UEFI??
Даже в долбанном планшете от АЙСЕРА W700 на 8ке... в "BIOS" можно отрубить всё.
Линукс спокойно ставиться. (но к сожалению пришлось перепрыгнуть обратно на винду, без вменяемой виртуальной клавы во всех местах - как то стремно работается.)
> Ваще понять не могу о чем идет речь.
> Не пойму - есть железки где нельзя отрубить UEFI??
> Даже в долбанном планшете от АЙСЕРА W700 на 8ке... в "BIOS" можно
> отрубить всё.
> Линукс спокойно ставиться. (но к сожалению пришлось перепрыгнуть обратно на винду, без
> вменяемой виртуальной клавы во всех местах - как то стремно работается.)Если отрубить UEFI, то компьютер не загрузится. Можно отключить Secure Boot или перевести UEFI в режим совместимости (эмуляции BIOS).
> Если отрубить UEFI, то компьютер не загрузитсявсё верно. поэтому в железках и НЕ делают такой переключатель "отключить UEFI?" :)
а было бы прикольно -- выставил этот переключатель в OFF -- и неси комп на ремонт (в сервисный центр для перепрошивки, промышленным способом)....
....в этом случае умников стало бы в разы поменьше :-), которые думают будто бы SecureBoot это синоним UEFI (или которые думают будто бы имитация BIOS -- является якобы на самом деле не имитацией) :)
Да, соглашусь, ступил, не так описал то о чем подумал :)
Спасибо, посмеялся. :)
Тут выше писали про то, что очень мала доля тех, кто перешивает BIOS|UEFI на что-то своё, вроде coreboot.Товарищи, не надо путать причину и следствие: таких перешивок мало именно потому, что это очень трудно сделать, а трудности созданы искусственно со стороны производителей железа.
Не так-то просто, знаете ли, делать замену прошивке для железа, на которое нет сколь-нибудь вменяемых спеков, и которое, к тому же, этой самой перешивке активно сопротивляется.
>трудности созданы искусственно со стороны производителей железада-да, заговор злобных корпораций против белых и пушистых хомячков, мы в курсе
Вы так говорите, как будто эти проблемы _случайно_ возникли одновременно со всеми производителями железа.И нет, речь не идёт о чём-то вроде мирового заговора. Этим людям нужно примерно одно и то же, поэтому они совершают примерно одинаковые действия. Им не нужно специально договариваться для этого.
Никакой излишней паранойи, всего лишь прагматичная оценка, т.е. "смотри, кому выгодно".
> Вы так говорите, как будто эти проблемы _случайно_ возникли одновременно со всеми производителями железа.эти проблемы созданы были не случайно.. но и не специально против corebootчиков.
нет смысла производителям железа выкладывать спецификации. так как нет смысла делать лишню работу (работу по публикации спецификаций, и работу по правильному оформлению этих спецификаций.. и работу по поддержании всего этого архива в актуальном состоянии при изменении ревизии).
и работать с сообществом (отвечать на письма о запросах спецификаций) -- это тоже лишний труд для проихводителя. поэтому и нет работы с сообществом.. (а не для поддержания заговора)
Xasd, именно это я и имел в виду, когда уточнил, что "речь не идёт о чём-то вроде мирового заговора" и т.д.
> да-да, заговор злобных корпораций против белых и пушистых хомячков, мы в курсеНе, ну что ты. AWARD_SW случайно сам накодился в биосе. И бэкдор у супермикры в BMC - сам. И западлоидизированый биос не дающий сменить сетевки или модули памяти на нечто отличное от вендырского. А корпорасы что, они белые и пушистые, к западлу отношения не имеют.
award_sw мог быть в дебаг секции. Но факт в том что многие производители забыли выключить дебаг :-)
так что не надо искать сложности где простой прое.. б у индусов.
Сноуден описал как такие "простые баги" появляются. Да, случайно все - дебаг забыли убрать, забыли послать клиента нафиг, когда он запрашивает в heartbeat-е слишком много данных и так далее...
> award_sw мог быть в дебаг секции. Но факт в том что многие
> производители забыли выключить дебаг :-)а мне какая разница?
> award_sw мог быть в дебаг секции.А ты мог случайно упасть на кулак добрейшего гражданина. Случайно. И так пять раз.
> производители забыли выключить дебаг :-)
А мне какая разница? Бэкдор и есть бэкдор. А оправдания и виляния пoпой меня не сильно интересуют.
> так что не надо искать сложности где простой прое.. б у индусов.
Интересные такие про..бы. Надеюсь что в поезде, самолете или автомобиле в котором они будут ездить в сервисной фирмвари тоже окажется парочка забытых дебаг секций и прочих радостей.
> А мне какая разница? Бэкдор и есть бэкдор. А оправдания и виляния пoпой меня не сильно интересуют.Бэкдор делается с умыслом. а это про.. ...
> Интересные такие про..бы. Надеюсь что в поезде, самолете или автомобиле в котором они будут ездить в сервисной фирмвари тоже окажется парочка забытых дебаг секций и прочих радостей.
Ты даже не знаешь насколько ты прав. В софте для станций диагностики Мерседес - компилятор забыл мертвый код с паролями для перепрошивки флэшей которые имеют разные пароли на чтение и запись данных.
это тоже сознательный бэкдор ?
ps. о качестве кода биосов знаю слегка не понаслышке.
> Бэкдор делается с умыслом. а это про.. ...Был там умысел или нет, узнать невозможно. Поэтому чётко утверждать, что продолб странно.
видя код биосов и где находится данная опция - можно.
> видя код биосов и где находится данная опция - можно.Код BIOSов конечно лютейшее г-но, ОДНАКО без осмысленного желания того или иного индивида такая фича в принципе не может появиться. Так что никаких случайностей там в принципе быть не может - это точно не спихнешь на опечатки и прочее. Это вполне осмысленный кусок троянского кода.
девелопер кода - который использовался при тестировании паролей
> Бэкдор делается с умыслом. а это про.. ...Не представляю себе как можно накодить инженерный пароль без умысла. Нечаянно такое не кодится.
> Мерседес - компилятор забыл мертвый код с паролями для перепрошивки флэшей
> которые имеют разные пароли на чтение и запись данных.
> это тоже сознательный бэкдор ?Не очень понимаю как можно в коде впихать мастер пароль без умысла. Это как если бы серийный убийца добыл где-то пулемет, выкосил полрайона, целенаправленно охотясь за гражданами, а потом начал вещать что он все это нечаянно, дескать.
> ps. о качестве кода биосов знаю слегка не понаслышке.
А я видел код парочки из таковых. Что еще интереснее - там ченжлог был. Вот это заставляет волосы шевелиться. Даже на ж..е! Потому что почитав его я не понял: а как это вообще работало то? :)
>> Бэкдор делается с умыслом. а это про.. ...
> Не представляю себе как можно накодить инженерный пароль без умысла. Нечаянно такое
> не кодится.кодится дебаговая секция для своих нужд - потом кто-то забывает убрать -DDEBUG из makefile и на выходе такое получается.. пример с паролями от станций диагностики мерсов - я приводил.. тож видимо бэкдоры.