The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

В Oracle Linux выявлены серьёзные проблемы в реализации UEFI Secure Boot

16.03.2015 09:59

Компания Oracle объявила о реализации в выпуске дистрибутива Oracle Linux 7.1 возможности верификации процесса загрузки на системах с UEFI Secure Boot. Мэтью Гаррет (Matthew Garrett), один из разработчиков ядра Linux, активно занимающийся обеспечением загрузки Linux на системах с UEFI, выступил с критикой поддержки UEFI Secure Boot в Oracle Linux и указал на серьёзные проблемы с безопасностью, позволяющие выполнить произвольный код, не заверенный цифровой подписью.

Механизм UEFI Secure Boot позволяет гарантировать использование на этапе загрузки системы только оригинальных компонентов, заверенных цифровой подписью. В RHEL и Oracle Linux, при использовании UEFI Secure Boot, обеспечивается проверка загрузчика, ядра, загружаемых ядром драйверов и модулей ядра. Для обеспечения защиты от выполнения непроверенных компонентов, при загрузке с верификацией в ядре необходимо отключить ряд возможностей, таких как вызов kexec и интерфейсы, позволяющие вносить изменения в память ядра из пространства пользователя. В частности, kexec предоставляет возможность загрузки нового ядра из уже запущенного ядра Linux, что может быть использовано для обхода UEFI Secure Boot путём замены проверенного ядра на другое ядро, не снабжённое цифровой подписью.

