id: Гость   вход   регистрация
текущее время 06:22 09/12/2021
Владелец: ntldr (создано 11/03/2008 10:10), редакция от 11/03/2008 11:01 (автор: ntldr) Печать
Категории: софт, truecrypt
https://www.pgpru.com/Новости/2008/КритическаяУязвимостьВTrueCrypt51
создать
просмотр
редакции
ссылки

11.03 // Критическая уязвимость в TrueCrypt 5.1


10.03.2008 вышел релиз TrueCrypt 5.1 одной из добавленых фич которого является поддержка hibernation. Посмотрев исходный код TrueCrypt, я обнаружил критическую уязвимость приводящую на некоторых конфигурациях железа к полному раскрытию всех ключей шифрования находившихся в памяти в момент использования hibernate. Это дает возможность дешифрования загрузочного раздела, и весьма вероятно всех подключенных контейнеров.


Уязвимость находится в файле DriveFilter.c, и заключается в некорректной реализации перехвата исполнения точки входа dump port драйвера. TrueCrypt определяет нужный драйвер путем сравнения его имени со следующим списком:



Если вы используете нестандартный storage контроллер, то он может иметь свой драйвер реализующий функциональность dump port, и в этом случае содержимое памяти будет записано на диск в открытом виде, что позволяет извлечь ключи шифрования просто просканировав данные на диске.


Еще одна уязвимость находится в этом участке кода:


Структура HiberDriverContext в TrueCrypt описана не полностью. Она имеет слудеющий вид:

Оригинальная структура взятая из открытых источников (отладочных символов на ядро) должна иметь такой вид:

Как вы видите, имеются два обработчика записи данных на диск. Это WriteRoutine и WritePendingRoutine. TrueCrypt обрабатывает только WritePendingRoutine, и если драйвер дамп порта не поддерживает WritePendingRoutine, то данные будут писаться через WriteRoutine, что опять же вызовет утечку ключей шифрования. В частности Windows 2000 всегда использует WriteRoutine, поэтому в этой ОС узявимость проявлялась бы всегда, если бы TrueCrypt мог работать на ней.


Уязвимости подвержены пользователи держащие систему на аппатарных RAID, а частности на популярном чипе Intel Matrix Storage.
Способы решения уязвимости: отключить hibernate в настройках электропитания. В случае если вы уже использовали hibernate вы должны проверить удалился ли файл hiberfil.sys и затереть все свободное место на диске программой безопасного уничтожения информации.


 
— unknown (11/03/2008 11:33)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Оригинальная структура взятая из открытых источников (отладочных символов на ядро) должна иметь такой вид:

Насколько реалистично написание Hibernate-шифрования вообще (что само по-себе рискованно) и любого шифрования системного раздела под закрытую/коммерческую ОС в частности?

Если это делается не интеграцией функций в ядро, а просто перехватом/заменой соответствующих драйверов? Где гарантия что документация системы достаточна, а какой-нибудь сервис-пак не внесёт существеных изменений в окружение?
— ntldr (11/03/2008 11:46, исправлен 11/03/2008 11:48)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Насколько реалистично написание Hibernate-шифрования вообще (что само по-себе рискованно) и любого шифрования системного раздела под закрытую/коммерческую ОС в частности?

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

Где гарантия что
документация системы достаточна, а какой-нибудь сервис-пак не внесёт
существеных изменений в окружение?

Абсолютной гарантии нет, но под windows написано немало драйверов storage контроллеров которые используют эти недокументированые структуры. Врядли m$ рискнут сломать совместимость. А если и рискнут, то мы про это быстро узнаем.
Аналогичный риск существует и при использовании сторонных систем шифрования под открытые ОС. В новой версии ОС могут быть добавлены новые фичи про которые старая версия программы не знает, из за чего возможно появление аналогичных уязвимостей.
— ntldr (17/03/2008 19:38)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Сегодня выпущена версия TrueCrypt 5.1a в которой устранена вышеописаная уязвимость. Но сделано это так, что глядя на этот код хочеться материться.
Я по прежнему не рекомендую использовать TrueCrypt версии выше 4.3 из за ужасающе низкого качества кода линейки 5.x
— Гость (18/03/2008 04:46)   <#>
Сегодня выпущена версия TrueCrypt 5.1a в которой устранена вышеописаная уязвимость.

