The OpenNET Project / Index page

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



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

Оглавление

В ядро Linux 5.4 приняты патчи для ограничения доступа root ..., opennews (ok), 30-Сен-19, (0) [смотреть все]

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


77. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/
Сообщение от Stax (ok), 30-Сен-19, 13:17 
К примеру, от атаки Evil Maid https://en.wikipedia.org/wiki/Evil_maid_attack
Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

80. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/
Сообщение от DerRoteBaron (ok), 30-Сен-19, 13:31 
А еще осложняет cold boot (в особенности при запаянной памяти)
Ответить | Правка | Наверх | Cообщить модератору

90. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +1 +/
Сообщение от Аноним (90), 30-Сен-19, 14:17 
Мне кажется, что угроза cold boot из разряда страшилок, имеющих небольшую практическую угрозу в реальных условиях. Для нее практически надо, чтобы в руки атакующего попал невыключенный компьютер, и даже при этом без гарантий успеха.  Для защиты тут проще сделать задержку с подачей напряжений на память при reset. Впрочем она и так есть, вероятность, что в памяти что-то сохранилось после включения невелика.
Ответить | Правка | Наверх | Cообщить модератору

86. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +3 +/
Сообщение от Аноним (90), 30-Сен-19, 14:09 
Чтобы от этой атаки появилась хотя бы что-то чуть более, чем иллюзия защищенности, надо из UEFI удалить ВСЕ ключи, кроме собственноручно сгенерированных.  Вопрос, многие ли системы позволяют это сделать?

При этом еще надеяться, что у атакующего нет бекдоров для SB и он не сможет, например, просто всю материнскую плату подменить или некоторые микросхемки с uefi перепаять на ней.

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

142. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +1 +/
Сообщение от Stax (ok), 30-Сен-19, 16:47 
> Чтобы от этой атаки появилась хотя бы что-то чуть более, чем иллюзия
> защищенности, надо из UEFI удалить ВСЕ ключи, кроме собственноручно сгенерированных.  
> Вопрос, многие ли системы позволяют это сделать?

Погодите, а это почему?
Наличие ключа MS при условии, что приватным ключом MS кого попало не подписывает - не нарушает безопасность.

А своим ключом MS вроде как кого попало и не подписывает. Свои загрузчики, ну и еще некоторые конкретные сборки shim (которые попросили у них подписать) и еще некоторые вполне конкретные *бинарные* загрузчики. Собрать свой загрузчик-зловред и подписать его сборку у MS - хоть возможно в теории, но на практике из разряда фантазий, не настолько же они идиоты, что попало подписывать.

> При этом еще надеяться, что у атакующего нет бекдоров для SB и
> он не сможет, например, просто всю материнскую плату подменить или некоторые
> микросхемки с uefi перепаять на ней.

Строго говоря, правильное взаимодействие ядра и TPM решило бы эту проблему. Но его нет.

Кстати, сама винда тут весьма правильно делает: она проверяет всю цепочку загрузчиков (*всю* цепочку тех, кто ее загружал - т.е. например конкретный UEFI + конкретный bootmgfw.efi, или же цепочку UEFI + shim + grub + bootmgfw). И если что-то серьезное изменилось в настройках UEFI (к примеру, выключили Secure Boot) или загрузили по другой цепочке (например раньше грузили без grub, а теперь его вставили в цепочку) или же изменился конкретный бинарник shim, она тут же навостряет уши и требует ввести длинный ключ Bitlocker, который сообщался при шифровании диска. При этом это не имеет отношения собственно к пассфразе или отпечатку пальца или другому методу аутентификации, который потом будет использоваться для расшифровки. И это работает в т.ч. при выключенном Secure Boot.

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

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

166. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/
Сообщение от Аноним (90), 30-Сен-19, 19:08 
> Наличие ключа MS при условии, что приватным ключом MS кого попало не подписывает - не нарушает безопасность.

Что знают двое - то знает и свинья (c) "17 мгновений весны".

Нет уж, если действительно безопасность, то дайте мне возможность всё (включая винду, если ее использую) подписать своим и только своим ключом, который кроме меня вообще никто не знает.  А кому там MS дает, кому не дает  в таком случае не волнует совершенно.

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

182. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/
Сообщение от Stax (ok), 30-Сен-19, 23:03 
Ну, возможность у вас есть.
Ответить | Правка | Наверх | Cообщить модератору

167. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/
Сообщение от AlexYeCu_not_logged (?), 30-Сен-19, 19:26 
>Наличие ключа MS при условии, что приватным ключом MS кого попало не подписывает - не нарушает безопасность.

Собственно, это условие и не соблюдается. И, кстати говоря, не может быть соблюдено.

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

185. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/
Сообщение от Анонимный этот (?), 30-Сен-19, 23:22 
> Это очень правильная идея, на самом деле, и обидно что линуксу глубоко
> безразлично, что там происходило до его загрузки - вот какое-то ядро
> загрузилось, теперь вводи пассфразу от luks и пожалуйста, открыт полный доступ
> к системе.

А чем это хуже этого вашего "ключа Bitlocker"? И не полный доступ.

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

186. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/
Сообщение от Stax (ok), 30-Сен-19, 23:25 
Есть разница между короткой пассфразой, выбранной пользователем и вводимой каждую загрузку и длинной специализированной, которая требуется только если произошло что-то подозрительное и изменилась цепочка загрузчика.
Ответить | Правка | Наверх | Cообщить модератору

190. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/
Сообщение от Анонимный этот (?), 30-Сен-19, 23:54 
Что-то эта ваша "длинная специализированная" смахивает на очередное плацебо, потому что не требуется...
Ответить | Правка | Наверх | Cообщить модератору

191. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/
Сообщение от Stax (ok), 30-Сен-19, 23:59 
> Что-то эта ваша "длинная специализированная" смахивает на очередное плацебо, потому что
> не требуется...

В каком смысле не требуется?

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

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

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

239. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/
Сообщение от microsoft (?), 02-Окт-19, 11:56 
> А своим ключом MS вроде как кого попало и не подписывает. Свои
> загрузчики, ну и еще некоторые конкретные сборки shim (которые попросили у

на минуточку - у нас не один ключ!
И ваши шимы мы подписываем _другим_ ключом. Что и позволило огрызку их не загружать. В отличие от б-жественной десяточки.

> них подписать) и еще некоторые вполне конкретные *бинарные* загрузчики. Собрать свой
> загрузчик-зловред и подписать его сборку у MS - хоть возможно в

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

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

> Это очень правильная идея, на самом деле, и обидно что линуксу глубоко
> безразлично, что там происходило до его загрузки - вот какое-то ядро

потому что вашего Линуса - мак!

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

180. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/
Сообщение от Анонимный этот (?), 30-Сен-19, 22:56 
> он не сможет, например, просто всю материнскую плату подменить или некоторые
> микросхемки с uefi перепаять на ней.

Ага. Не сможет. В ряде случаев.
В других случаях проще будет изъять так сказать диск. А там своя защита работающая в паре с UEFI... Правда сейчас в том что в широкой так сказать продаже не очень работающая, но...
Короче придётся атаккеру паять свою плату к своему компу... >:-)

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

133. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/
Сообщение от Armagor (ok), 30-Сен-19, 16:22 
Спасибо за ссылку.
>An evil maid attack is an attack on an unattended device

И чтобы защититься от такой атаки, мы делаем SB с Microsoft в качестве Certification Authority. Что бы могло пойти не так?

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

188. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +2 +/
Сообщение от Аноним84701 (ok), 30-Сен-19, 23:34 
> Спасибо за ссылку.
>>An evil maid attack is an attack on an unattended device
> И чтобы защититься от такой атаки, мы делаем SB с Microsoft в
> качестве Certification Authority. Что бы могло пойти не так?

https://www.opennet.ru/opennews/art.shtml?num=44950
> Утечка мастер-ключа Microsoft скомпрометировала защиту Secure Boot
> 11.08.2016 19:22
> [...] ключ был найден в составе отладочного инструментария, который был забыт на одном из устройств.

[...]
> По сути, все устройства с верифицированной загрузкой Windows скомпрометированы и решить проблему выпуском обычного обновления не получается

[...]
> Устранить проблему просто не получится, так как загрузчик уже поставляется в установочных носителях, а отзыв связанного с ним ключа повлечёт за собой неработоспособность установочных образов, разделов для восстановления и резервных копий.

И правда, что? :)

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

192. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/
Сообщение от Stax (ok), 01-Окт-19, 00:01 
>> Спасибо за ссылку.
>>>An evil maid attack is an attack on an unattended device
>> И чтобы защититься от такой атаки, мы делаем SB с Microsoft в
>> качестве Certification Authority. Что бы могло пойти не так?
> https://www.opennet.ru/opennews/art.shtml?num=44950
>> Утечка мастер-ключа Microsoft скомпрометировала защиту Secure Boot
>> 11.08.2016 19:22
>> [...] ключ был найден в составе отладочного инструментария, который был забыт на одном из устройств.
> [...]
>> По сути, все устройства с верифицированной загрузкой Windows скомпрометированы и решить проблему выпуском обычного обновления не получается

А почитать внимательнее не судьба, да?

> Важно подчеркнуть, что это не PKI-ключ, применяемый для формирования цифровых подписей к исполняемым файлам, а ключ для отключения проверки в загрузчике, не влияющий на надёжность работы прошивок UEFI

Тем, что утекло - свой зловредный загрузчик вы не подпишете.

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

195. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/
Сообщение от Аноним84701 (ok), 01-Окт-19, 00:28 
> А почитать внимательнее не судьба, да?
>> Важно подчеркнуть, что это не PKI-ключ, применяемый для формирования цифровых подписей к исполняемым файлам, а ключ для отключения проверки в загрузчике, не влияющий на надёжность работы прошивок UEFI
> Тем, что утекло - свой зловредный загрузчик вы не подпишете.

Читать внимательно желательно оригинал:
https://gist.github.com/anonymous/c94cadade3a8b87dcdc52c639f...

> The "supplemental" policy does NOT contain a DeviceID. And, because they were meant to be merged into a base policy, they don't contain any BCD rules either,
> which means that if they are loaded, you can enable testsigning. Not just for windows (to load unsigned driver, ie rootkit), but for the {bootmgr} element as well, which allows bootmgr to run what is effectively an unsigned .efi (ie bootkit)!!! (In practise, the .efi file must be signed, but it can be self-signed)   You can see how this is very bad!! A backdoor, which MS put in to secure boot because they decided to not let the user turn it off in certain devices, allows for secure boot to be disabled everywhere!
>  You can see the irony. Also the irony in that MS themselves provided us several
> nice "golden keys" (as the FBI would say ;) for us to use for that purpose :)
>

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

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

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




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

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