Как известно, в Oracle Linux кроме клона ядра из состава RHEL также поставляется собственный вариант ядра Unbreakable Enterprise Kernel, поддерживаемый силами 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 ключа.

  1. Главная ссылка к новости (http://www.theregister.co.uk/2...)
  2. OpenNews: Доступен дистрибутив Oracle Linux 7.1
  3. OpenNews: Для Linux представлена система верификации исполняемых файлов по цифровым подписям
  4. OpenNews: Для ядра Linux представлены патчи, отключающие поддержку спящего режима при загрузке с UEFI Secure Boot
  5. OpenNews: Проблемы на пути реализации режима безопасной загрузки UEFI в Linux
  6. OpenNews: Red Hat и Canonical опубликовали рекомендации по реализации режима безопасной загрузки в UEFI
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/41852-oracle
Ключевые слова: oracle, uefi
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (117) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 10:17, 16/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +25 +/
    На третий день Зоркий Глаз заметил что у сарая нет стены...
     
     
  • 2.31, Аноним (-), 13:56, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    ...только три стены
     

  • 1.2, Аноним (-), 10:23, 16/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +14 +/
    > Интересно также то, что ключ для создания цифровой подписи для Oracle Linux назван "oracle301", при том, что число 301 выбрано так как ключ в RHEL тоже оканчивается на 301, но без учёта того, что 301 не имеет принципиального значения и является лишь порядковым номером сгенерированного в Red Hat ключа.

    Вывод отсюда какой? Правильно, Oracle копипастит из RHEL, даже не понимая как это работает. Еще и суппорт какой-то оказывать пытаются.

     
     
  • 2.39, koblin (ok), 16:42, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +6 +/
    возможно у них тупо есть подписка на суппорт от RH и они форвардят обращения туда от своего имени)
     
  • 2.109, Anonim (??), 20:42, 18/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вывод отсюда какой? Правильно, Oracle копипастит из RHEL, даже не понимая как это работает. Еще и суппорт какой-то оказывать пытаются.

    Подождём и посмотрим как поступят ВНИИНС со своим МСВС?

     
     
  • 3.117, Умный (?), 18:00, 19/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Идеально!
     
  • 3.118, Аноим (?), 14:46, 20/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Лет через 15 узнаем, раньше врядли
     

  • 1.3, Аноним (-), 10:25, 16/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Предлагаю переименовать ключ oracle301 в oracle42
     
  • 1.4, Нанобот (ok), 10:27, 16/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    что-то мне кажется, что имеется намного больше способов обхода UEFI Secure Boot, просто вопрос слабо изучен
     
     
  • 2.19, Аноним (-), 12:45, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ну грубо говоря если ты можешь переписать uefi то и Secure Boot обойти не проблема.
     

  • 1.5, Аноним (-), 10:31, 16/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +24 +/
    >UEFI Secure Boot

    Оно не для безопасности создано. А для того чтобы запретить пользователям устанавливать ОС отличные от микрософтовских.

     
     
  • 2.8, ZiNk (ok), 11:19, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • –6 +/
    > Оно не для безопасности создано. А для того чтобы запретить пользователям устанавливать ОС отличные от микрософтовских.

    Однако если контроль над ключами в руках у пользователя - то это хорошая, годная технология по hardening-у ОС.

     
     
  • 3.11, Аноним (-), 11:39, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Единственная проблема Boot Guard от интеля подразумевает однократное вшивание х... большой текст свёрнут, показать
     
     
  • 4.15, Crazy Alex (ok), 12:21, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так Boot Guard - это другая технология, при чём здесь он?
     
     
  • 5.28, Канада_тян (?), 13:41, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну так Boot Guard - это другая технология, при чём здесь он?

    Вот именно.

     
  • 5.69, Аноним (-), 02:25, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну так Boot Guard - это другая технология, при чём здесь он?

    А при том что
    1) Без него секурбут не полный. Ведь недруг может потенциально перелить фирмваре на пропатченое.
    2) Поэтому появляется BootGuard. И когда вопрос становится ребром: на кого залочить железку, при том что лок прописывается в фюзы 1 раз и навсегда - ВНЕЗАПНО оказывается что мастерключ не ваш и вам его давать никто не собирается. Девайс лочится на вендыря и рулится вендырем. А вы там можете верить ему на честное слово что его мутный многометровый блоб делает то что показывает в настройках сетапа, а не что-нибудь другое. А можете и не верить, все-равно вы никуда не денетесь с подводной лодки.

     
     
  • 6.78, Crazy Alex (ok), 03:47, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Угу. Только в отличие от UEFI, худо-бедно ставшего стандартом, Secure Boot - это факультативная дурь интела. Причём на десктопе и сервере, где заведомо съёмный проц (а то и самосбор), эта "фича" вообще вряд ли когда-либо появится. На приличныйх ноутах тоже процессор меняется - так что в худшем случае обойдётся в стоимость нового камня. В общем, даже если ограничиваться интелом вариантов предостаточно. А для юзерских повседневных нужд - проблем никаких. Да и у гиков я как-то не вижу повальной смены биосов на открытые. Я бы понял стоны, если хотя бы одна десятая (да хоть сотая!) процента биосов перешивалась на что-то. Но этого же и близко нет.
     
     
  • 7.87, Аноним (-), 13:51, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А UEFI - такой же стандарт как ACPI. В смысле, реализуется какими-то левыми блобами без сорцов, с кучей багов, по принципу "винда вроде как-то работает, ну и ладно". Нафиг-нафиг таких стандартизаторов, они себя дискредитировали по всем фронтам.
     
  • 7.88, Аноним (-), 13:52, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > На приличныйх ноутах тоже процессор меняется - так что
    > в худшем случае обойдётся в стоимость нового камня.

    Насколько я понимаю, шьется в чипсет. Удачи тебе в перепайке BGA...

     
  • 4.53, Аноним (-), 19:57, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    ну на счёт "опенсорсное фирмваре где все заведомо честно" ты конечно чуток переборщил..


     
     
  • 5.70, Аноним (-), 02:26, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > ну на счёт "опенсорсное фирмваре где все заведомо честно" ты конечно чуток переборщил..

    Пока-что авторов coreboot, u-boot и прочая как-то не ловили на вещах типа AWARD_SW и мастер-пароля на управление через BMC как у супермикры.

     
     
  • 6.80, Аноним (-), 08:19, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Пока-что авторов coreboot, u-boot и прочая как-то не ловили на вещах типа
    > AWARD_SW и мастер-пароля на управление через BMC как у супермикры.

    "В пьянстве замечен не был, но по утрам жадно пил холодную воду"

    такого беспредела, как ты написал, конечно быть не должно.
    Но это не отменяет возможности различных подстав ввиду "анонимизма" авторов и IOCCC
    и поди потом докажи что это "кнопкой ошибся", а не целенаправленно пилил под поставленную кем-то задачу.

     
     
  • 7.82, ZiNk (ok), 10:07, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> Пока-что авторов coreboot, u-boot и прочая как-то не ловили на вещах типа
    >> AWARD_SW и мастер-пароля на управление через BMC как у супермикры.
    > "В пьянстве замечен не был, но по утрам жадно пил холодную воду"
    > такого беспредела, как ты написал, конечно быть не должно.
    > Но это не отменяет возможности различных подстав ввиду "анонимизма" авторов и IOCCC
    > и поди потом докажи что это "кнопкой ошибся", а не целенаправленно пилил
    > под поставленную кем-то задачу.

    Но это уже запилить и оставить ненайденным намного сложнее, чем в открытую запихать скрытый вход по "правильному стуку"

     
     
  • 8.86, Аноним (-), 13:47, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    судя по результатам где-то новость на опеннете проскакивала, не могу найти ва-... текст свёрнут, показать
     
     
  • 9.90, Аноним (-), 13:57, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Это вы не про то как в линухе при попытке коммита бэкдора он был запален ... текст свёрнут, показать
     
     
  • 10.94, Аноним (-), 14:18, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    не, не оно ... текст свёрнут, показать
     
  • 7.89, Аноним (-), 13:56, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Более того - проприерасы себя уже дискредитировали и на честное слово им верить ... большой текст свёрнут, показать
     
     
  • 8.103, Аноним (-), 09:33, 18/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    ну, а что будет анонимному патчеру аась и кстати, что было автору хартблида а... текст свёрнут, показать
     
     
  • 9.110, Аноним (-), 20:48, 18/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Потеря доверия и как минимум нужда убить заново кучу времени годы на выращи... большой текст свёрнут, показать
     
     
  • 10.115, Аноним (-), 12:10, 19/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    ты вообще читал о чём я говорил а я думаю он мог на ней уже озолотиться - и ко... большой текст свёрнут, показать
     
  • 4.122, sur pri (?), 03:29, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Поэтому предлагается на честное слово поверить проприерасам с
    > мутным бэкдореным уефанством что их мутный блоб делает по части ключей
    > именно то что вы попросили, а не что-нибудь еще. А попытки
    > взять управление на себя путем прошивания своего BIOS по типу опенсорсного
    > coreboot - безнадежно зарублены.

    А что ещё их мутный блоб может делать с ключами?
    Он должен проверять подпись загружаемой системы. Можете проверить, что проверяет, и неправильно подписанное не загружается.
    Может статься, что там есть возможность обойти ваш ключ. Но если её туда вставил производитель... То он в общем-то скорее и так не имел бы сложностей сделать замену БИОС... (если имел бы доступ)...
    Хотя технология и по-моему слишком явно оставляет желать лучшего так сказать.

     
  • 3.17, jOKer (ok), 12:40, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Хы!  Да кто же им, зверькам то есть, позволит что-то там контролировать и тем более отключать? Это все их влажные мечты и не более того. Ничего они не контролируют и полезность этой технологии для них - со знаком минус.

    Ну позволят им какое-то время побаловаться со своими ключами... пока производители матерей не подсели на UEFI полностью и окончательно... а потом жестко заблокируют. Придумают оправдание или оговорку какую и залочат смену ключей. Раз есть пушка, - то грех не пальнуть из нее, верно? Тем более что пальба ведется по карману потребителя. Да еще и с большущим профитом для стрелков.

     
     
  • 4.18, ZiNk (ok), 12:44, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Стрелки рискуют лишиться пачек бабла Сделает интель - АМБ начнёт гарцевать свои... большой текст свёрнут, показать
     
     
  • 5.22, Аноним (-), 12:54, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • –3 +/
    А если они договорятся так не делать, а? Или "АМБ" тупо подсчитает, что если интел залочит, то и им выгоднее будет все-таки залочить, чем разлочивать?
     
     
  • 6.54, Аноним (-), 20:01, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > А если они договорятся так не делать, а? Или "АМБ" тупо подсчитает,
    > что если интел залочит, то и им выгоднее будет все-таки залочить,
    > чем разлочивать?

    Легко. Это бизнес и первое место это интересы бизнеса. Клиент всего лишь на втором месте. Ну так, по чесноку.


     
  • 2.29, Канада_тян (?), 13:43, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >>UEFI Secure Boot
    > Оно не для безопасности создано. А для того чтобы запретить пользователям устанавливать
    > ОС отличные от микрософтовских.

    UEFI позволяет использовать свою собственную связку ключей, чтобы запретить установку ОС, отличных от Linux.

     
     
  • 3.32, ZiNk (ok), 14:24, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>>UEFI Secure Boot
    >> Оно не для безопасности создано. А для того чтобы запретить пользователям устанавливать
    >> ОС отличные от микрософтовских.
    > UEFI позволяет использовать свою собственную связку ключей, чтобы запретить установку
    > ОС, отличных от Linux.

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

     
     
  • 4.33, Канада_тян (?), 14:49, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Да, вы правы, просто UEFI не живёт без Secure Boot, как мне казалось.
     
     
  • 5.35, ZiNk (ok), 15:20, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Да, вы правы, просто UEFI не живёт без Secure Boot, как мне
    > казалось.

    Живёт и ещё как. Это наоборот - SecureBoot живёт только на UEFI. Производителям секьюр бут требуется только для сертификации восьмой винды, что допустим, для серверных стоек - как собаке пятая нога и второй хвост, там производители могут вообще забить на реализацию этой фигни. На лэптопах и рабочих станциях меня куда больше стремают дугие технологии интеля с TPM, anti-theft с 3Г модемчиком, локом всех функций и т.д. А пока что в спецификацию секьюр бута входит требование иметь возможность это отключить. Не помню есть ли требование к укправлению ключами но на всех виденых реализациях это было (выпилиываешь ключи МС, вставляешь свои, живёшь долго и счастливо, пока не узнаёшь что у тебя на уровне ЦПУ бэкдор :) ).

     
     
  • 6.91, Аноним (-), 13:58, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > и рабочих станциях меня куда больше стремают дугие технологии интеля с
    > TPM, anti-theft с 3Г модемчиком, локом всех функций и т.д.

    Ну так интель дает понять что это они рулят железкой, а не ты. Зато очень удобно. США ввели санкции. Количество theft'ов увеличилось вдвое...

     
  • 3.71, Аноним (-), 02:31, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > UEFI позволяет использовать свою собственную связку ключей, чтобы запретить установку
    > ОС, отличных от Linux.

    Точнее, для мутного проприетарного блоба фирмвари номинально декларируется что оно вот так. А насколько это по факту соответствует действительности и какие там AWARD_SW для себя оставил производитель - извольте дизассемблить ...цатимеговое фирмваре, типа.

     

  • 1.6, Омский линуксоид (ok), 10:46, 16/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Маркетинг решает. Все забудут зачем UEFI. И что она плохо работает, тоже забудут.
     
     
  • 2.27, Аноним (-), 13:39, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Не путайте UEFI и Secure Boot. Это НЕ одно и тоже.
     
     
  • 3.48, Аноним (-), 19:14, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Вот и я о том же не путайте. UEFI работает плохо.
    А с secure boot сложнее получить загрузочный вирус.
     
     
  • 4.57, Гость3 (?), 20:03, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот и я о том же не путайте. UEFI работает плохо.
    > А с secure boot сложнее получить загрузочный вирус.

    всё это смахивает на эволюционную борьбу за пользователя между бэкдорами производителей и загрузочными вирусами.
    Кто победит интересно?

     
     
  • 5.111, Аноним (-), 20:51, 18/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Кто победит интересно?

    Победила "Дружба" - пробурчал дровосек. В смысле, вся эта живность будет иметь юзерье, а воевать друг с другом им в общем то и не особо надо.

     
  • 4.72, Аноним (-), 02:32, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот и я о том же не путайте. UEFI работает плохо.
    > А с secure boot сложнее получить загрузочный вирус.

    Если супермикро внаглую шьет бэкдор прямо в фирмварь BMC - удачи вам в вашей защите от вирусов :)

     

  • 1.7, Аноним (-), 11:05, 16/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    железо с uefi нужно было байкотировать, а теперь приходится терпеть и тратить время впустую
     
     
  • 2.9, KT315 (ok), 11:28, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Правильное железо дает возможность эту гнойную заразу выключить. А не правильное - у есть 14 дней на возврат товара, по причине - нет возможности использовать по прямому назначению из-за "Vendor Lock".
     
     
  • 3.12, Аноним (-), 11:42, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Правильное железо дает возможность эту гнойную заразу выключить.

    Простите, но в поздних интеловских процах и чипсетах есть countermeasure который не даст сменить черти-какой bios делающий черт знает что на опенсорсную фирмварь которой реально можно доверять по части того что boot sequence - именно такой как ожидается, а не что-нибудь еще, с сюрпризами и бэкдорами. Никаких оснований доверять производителям AWARD_SW - нет. А заменить западло от западлостроителей теперь не даст проц и чипсет.

     
     
  • 4.16, Crazy Alex (ok), 12:23, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Как-то я слабо представляю вшитый ключ в процессорах, купленных отдельно в магазине, а не впаянных в мать, так что при желании эта проблема решается тривиально.
     
     
  • 5.24, jOKer (ok), 12:57, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Как-то я слабо представляю вшитый ключ в процессорах

    А зря. Потому что именно это интеловцы и тащщють на рынок сейчас. Вот полюбуйтесь http://hi-news.ru/hardware/mobilnye-processory-intel-merrifield-budut-blokiro
    Речь пока идет правда только о мобильных процессорах, но ведь лиха беда начало, верно?

     
     
  • 6.34, Crazy Alex (ok), 14:58, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так я ж написал дальше - "Купленных отдельно в магазине". Какой именно ключ туда шить, если не известно, в какую мать его сунут? А то, что впаяно в мать - ну, беда-печаль тем, кто такое купил. Есть альтернативы - от AMD до ARM.
     
  • 5.73, Аноним (-), 02:33, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Как-то я слабо представляю вшитый ключ в процессорах, купленных отдельно в магазине,

    Оно IIRC вшивается в чипсет. А так - купил ты ноут. А он залочен не на тебя и твой ключ, а на ключ вендора. И ты делаешь deep throat вендору и его биосу.

     
     
  • 6.77, Crazy Alex (ok), 03:37, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Насколько я читал - вшивается в CPU. И да, в приличных ноутбуках (хотя ноутбук, конечно, всегда урод) так и так процессор меняется. Плюс есть AMD и ARM. Учитывая, что смена биоса и сейчас, мягко говоря, не слишком распространена - по-моему шум по этому поводу слишком велик.
     
     
  • 7.92, Аноним (-), 14:02, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Насколько я читал - вшивается в CPU.

    А вроде coreboot'овцы говорили что фьюзы в чипсете.

    > И да, в приличных ноутбуках (хотя ноутбук, конечно, всегда урод) так и
    > так процессор меняется.

    Да я не сомневаюсь что интел продаст новые чипсет, проц и даже весь ноут. За отдельное баблo. А то что купил по дефолту - залоченая троянская коняшка, работающая на левых хренов за бугром.

    > говоря, не слишком распространена - по-моему шум по этому поводу слишком велик.

    Шум по поводу того что PC под оправданиями защиты от плохих парней заканчивает существование как открытая промышленная платформа, превращаясь в walled garden имени микрософта. А ты думал что эти бут-гады и секурбуты для защиты тебя от чего либо? То как это сделано - прозрачно намекает для чего этого.

     
  • 2.20, ZiNk (ok), 12:47, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > железо с uefi нужно было байкотировать, а теперь приходится терпеть и тратить
    > время впустую

    Ещё один путающий UEFI c SecureBoot-ом? Прицепить замок не дающий сменить прошивку можно и на биос, чем уже давно и успешно занимаются Леново и Деллы.

     
     
  • 3.66, AlexAT (ok), 23:14, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Лично я давно путаю UEFI с говном. Достаточно оправданно.
     
  • 2.26, Аноним (-), 13:25, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    "байкотировать" - это на байках, что-ли? Откуда у вас байки, нестирано-сальножелёзные?
    А кто должен был бойкотировать? Оба твоих нездоровых друга? Ну, они и бойкотируют и даже бубунту на улице как-то раздавали. Ну и чо?

     
     
  • 3.30, Zomby (?), 13:43, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Байкотировать! А также Килобайкотировать, Мегабайкотировать и Гигабайкотировать!
     
     
  • 4.56, Аноним (-), 20:03, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Байкотировать! А также Килобайкотировать, Мегабайкотировать и Гигабайкотировать!

    Ну и сидите с лучиной, кому хуже-то?!

     

  • 1.10, Анонимус сапиенс (?), 11:29, 16/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    http://www.youtube.com/watch?v=ths65a9LH6Y
     
  • 1.14, Аноним (-), 12:08, 16/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А может ну его нафиг этот Secure Boot?
    Уже может пора понять, что на уровне доступа к железу надо реализовать безопасность?
     
     
  • 2.21, Аноним (-), 12:51, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А может ну его нафиг этот Secure Boot?
    > Уже может пора понять, что на уровне доступа к железу надо реализовать
    > безопасность?

    Естественно, помню крепили провода от мышек и клав + замок на корпус. Единственная острая проблема была с шариковыми мышками, воровали шарики по страшному.

     
  • 2.36, ZiNk (ok), 15:24, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > А может ну его нафиг этот Secure Boot?
    > Уже может пора понять, что на уровне доступа к железу надо реализовать
    > безопасность?

    SecureBoot реализует защиту от замены ядра ОС и подмены её на липовый загрузчик. Естественно делает это коряво и с дырами. :)

     
     
  • 3.49, Аноним (-), 19:15, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    перечисляйте дыры.
     
     
  • 4.74, Аноним (-), 02:37, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > перечисляйте дыры.

    Проприетарь же. Вон у супермикры нашелся инженерный логин в фирмвари BMC. Всего ничего. А AWARD и AMI сто лет как делали мастер-пароли на BIOS, по типу AWARD_SW (через который я однажды лично вломился на запароленый биос). Доверять этим блобмейкерам на слово? Нет пути.

     
     
  • 5.100, Аноним (-), 22:44, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> перечисляйте дыры.
    > Проприетарь же. Вон у супермикры нашелся инженерный логин в фирмвари BMC. Всего
    > ничего. А AWARD и AMI сто лет как делали мастер-пароли на
    > BIOS, по типу AWARD_SW (через который я однажды лично вломился на
    > запароленый биос). Доверять этим блобмейкерам на слово? Нет пути.

    То есть по сути ответить нечего? раз идет переход на какие-то странные утверждения.
    Еще раз - у вас просили список багов.. где этот список?

    а award_sw - это некоторые производители материнок - не выключили дефолт при сборке под себя.
    Правда в этом виноват производитель биоса? или может производитель материнок?

     
     
  • 6.112, Аноним (-), 20:57, 18/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Вы просили перечислить Я привел два вопиющих бэкдора, реально существующих Чем... большой текст свёрнут, показать
     

  • 1.38, Аноним (-), 16:33, 16/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кому надо такое - запретит запуск kdump через нужный kernel command line. И поставит запрет на изменение.
     
  • 1.40, ffirefox (?), 17:03, 16/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Что-то отдает какой-то желтизной новость.
    В Linux всегда оставляли все ручки, для того чтобы настроить под конкретный случай. В чем проблема то? Кто-то не знает, где эта _возможность_ отключается? Тогда о какой безопасности может идти речь с таким админом? Будем как в винде ориентироваться только на домохозяек? Так они возьмут другой дистрибутив - более домохозяекфрендли (тот же минт, например). Но на сервере важнее иметь возможность сменить ядро без перезагрузки. Ораклу однозначно плюс, а UEFI пусть идет лесом, пока закрыт
     
     
  • 2.41, ZiNk (ok), 17:24, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Вопрос не в домохозяйках, а в том, что Оракл тырит код не врубаясь в то что копи... большой текст свёрнут, показать
     
     
  • 3.42, Аноним (-), 17:52, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Это у оракула бзик на "совместимости". Они даже настоящую версию ядра долго говорили старую, чтобы программы какие-то не сломались.
     

  • 1.43, дон Педро (?), 18:21, 16/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как неожиданно... От оракла я такого не ожидал.
     
  • 1.44, Аноним (-), 18:42, 16/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Новость-то ни о чем :) Еще "спецы" пытаются над Ораклом смеяться, типа копипастят рэдхатовский код, сами ничего не понимают. Поверьте, в такой компании по определению не может быть сотрудников, чей уровень знаний ниже ваших.
     
     
  • 2.45, ZiNk (ok), 18:50, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Новость-то ни о чем :) Еще "спецы" пытаются над Ораклом смеяться, типа
    > копипастят рэдхатовский код, сами ничего не понимают. Поверьте, в такой компании
    > по определению не может быть сотрудников, чей уровень знаний ниже ваших.

    Talk is cheap, show me the code.

    Какой бы не был уровень этих сотрудников, результат их работы налицо и он говорит об их уровне куда больше чем ваше "поверьте".

     
     
  • 3.46, Аноним (-), 19:09, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    да? новость не о чем. kdump надо еще специально включить.

    Новость однозначно попытка шапки дискредитировать Oracle.

     
  • 2.50, Аноним (-), 19:17, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    уборщицы с высшим образованием...
     
     
  • 3.62, Анонимууус (?), 21:29, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А у тебя специализация "уборщик"? :) Возможно, что и там тебе фору дадут в некоторых моментах:) Сравнивай себя с людьми, которые занимаются тем же делом, что и ты, а не с уборщиками или Ларри Эллисоном :)
     
  • 2.64, Аноним (-), 22:21, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Да, как комменты с опнета почитаешь - такое впечатление, что здесь самая кодерская косточка собирается. А на деле кунсткамера, маги пхп и пистона, гении верной расстановки переменных при сборке.
     
  • 2.97, arisu (ok), 20:07, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Поверьте, в такой компании
    > по определению не может быть сотрудников, чей уровень знаний ниже ваших.

    хорошо лизнул.

     

  • 1.47, Аноним (-), 19:11, 16/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Компания Oracle объявила (https://blogs.oracle.com/wim/entry/secure_boot_support_with_oracle)
    > о реализации в выпуске дистрибутива Oracle Linux 7.1 возможности верификации процесса
    > загрузки на системах с UEFI Secure Boot. Мэтью Гаррет (Matthew Garrett),
    > один из разработчиков ядра Linux

    Заменяем слово "разработчик ядра" - на "сотрудник redhat" и все становится на свои места. Просто черный пиар - в попытке оттянуть клиентов. Жаль что Opennet - ориентируется на сильно аганжированные новости.

     
     
  • 2.51, Аноним (-), 19:19, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    То есть в Oracle Linux нет включенного kexec? А если есть это не позволяет обойти цепочку доверия? Вас так надо понимать?
     
     
  • 3.99, Аноним (-), 22:42, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > То есть в Oracle Linux нет включенного kexec? А если есть это
    > не позволяет обойти цепочку доверия? Вас так надо понимать?

    Надо понимать - что если в руководстве написано - что если вам надо макс безопастность - вам надо зайти и отключить kexec - то это фича а не бага.
    А вот то что у RedHat перестает работать kexec автоматом - это уже бага. Случись что и получить отладочную инфу никак.

    Или это сильно сложно для вас?

     
     
  • 4.105, ZiNk (ok), 10:29, 18/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> То есть в Oracle Linux нет включенного kexec? А если есть это
    >> не позволяет обойти цепочку доверия? Вас так надо понимать?
    > Надо понимать - что если в руководстве написано - что если вам
    > надо макс безопастность - вам надо зайти и отключить kexec -
    > то это фича а не бага.
    > А вот то что у RedHat перестает работать kexec автоматом - это
    > уже бага. Случись что и получить отладочную инфу никак.
    > Или это сильно сложно для вас?

    Надо понимать - что если в руководстве написано - что если вам
    надо макс безопастность - вам надо зайти и отключить telnet с
    рут доступом без пароля, то это фича, а не бага.

    А вот то что у RedHat перестает работать telnet автоматом - это
    уже бага. Случись что и зайти по сети поправить никак.

    Так лучше? Если человеку не нужен SecureBoot - он его не включает. Если он хочет чтобы в загрузке каждый элемент проверял следующий загружаемый - то он его включает и ожидает что ОС будет действовать соответственно. Если Оракл хотели сделать поддержку загрузки на системах с SecureBoot оставив возможность грузить что угодно (предположим, что админ-наркоман купил сервер-удобрение, где криворукие китайцы сделали неотключаемый секьюр бут), то тогда ставится заглушка, которая грузит любое ядро и не задаёт вопросов. А тут мы имеем вроде как и проверку подписей ядра и прочую фигню, но рядом лежит неотключенный способ это обойти.

     
  • 3.125, sur pri (?), 04:19, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > То есть в Oracle Linux нет включенного kexec? А если есть это
    > не позволяет обойти цепочку доверия? Вас так надо понимать?

    Нет. Не позволяет это обойти. Цепочку....

     
  • 2.52, Аноним (-), 19:31, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Заменяем слово "разработчик ядра" - на "сотрудник redhat" и все становится на
    > свои места.

    Matthew Garrett уже лет пять как не сотрудник Red Hat.

     
     
  • 3.59, Аноним (-), 20:06, 16/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> Заменяем слово "разработчик ядра" - на "сотрудник redhat" и все становится на
    >> свои места.
    > Matthew Garrett уже лет пять как не сотрудник Red Hat.

    С кем ты разговариваешь? Эти тормоза за пределы своих уютненьких не выходят никогда, они даже на портале Оракловом по жизни не были - им рабинович напел - а пойти туда глянуть религия не позволяет.

     
  • 3.98, Аноним (-), 22:40, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    а гугл говорит что еще год назад был им.. что-то мне вам не верится.
     
     
  • 4.104, Andrey Mitrofanov (?), 09:55, 18/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > а гугл говорит что еще год назад был им

    Садись, двойка. Предыдущий оратор хоть гугли-фу не размахивал.

    Last day at Red Hat
    Nov. 9th, 2012
    http://mjg59.dreamwidth.org/19695.html

     

  • 1.67, vitalif (ok), 23:31, 16/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Оракл всё правильно делает - секьюрбут это вредная технология, и поддержка её если и должна быть, то чисто формальная, чтобы обеспечить загрузку при включённом секурбуте.

    А по мне - его вообще не нужно реализовывать, нужно отключать везде и всё.

     
     
  • 2.68, ZiNk (ok), 01:23, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Оракл всё правильно делает - секьюрбут это вредная технология, и поддержка её
    > если и должна быть, то чисто формальная, чтобы обеспечить загрузку при
    > включённом секурбуте.
    > А по мне - его вообще не нужно реализовывать, нужно отключать везде
    > и всё.

    Ну не смешите мои тапочки. Оракл - бунтари против системы, ага, три раза. В продакшне админам как раз очень удобно было бы знать что ядра на системе запустятся только те, которые подписаны их ключами, тут же элементарный косяк. Для галочки реализовали, кстати, канониклы - efi-shim, заглушка которая подписана ключом и запускает что угодно.

     
     
  • 3.75, Аноним (-), 02:38, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > заглушка которая подписана ключом и запускает что угодно.

    Только оно следует неким правилам. И [I]автоматически и без спросу[/I] черти-что запускать не станет.

     
     
  • 4.83, ZiNk (ok), 10:20, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> заглушка которая подписана ключом и запускает что угодно.
    > Только оно следует неким правилам. И [I]автоматически и без спросу[/I] черти-что запускать
    > не станет.

    Оно загрузит груб, который загрузит любой кернел, который ему скажут, то есть проверки подписей не происходит и тут именно "обходится" secure boot, вместо использования его. В Федоре, например, при включении секьюр бута првоерка кернела происходит и кернел проверяет подписи модулей при загрузке, что выкидывает модуль невидии (нет в официальном репо, никто его подписывать не будет) - это реализация secureboot как оно задумывалось.

    Кому-то может быть такое надо, но большинству проще выключить и забыть как страшный сон.

     
     
  • 5.113, Аноним (-), 21:07, 18/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Вроде как если грузится секурный загрузчик то и тот должен проверять что грузит ... большой текст свёрнут, показать
     

  • 1.76, Andrey (??), 02:53, 17/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ваще понять не могу о чем идет речь.

    Не пойму - есть железки где нельзя отрубить UEFI??

    Даже в долбанном планшете от АЙСЕРА W700 на 8ке... в "BIOS" можно отрубить всё.
    Линукс спокойно ставиться. (но к сожалению пришлось перепрыгнуть обратно на винду, без вменяемой виртуальной клавы во всех местах - как то стремно работается.)

     
     
  • 2.84, ZiNk (ok), 10:24, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Ваще понять не могу о чем идет речь.
    > Не пойму - есть железки где нельзя отрубить UEFI??
    > Даже в долбанном планшете от АЙСЕРА W700 на 8ке... в "BIOS" можно
    > отрубить всё.
    > Линукс спокойно ставиться. (но к сожалению пришлось перепрыгнуть обратно на винду, без
    > вменяемой виртуальной клавы во всех местах - как то стремно работается.)

    Если отрубить UEFI, то компьютер не загрузится. Можно отключить Secure Boot или перевести UEFI в режим совместимости (эмуляции BIOS).

     
     
  • 3.95, Xasd (ok), 15:40, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Если отрубить UEFI, то компьютер не загрузится

    всё верно. поэтому в железках и НЕ делают такой переключатель "отключить UEFI?" :)

    а было бы прикольно -- выставил этот переключатель в OFF -- и неси комп на ремонт (в сервисный центр для перепрошивки, промышленным способом)....

    ....в этом случае умников стало бы в разы поменьше :-), которые думают будто бы SecureBoot это синоним UEFI (или которые думают будто бы имитация BIOS -- является якобы на самом деле не имитацией) :)

     
     
  • 4.107, Andrey (??), 16:25, 18/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Да, соглашусь, ступил, не так описал то о чем подумал :)
     
  • 4.120, Аноним (-), 14:30, 22/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо, посмеялся. :)
     

  • 1.79, Аноним (-), 07:30, 17/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Тут выше писали про то, что очень мала доля тех, кто перешивает BIOS|UEFI на что-то своё, вроде coreboot.

    Товарищи, не надо путать причину и следствие: таких перешивок мало именно потому, что это очень трудно сделать, а трудности созданы искусственно со стороны производителей железа.

    Не так-то просто, знаете ли, делать замену прошивке для железа, на которое нет сколь-нибудь вменяемых спеков, и которое, к тому же, этой самой перешивке активно сопротивляется.

     
     
  • 2.81, Нанобот (ok), 10:07, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >трудности созданы искусственно со стороны производителей железа

    да-да, заговор злобных корпораций против белых и пушистых хомячков, мы в курсе

     
     
  • 3.85, Аноним (-), 11:00, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Вы так говорите, как будто эти проблемы _случайно_ возникли одновременно со всеми производителями железа.

    И нет, речь не идёт о чём-то вроде мирового заговора. Этим людям нужно примерно одно и то же, поэтому они совершают примерно одинаковые действия. Им не нужно специально договариваться для этого.

    Никакой излишней паранойи, всего лишь прагматичная оценка, т.е. "смотри, кому выгодно".

     
     
  • 4.96, Xasd (ok), 15:46, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы так говорите, как будто эти проблемы _случайно_ возникли одновременно со всеми производителями железа.

    эти проблемы созданы были не случайно.. но и не специально против corebootчиков.

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

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

     
     
  • 5.101, Аноним (-), 05:57, 18/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Xasd, именно это я и имел в виду, когда уточнил, что "речь не идёт о чём-то вроде мирового заговора" и т.д.
     
  • 3.93, Аноним (-), 14:04, 17/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > да-да, заговор злобных корпораций против белых и пушистых хомячков, мы в курсе

    Не, ну что ты. AWARD_SW случайно сам накодился в биосе. И бэкдор у супермикры в BMC - сам. И западлоидизированый биос не дающий сменить сетевки или модули памяти на нечто отличное от вендырского. А корпорасы что, они белые и пушистые, к западлу отношения не имеют.


     
     
  • 4.102, Аноним (-), 08:30, 18/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    award_sw мог быть в дебаг секции. Но факт в том что многие производители забыли выключить дебаг :-)
    так что не надо искать сложности где простой прое.. б у индусов.
     
     
  • 5.106, Аноним (-), 15:30, 18/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Сноуден описал как такие "простые баги" появляются. Да, случайно все - дебаг забыли убрать, забыли послать клиента нафиг, когда он запрашивает в heartbeat-е слишком много данных и так далее...
     
  • 5.108, arisu (ok), 17:10, 18/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > award_sw мог быть в дебаг секции. Но факт в том что многие
    > производители забыли выключить дебаг :-)

    а мне какая разница?

     
  • 5.114, Аноним (-), 21:09, 18/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > award_sw мог быть в дебаг секции.

    А ты мог случайно упасть на кулак добрейшего гражданина. Случайно. И так пять раз.

    > производители забыли выключить дебаг :-)

    А мне какая разница? Бэкдор и есть бэкдор. А оправдания и виляния пoпой меня не сильно интересуют.

    > так что не надо искать сложности где простой прое.. б у индусов.

    Интересные такие про..бы. Надеюсь что в поезде, самолете или автомобиле в котором они будут ездить в сервисной фирмвари тоже окажется парочка забытых дебаг секций и прочих радостей.

     
     
  • 6.116, Аноним (-), 14:44, 19/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > А мне какая разница? Бэкдор и есть бэкдор. А оправдания и виляния пoпой меня не сильно интересуют.

    Бэкдор делается с умыслом. а это про.. ...

    > Интересные такие про..бы. Надеюсь что в поезде, самолете или автомобиле в котором они будут ездить в сервисной фирмвари тоже окажется парочка забытых дебаг секций и прочих радостей.

    Ты даже не знаешь насколько ты прав. В софте для станций диагностики Мерседес - компилятор забыл мертвый код с паролями для перепрошивки флэшей которые имеют разные пароли на чтение и запись данных.

    это тоже сознательный бэкдор ?

    ps. о качестве кода биосов знаю слегка не понаслышке.

     
     
  • 7.119, Vkni (ok), 18:25, 20/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Бэкдор делается с умыслом. а это про.. ...

    Был там умысел или нет, узнать невозможно. Поэтому чётко утверждать, что продолб странно.

     
     
  • 8.121, Аноним (-), 08:56, 23/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    видя код биосов и где находится данная опция - можно ... текст свёрнут, показать
     
     
  • 9.124, Аноним (-), 03:55, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Код BIOSов конечно лютейшее г-но, ОДНАКО без осмысленного желания того или иного... текст свёрнут, показать
     
     
  • 10.126, Аноним (-), 17:05, 26/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    девелопер кода - который использовался при тестировании паролей... текст свёрнут, показать
     
  • 7.123, Аноним (-), 03:53, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Не представляю себе как можно накодить инженерный пароль без умысла Нечаянно та... большой текст свёрнут, показать
     
     
  • 8.127, Аноним (-), 17:13, 26/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    кодится дебаговая секция для своих нужд - потом кто-то забывает убрать -DDEBUG и... текст свёрнут, показать
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру