Подразделы

• Откуда они берутся
• Как они шифруются

Про пароли

Откуда они берутся

Всё началось несколько месяцев назад, когда ряд моих коллег обнаружил (не без ужаса), что иногда к серверу можно подключиться под SYSDBA не вводя пароля. Или с паролем, гораздо более длинным, нежели он реально установлен. В ходе дальнейших разбирательств выяснилось, что даже убивание переменных ISC_USER и ISC_PASSWORD проблему иногда не устраняет -- вводишь SYSDBA, жмёшь Enter, и оказываешься в базе под полными правами.

В конце концов выяснилось, что коварные переменные были установлены ... в сервере. И этого оказалось достаточно. В результате методичного перебора комбинаций было выяснено следующее (сервер был тогда 4.2/NT).

• У пользователя запрашиваются имя и пароль. Или берутся с комстроки, смотря что и как запускалось.

• Из полученных строк выкидываются начальные и конечные пробелы.

• Если значения после этого стали пустыми, но определены соответствующие переменные окружения ISC_*, то подставляются значения из переменных.

• Полученные значения уезжают на сервер.

• Сервер проверяет, не пустые ли они, и если пустые, то точно так же пытается подставить уже свои серверные (!) значения ISC_*.

• Полученные в результате значения сверяются с базой пользователей isc4.gdb.

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

Наименее актуальна данная проблема для классической архитектуры под *nix. Ведь inetd обычно запускается из стартовых скриптов системы, в то время как ISC_* устанавливаются в пользовательском окружении, где-нибудь в profile. За весь свой опыт не помню, чтобы эти вещи у меня пересеклись.

Абсолютно безопасна с точки зрения данной проблемы, на мой взгляд, платформа NetWare. Там переменных окружения вообще нет. По крайней мере в те времена, когда я имел дело с 3.11 и 3.12, ничего такого не было. Хотя конечно, NetWare неудобна для сервера баз данных по другим причинам.

С другой стороны, наиболее вероятна подобная ситуация под NT, с её возможностью глобальной настройки переменных, включаемых во все окружения. 10 раз подумайте, прежде чем добавлять туда что-либо, особенно пароль! И даже если это не связано с InterBase . Собственно под NT данная опасность и была обнаружена.

Аналогичным образом потенциально опасны настройки, сделанные в autoexec.bat под Win9x. Кроме того, об окружении никогда нельзя забывать, когда запускаешь сервер ``руками'', на какой бы платформе это ни происходило.

Как они шифруются

Здесь надо заметить, что упомянутая технология на самом деле предусматривает шифрование лишь первых 64 бит пароля, то есть 8 символов. С учётом выкидывания пробелов. Остальные символы могут быть любыми. Благодаря этому, например, вместо ``masterkey'' можно написать ``masterkeyxyz'', и даже ``masterke''.

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

Но сначала почва для проблем была дополнительно подготовлена при портировании InterBase на платформы, не имеющие crypt(). Естественно, в код, специфичный для этих платформ была включена функция crypt(), позаимствованная из Unix. Однако в InterBase для предыдущих платформ это заимствование внесено не было. Таким образом возник ещё один повод, чтобы с одной стороны поменялось, а с другой -- нет.

И наконец, настал тот день, когда алгоритм шифрования под Unix начал меняться. Вместо старого, по нынешним временам малоразрядного и обросшего несметным количеством кряков DES функцию crypt() научили MD5. Если не вдаваться в подробности, то MD5 шифрует по другому алгоритму (строго говоря -- это алгоритм хеширования, обратную операцию, то есть расшифровку, вообще не поддерживает) и работает с паролями большей длины. И естественно, если на одном конце пароль зашифрован по одной технологии, а на другом конце соединения установлена другая, то сравнение потерпит неудачу и пользователь до работы допущен не будет.

Замена произошла, насколько мне известно, при переходе к glibc 2.1, в частности в системах Linux и FreeBSD. Более того, новая версия пакета системных библиотек содержала по умолчанию поддержку нового MD5, а старый DES поставлялся в виде отдельной библиотеки descrypt, которую следовало доустановить при острой необходимости в обратной совместимости. Многие пользователи и администраторы с непривычки этот момент упустили.

В результате возникла ситуация, в типичном случае примерно следующая: клиенты под Windows используют DES (единственное, что зашито в них авторами InterBase), а сервера под *nix -- MD5. Подключиться невозможно. Более того, база isc4.gdb, поставляемая с InterBase, изначально содержит SYSDBA/masterkey, причём пароль зашифрован именно DES. В результате после такой установки даже первые администраторские подключения внутри одной системы осуществить невозможно.

К сожалению, я не могу сказать, как дальше будет развиваться ситуация с платформами и технологиями шифрования. Пока же наиболее разумный и правильный подход -- привести всё к единому, давно принятому в InterBase стандарту, DES. То есть при установке сервера под *nix необходимо удостовериться, что необходимые библиотеки установлены. К счастью, начиная с glibc2.2 похоже, что обе технологии шифрования будут поставляться вместе и ничего доустанавливать не потребуется.