Кто-то из русских сославшись на этот топик настучал или какие-то иностранцы сами догадались?
— el_Diamante (24/03/2008 01:24)   <#>
Я по прежнему не рекомендую использовать TrueCrypt версии выше 4.3 из за ужасающе низкого качества кода линейки 5.x


Я не системщик и к сожалению с сями плохо знаком. Можно подробнее про низкое качество кода 5ой линейки TC и чем это чревато? Ибо 5.1а по скорости работы раза в 2 превосходит 4.3а на алгоритме twofish и раза в 3 на AES (по карйней мере на моём AMD Athlon 6400) и очень хочется использовать то, что пошустрее. Шифрование системы мне ни к чему и hibernate не использовал и не собираюсь.
— Гость (24/03/2008 01:58)   <#>
Ибо 5.1а по скорости работы раза в 2 превосходит 4.3а на алгоритме twofish ...
очень хочется использовать то, что пошустрее...
...
Шифрование системы мне ни к чему ...

Это как? Шифрование ни к чему но хочется использовать то что быстрее? Жостко, ничего не скажешь...
ntldr во-первых, уже отвечал на этот вопрос.
— ntldr (24/03/2008 02:42)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Можно подробнее про низкое качество кода 5ой линейки TC и чем это чревато?

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

Ибо 5.1а по скорости работы раза в 2 превосходит 4.3а на алгоритме twofish и раза в 3 на AES

Я бы сказал несколько иначе: не 5.1 превосходит, а 4.3 отстает. До выхода DiskCryptor они судя по всему вобще не думали о производительности и о шифровании системы, что подтверждено ответами на их форуме. Теперь же надо как-то конкурировать, вот и приходится догонять впереди идущих...
К слову, авторы dm-crypt (Linux) изначально думали об оптимизации шифрования, и изначально писали правильный код. Это так..., мысли о разных подходах к разработке.
— unknown (24/03/2008 09:07, исправлен 24/03/2008 09:10)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Небольшой оффтопик. А в Линуксе есть один автор – Jari Ruusu, который сильно ругает dm-crypt и продвигает свой loop-aes и альтернативную реализацию cryptoAPI тоже довольно агрессивно и практически в одиночку. Он по скорости вроде бы ещё быстрее из-за ассемблерных сборок (можно было использовать или не использовать под разные процы по желанию).

Но, dm-crypt/cryptsetup выбрали в мэйнстрим и включили в ядро из-за лучшей читаемости кода, предпочтению шифрования томами, а не только через loop-device, отсутствию запутанных нестандартных самописных режимов, наличию хорошей документации и теоретической работы с обоснованием дизайна, а не только файла readme.
— Гость (24/03/2008 21:35)   <#>
Но, dm-crypt/cryptsetup выбрали в мэйнстрим и включили в ядро из-за лучшей читаемости кода, предпочтению шифрования томами, а не только через loop-device, отсутствию запутанных нестандартных самописных режимов, наличию хорошей документации и теоретической работы с обоснованием дизайна, а не только файла readme.

Будем надеяться что касаемо loop-aes все эти вкусности тоже со временем появятся.
— el_Diamante (26/03/2008 01:05)   <#>
Это как? Шифрование ни к чему но хочется использовать то что быстрее? Жостко, ничего не скажешь...


Как-как! Через верстак! Система грузится с обычного раздела харда, а данные с которыми я работаю цепляются с зашифрованного. Под словом "система" я подразумевал загрузочный раздел с установленной ОС, который мне криптовать не нужно.

В общем ответ на свой вопрос я кое-какой получил, за что и спасибо.
— equinox (05/07/2008 22:21)   <#>
Вышла 6-я версия трукрипта. Интересно, пофиксили вышеуказанный баг?
— Гость (06/07/2008 02:02)   <#>
Его ещё давно пофиксили, вскоре после появления этого топика на pgpru (кто-то настучал).
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3