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

Разумеется, иначе бы имело место объективное вменение (безвинная ответственность).

Хороший термин.

[offtop]
При попытке поиска гугл предложил ссылки на стихи Ахматовой:

Звезды смерти стояли над нами,
И безвинная корчилась Русь
Под кровавыми сапогами
И под шинами черных марусь.

[/offtop]

Результаты аудита TrueCrypt 7.1a
Не помню, выкладывался или нет, сегодня перечитал – решил на всякий разместить.

Прочитал, с некоторыми "уязвимостями" не согласен.

The team also found a potential weakness in the Volume Header integrity checks. Currently,
integrity is provided using a string (“TRUE”) and two (2) CRC32s. The current version of True-
Crypt utilizes XTS2 as the block cipher mode of operation, which lacks protection against modi-
fication; however, it is insufficiently malleable to be reliably attacked. The integrity protection
can be bypassed, but XTS prevents a reliable attack, so it does not currently appear to be an is-
sue. Nonetheless, it is not clear why a cryptographic hash or HMAC was not used instead.

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

1. Weak Volume Header key derivation algorithm
Class: Cryptography
Severity: Medium
Difficulty: Medium
FINDING ID: iSEC-OCAP-11
TARGETS: Encrypted Volume Header
DESCRIPTION: The key used to encrypt the TrueCrypt Volume Header is derived using PBKDF2,
a standard key derivation algorithm5. Developers are responsible for specifying an iteration
count that influences the computational cost of deriving a key from a password. The iteration
count used by TrueCrypt is either 1000 or 2000, depending on the hash function and use case.
In both cases, this iteration count is too small to prevent password guessing attacks for even
moderately complex passwords. The paper that introduces scrypt6, an alternate key derivation
function, demonstrates the challenge of using PBKDF2 even with a very high iteration count –
brute-forcing key derivation is easily parallelized and becomes more efficient each year with ad-
vances in CPU performance. The use of a small iteration count in TrueCrypt permits efficient
brute-force attacks against its header key.
EXPLOIT SCENARIO: An attacker captures an encrypted TrueCrypt volume and performs an of-
fline brute-force and / or dictionary attack to identify the key used to encrypt the Volume Head-
er. They use the recovered key to decrypt the volume.
SHORT TERM SOLUTION: Support the use of configurable iteration counts for PBKDF2 to keep
pace with advances in CPU and GPU speed. If the current volume format does not include re-
served space to store such a value, and if changes to the Volume Header cannot be made, this
value might be derived from a portion of the salt, so long as it is guaranteed to exceed a certain
minimum value.
LONG TERM SOLUTION: Consider supporting the use of additional key derivation functions.
Scrypt, in particular, requires the use of large amounts of memory and requires more expensive
hardware to brute-force.

Опять пустопорожняя придирка. PBKDF2 вполне стойкая функция, нареканий не вызывает, а то что сейчас придуманы другие – не повод тащить их в проект. Про стойкость scrypt еще бабушка надвое сказала (лично мне она не нравится). К тому-же scrypt в качестве KDF не применим для загрузчика, т.к. загрузчик испытывает катастрофическую нехватку памяти, то что есть – влезло только чудом, ни о каких scrypt, или других KDF использующих много памяти, не может быть и речи. Количество итераций можно увеличить, но это не принципиально. Стойкие пароли по прежнему остаются стойкими.

3. Multiple issues in the bootloader decompressor
Class: Data Validation
Severity: Medium
Difficulty: High
FINDING ID: iSEC-OCAP-5
TARGETS: Decompressor.c
DESCRIPTION: The code to decompress the main bootloader suffers from several implementation
weaknesses. Throughout the source code, signed and unsigned integer types are mixed, arrays
are accessed without checking if the index is within bounds, and so forth. In several cases, the
lack of array bounds checking results out-of-bound accesses actually being performed. Three (3)
examples can be found in Appendix A.
It should be noted that in order to exploit this, an attacker would need access to the disk on
which the TrueCrypt-encrypted system resides. An attacker with this level of access could in-
stead perform a more effective evil maid attack8.
EXPLOIT SCENARIO: An attacker modifies the compressed bootloader on the disk to exploit one
of the issues in the decompressor. Successful exploitation allows the attacker to modify the
TrueCrypt code to record and save the password while the user enters it.
SHORT TERM SOLUTION: Fix the issues identified in the decompressor. Alter the input buffer
handling to take an input size argument and verify that the code does not attempt to read past
the end of the buffer while decompressing.
LONG TERM SOLUTION: Make integer types more consistent throughout the TrueCrypt source
code, favoring well-defined unsigned types wherever possible. Perform extensive fuzzing of the
bootloader decompressor as well as a more in-depth review of the functionality.

Еще одна глупейшая придирка. От декомпрессора в данном случае требуется ровно одно – чтобы он работал. Он работает. Если атакующий способен модифицировать сектора диска на низком уровне, абсолютно не важно какой там декомпрессор, не важно даже есть он или нет, можно модифицировать любой код. Просто написать что-то было нужно, а придраться больше не к чему.

А теперь настоящие дефекты с которыми я согласен:

2. Sensitive information might be paged out from kernel stacks
Class: Data Exposure
Severity: Medium
Difficulty: High
FINDING ID: iSEC-OCAP-6
TARGETS: TrueCrypt Windows kernel driver
DESCRIPTION: The TrueCrypt Windows driver code makes some effort to prevent sensitive in-
formation from being paged out during a low memory situation by allocating memory from the
non-paged pool. However, sensitive information, such as key material, may still leak to various
places during execution, among those kernel stack pages, which can be paged out under certain
conditions.
If the stack for the system thread created during volume mounting were to be paged out, there is
a risk that key information in ReadVolumeHeader() could end up on disk.
It should be noted that for this to be a threat, the user must be running a configuration in which
the main Windows system disk is not encrypted, something the TrueCrypt documentation ex-
plicitly recommends against7.
EXPLOIT SCENARIO: A user has a system with a TrueCrypt-encrypted partition on it, in which
they save sensitive information. An attacker creates a low memory situation on the user’s ma-
chine, forcing key information to be paged out to the unencrypted system disk. The attacker
later gains access to the disk and can extract the key from the page file.
SHORT TERM SOLUTION: Consolidate all sensitive information to one single location. The data can then be locked into memory with the help of functions such as MmLockPagableDataSection() or KeSetKernelStackSwapEnable() to prevent it from being paged
out to disk.
LONG TERM SOLUTION: The short term solution is sufficient to correct this issue. The TrueCrypt
team already has documentation discouraging users from using a setup that could be exposed to
this.

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

4. Windows kernel driver uses memset() to clear sensitive data
Class: Data Exposure
Severity: Medium
Difficulty: High
FINDING ID: iSEC-OCAP-8
TARGETS: TrueCrypt Windows kernel driver
DESCRIPTION: The function burn() is used to clear sensitive data throughout most of the True-
Crypt Windows kernel driver. In the Windows version, burn() wraps RtlSecureZeroMemory(),
which is guaranteed to securely erase memory and will not be optimized out. However, in a
handful of places, memset() is used to clear potentially sensitive data. Calls to memset() run the
risk of being optimized out by the compiler.
One such location identified is in DriveFilter.c, line 104:
BootArgs = *bootArguments;
BootArgsValid = TRUE;
memset (bootArguments, 0, sizeof (*bootArguments));

if (BootArgs.BootLoaderVersion < 0x600)
With a second one later in the same file, at line 335:
if (mappedCryptoInfo)
{

Dump ("Wiping memory %x %d\n", cryptoInfoAddress.LowPart,

BootArgs.CryptoInfoLength);

memset (mappedCryptoInfo, 0, BootArgs.CryptoInfoLength);
MmUnmapIoSpace (mappedCryptoInfo, BootArgs.CryptoInfoLength);

}
EXPLOIT SCENARIO: A user has a system with a TrueCrypt-encrypted partition on it, in which
they save sensitive information. An attacker creates a low memory situation on the user’s ma-
chine, forcing key information that should have been securely wiped to be paged out to the un-
encrypted system disk. The attacker later gains access to the disk and extracts the key from the
paging file.
SHORT TERM SOLUTION: Alter the above code to call burn() instead of memset().
LONG TERM SOLUTION: Audit the code for other instances of memset() calls that should be re-
placed with calls to burn() to prevent potential information leakage.

Всё как сказали. memset не гарантирует зануления, компилятор может его выбросить при оптимизации. Следует использовать RtlSecureZeroMemory, либо интринсики stosb / stosd, либо самописную функцию зануления на volatile pointer'ах. Обязателен контроль созданного компилятором кода через дизассемблер.

5. TC_IOCTL_GET_SYSTEM_DRIVE_DUMP_CONFIG kernel pointer disclosure
6. IOCTL_DISK_VERIFY integer overflow
7. TC_IOCTL_OPEN_TEST multiple issues
8. MainThreadProc() integer overflow
9. MountVolume() device check bypass
10. GetWipePassCount() / WipeBuffer() can cause BSOD
11. EncryptDataUnits() lacks error handling

Малозначимые ошибки, требуют устранения, но опасности не несут.

Ты под Linux не планируешь DC затачивать?

присоединяюсь к вопросу. очень не помешала бы возможность использование шифрованных разделов и там и там (win и lin).

Перечитав еще раз, обратил внимание что уязвимость "4. Windows kernel driver uses memset() to clear sensitive data" на самом деле высосана из пальца. В том контексте memset не может быть удален оптимизатором и всё работает как требуется. Severity: Medium выставлен необоснованно, эта "уязвимость" имеет Severity: Informational, не более. Занулять memset'ом нельзя переменные в стеке.

И вдумчиво прочитайте это:

SHORT TERM SOLUTION: Support the use of configurable iteration counts for PBKDF2 to keep
pace with advances in CPU and GPU speed. If the current volume format does not include re-
served space to store such a value, and if changes to the Volume Header cannot be made, this
value might be derived from a portion of the salt, so long as it is guaranteed to exceed a certain
minimum value.

Это просто шедевр! Они предлагают похерить отрицаемость для закрытия совершенно надуманной "уязвимости". У меня есть большие сомнения насчет качества этого аудита. Наговаривают почем зря.

Ты под Linux не планируешь DC затачивать?

Разве что утилиту для монтирования. Полноценное портирование слишком трудозатратно, поддержка еще более трудозатратна. У меня слишком мало свободного времени, чтобы этим заниматься.

Ну хоть монтирование – и то здорово будет. По поводу уязвимостей – ну так целенаправленное ослабление криптографии и внедрение закладок всеми способами ведется, поэтому понятно, что из пальца высасывать будут. Меня лично всегда удивляли претензии к анонимности авторов, так мб поэтому проект более-менее чист, что авторов за яйца просто так не взять? Равносиль, что к тебе претензии за ник предъявлять, тем самым пытаясь под сомнения DC ставить... ну посмотрим, когда может и его аудит кто надумает делать – что из пальца там повысасывают, вместе поугараем) он просто менее интересен, т.к. под винду, поэтому внимания меньше, че к ТС.

Почти идентичные тексты. :-) Кстати, эта уязвимость вроде как была именно данного типа.


Не знаю, насколько страшно оно тут, но целочисленное переполнение в Linux-софте — одна из самых распространённых ошибок в багрепортах, приводящих к фатальным последствиям типа исполнения произвольного кода.


Уже есть ограниченная поддержка TC в cryptsetup и через tc-play. Возможно, поддержку DC проще было бы добавить в эти программы, чем делать полностью оригинальный софт.


Есть много ошибок из категории «так делать плохо, так делать не принято, это опасно, но в конкретно данном случае прямой уязвимости вроде не возникает, да». Это как претензии к тому, что код плохо откомментирован: само по себе это не уязвимость, но может привести к уязвимости через некоторое время. Как я понимаю, ряд претензий был именно такого рода. В то же время, могут быть разные школы, и не быть консенсуса на тему того, как делать правильно, а как не стоит. Для одних это может быть делом вкуса и предпочтений, а другие за тем же самым могут видеть потенциальную уязвимость с примером «как делать не надо».

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

Допустим, в простейшем случае есть некоторый предопределённый текст (сигнатура), и если он появляется в заголовке, то считается, что пароль верный. Однако, можно было бы поступить хитрее: дать пользователю самому указывать, что является такой сигнатурой. Это было бы как вторая часть пароля. Т.е. пароль сам бы в себе содержал как функции расшифрования, так и проверку корректности расшифрования. А поскольку какая должна быть сигнатура, противник не знает, он не мог бы отличить правильный исходной пароль от неправильного.

Этим свойством можно было бы пользоваться для последовательного бессигнатурного шифрования данных (не хочу говорить каскадрного, потому что смысл здесь другой: например, бессигнатурное шифрование всего диска и потом, если дать второй правильный пароль, получаем таблицу разделов; тогда не зная первый пароль, противник не знает, правильный ли он, пока не получит оба). Может быть, пример натянутый, но смысл примерно в этом: противник после осуществления cold boot атаки не должен получить всю информацию о структуре всех разделов/томов диска, если они были в отмонтированном состоянии (но считается неизбежным, что он получит информацию о тех разделах, которые были в тот момент подмонтированы).

На тему отрицаемого шифрования и вообще: как софт определяет, что пароль верный? <...> Допустим, в простейшем случае есть некоторый предопределённый текст (сигнатура), и если он появляется в заголовке, то считается, что пароль верный.

Так и есть. В блок шифруемых метаданных ставится волшебное слово; если при расшифровании оно находится в ожидаемом месте, значит, пароль верный. Вероятность ложного срабатывания существует, но она чрезвычайно мала.

А можно и рэндомное слово:

X₁ = Random IV

X₂ = Hash-MAC_X1 (KeyFromPass)

Y = Encrypt_KeyFromPass (X₁ ║ X₂)

---

Z = Decrypt_KeyFromPass (Y) = X₁ ║ X₂

Z' = Hash-MAC_X1 (KeyFromPass)

if Z' = X₂ then Decrypt(KeyFromPass) is true

Две маленькие уязвимости в TrueCrypt, чудом не ставшие большими

На днях мною были найдены еще две уязвимости в TrueCrypt 7.1a, которые остались незамеченными аудитом.

Уязвимость №1. Тип: утечка данных. Опасность: средняя. Возможность эксплуатации: низкая.

При предзагрузочной аутентификации загрузчик сохраняет пароль в первом мегабайте памяти для передачи драйверу, а драйвер его оттуда удаляет. Этот процесс нарушается при использовании гибернации. При выходе из гибернации загрузчик оставляет пароль в памяти, а драйвер ничего об этом не знает. Пароль остается по физическому адресу 0x90026 и мог бы быть доступен любым приложениям через память ntvdm, если бы не случайное везение, благодаря которому эта область памяти не попадает в отображаемые ntvdm регионы.
Уязвимость потенциально может приводить к утечке пароля от загрузочного диска.

Решение: в обработчике IRP_MN_SET_POWER отслеживать событие PowerSystemWorking и повторять поиск данных загрузчика в памяти. Отключить гибернацию до устранения уязвимости.

Уязвимость №2, Тип: утечка данных. Опасность: низкая. Возможность эксплуатации: на данный момент невозможна.
Обработчик DumpFilterWrite (файл DumpFilter.c), исполняющийся на уровне IRQL = HIGH_LEVEL подменяет содержимое writeMdl, используя функцию MmBuildMdlForNonPagedPool, которую допустимо вызывать на IRQL <= DISPATCH_LEVEL, что является грубой ошибкой. Если MmBuildMdlForNonPagedPool будет работать неправильно, возможна утечка данных, описываемых оригинальной writeMdl на диск в открытом виде, что потенциально приводит к полной компрометации всех ключей шифрования. Благодаря счастливому стечению обстоятельств этого не происходит, но поведение функции MmBuildMdlForNonPagedPool может быть изменено в следующих версиях Windows.

