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 и затереть все свободное место на диске программой безопасного уничтожения информации.
комментариев: 9796 документов: 488 редакций: 5664
Насколько реалистично написание Hibernate-шифрования вообще (что само по-себе рискованно) и любого шифрования системного раздела под закрытую/коммерческую ОС в частности?
Если это делается не интеграцией функций в ядро, а просто перехватом/заменой соответствующих драйверов? Где гарантия что документация системы достаточна, а какой-нибудь сервис-пак не внесёт существеных изменений в окружение?
комментариев: 371 документов: 19 редакций: 20
Это реально, но требует хорошего знания внутренностей системы, и зачастую дизассемблирования ее ядра.
Абсолютной гарантии нет, но под windows написано немало драйверов storage контроллеров которые используют эти недокументированые структуры. Врядли m$ рискнут сломать совместимость. А если и рискнут, то мы про это быстро узнаем.
Аналогичный риск существует и при использовании сторонных систем шифрования под открытые ОС. В новой версии ОС могут быть добавлены новые фичи про которые старая версия программы не знает, из за чего возможно появление аналогичных уязвимостей.
комментариев: 371 документов: 19 редакций: 20
Я по прежнему не рекомендую использовать TrueCrypt версии выше 4.3 из за ужасающе низкого качества кода линейки 5.x
Кто-то из русских сославшись на этот топик настучал или какие-то иностранцы сами догадались?
Я не системщик и к сожалению с сями плохо знаком. Можно подробнее про низкое качество кода 5ой линейки TC и чем это чревато? Ибо 5.1а по скорости работы раза в 2 превосходит 4.3а на алгоритме twofish и раза в 3 на AES (по карйней мере на моём AMD Athlon 6400) и очень хочется использовать то, что пошустрее. Шифрование системы мне ни к чему и hibernate не использовал и не собираюсь.
Это как? Шифрование ни к чему но хочется использовать то что быстрее? Жостко, ничего не скажешь...
ntldr во-первых, уже отвечал на этот вопрос.
комментариев: 371 документов: 19 редакций: 20
Подробнее уже было. Дополню только, что применительно к контейнерам скорее всего никаких уязвимостей там нет, хотя это не значит что они не могут появиться в следующих версиях.
Я бы сказал несколько иначе: не 5.1 превосходит, а 4.3 отстает. До выхода DiskCryptor они судя по всему вобще не думали о производительности и о шифровании системы, что подтверждено ответами на их форуме. Теперь же надо как-то конкурировать, вот и приходится догонять впереди идущих...
К слову, авторы dm-crypt (Linux) изначально думали об оптимизации шифрования, и изначально писали правильный код. Это так..., мысли о разных подходах к разработке.
комментариев: 9796 документов: 488 редакций: 5664
Но, dm-crypt/cryptsetup выбрали в мэйнстрим и включили в ядро из-за лучшей читаемости кода, предпочтению шифрования томами, а не только через loop-device, отсутствию запутанных нестандартных самописных режимов, наличию хорошей документации и теоретической работы с обоснованием дизайна, а не только файла readme.
Будем надеяться что касаемо loop-aes все эти вкусности тоже со временем появятся.
Как-как! Через верстак! Система грузится с обычного раздела харда, а данные с которыми я работаю цепляются с зашифрованного. Под словом "система" я подразумевал загрузочный раздел с установленной ОС, который мне криптовать не нужно.
В общем ответ на свой вопрос я кое-какой получил, за что и спасибо.