Решение: создавать MDL вручную. Отключить гибернацию до устранения уязвимости.

Само по себе это, пожалуй, не очень интересно. Если на то пошло, можно шифровать через cryptsetup plain mode и всегда получать на выходе набор случайных данных. Вопрос будет в том, как доказать, что эти данные и есть правильный результат расшифрования, и вы не обманываете, давая рандомный пароль.

Осмысленная схема всё равно сводится к двухпарольной в следующем смысле: дали правильный пароль — открылся скрытый контейнер, дали неправильный пароль — открылась обманка, всё как в идеологии TrueCrypt. В этом случае можно было бы сделать пароль, являющийся конкатенацией собственно KeyFromPass и IV. Тогда при правильном IV расшифровывается в правильный X₂, а при неправильном IV — в X₂, соответствующий обманке. Тут, конечно, интуитивно хочется, чтобы одни и те же шифрованные данные могли быть дешифрованы двояким образом, но на практике такое недостижимо, если я правильно понимаю (одноразовый блокнот — исключение). Соответственно, чтобы создать имитацию такой осуществимости, делают разделение данных внутри шифрованного объёма: одни соответствуют только обманке, а другие — только реальным данным, а противнику реальные данные выдаются за свободное место в контейнере/ФС/LVM и т.п. Итак, раз всё равно данные разделять, смысла делать вами приведённое расшифрование с проверкой случайной строки нет: можно точно так же сделать расшифрование через plain mode в обманку, где внутри будет ФС и всё такое, а для подключения реальных данных с этого же раздела/диска нужно будет задать иной пароль, правильный, и оффсеты (адресацию свободных блоков).

Кстати, сейчас пришла в голову гениальная мысль: вместо того, чтобы адресовать свободное пространство на ФС, можно в обманке (подключенной через plain mode) просто создать LVM volume group, внутри какие-то логические, разметить их и положить туда обманные данные. Как мне кажется, LVM, в отличие от ФС, не пишет информацию о суперблоках и остальном куда попало на дисковом пространстве, поэтому можно будет легко заранее сказать, какие сектора не будут использоваться LVM'ом для записи. Если что, можно сказать, что это место пока не используется, и из него пополянется пул при нехватке места на уже выделенных логических томах (примерно как unknown делает^*). А реально неиспользуемое место элементарно адресуется через dmsetup и цепляется через всё ту же plain mode как скрытый раздел.

Чисто интуитивно кажется, что неиспользуемое место на ФС более правдоподобно отрицаемо, чем неиспользуемый объём внутри volume group, но это уже вопрос психологии. Вообще, если честно, когда переделывал схему данных для себя по уму, даже без ориентировки на отрицаемость сразу сделал именно так: большой VG, свободное место которого используется для пополнения внутренних LV по мере надобности. Вроде это вполне естественный use case. По факту сложно бывает предсказать, как быстро и насколько разрастётся тот или иной LV, поэтому добавление места «на лету по мере надобности» самое оптимальное. А когда LVM'а нет, возникает стандартная проблема: один раздел уже заполнен, ему нужно место, но взять его неоткуда; зато есть другой раздел, где место есть и пока не нужно, но оттуда его не перекинуть. А если писать данные на иной раздел, его надо будет монтировать как и первый, поэтому возникает смешивание: приходится без надобности держать ключи в памяти на те разделы, которые в данный момент, казалось бы, не должны быть нужны.

^*См. пост:

А я часто забиваю весь физический том рэндомом, а внутри создаю логические с запасом на вырост и оставляю кучу свободного места. Потому что расширение томов с ФС менее глючно, чем сжатие.

Хорошо бы уточнить, потому как он предназначен для лёгкого перемещения и прочих аналогичных операций. Кроме того, UID'ы томов при vgscan, lvscan и пр. могут где-то кэшироваться в системе на корневом разделе.