Re: [DONE] wml://security/2015/dla-265.wml
On Mon, May 30, 2016 at 10:07:54PM +0500, Lev Lamberov wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> - --- english/security/2015/dla-265.wml 2016-04-08 01:24:54.000000000 +0500
> +++ russian/security/2015/dla-265.wml 2016-05-30 22:07:04.568752249 +0500
> @@ -1,45 +1,46 @@
> - -<define-tag description>LTS security update</define-tag>
> +#use wml::debian::translation-check translation="1.2" maintainer="Lev Lamberov"
> +<define-tag description>обновление безопасности LTS</define-tag>
> <define-tag moreinfo>
> - -<p>Martin Prpic has reported the possibility of a man-in-the-middle attack
> - -in the pykerberos code to the Red Hat Bugzilla (Fedora bug tracker). The
> - -original issue has earlier been <a href="https://www.calendarserver.org/ticket/833";>reported upstream</a>. We are quoting the
> - -upstream bug reported partially below:</p>
> - -
> - -<p>The python-kerberos checkPassword() method has been badly insecure in
> - -previous releases. It used to do (and still does by default) a kinit
> - -(AS-REQ) to ask a KDC for a TGT for the given user principal, and
> - -interprets the success or failure of that as indicating whether the
> - -password is correct. It does not, however, verify that it actually spoke
> - -to a trusted KDC: an attacker may simply reply instead with an AS-REP
> - -which matches the password he just gave you.</p>
> - -
> - -<p>Imagine you were verifying a password using LDAP authentication rather
> - -than Kerberos: you would, of course, use TLS in conjunction with LDAP to
> - -make sure you were talking to a real, trusted LDAP server. The same
> - -requirement applies here. kinit is not a password-verification service.</p>
> - -
> - -<p>The usual way of doing this is to take the TGT you've obtained with the
> - -user's password, and then obtain a ticket for a principal for which the
> - -verifier has keys (e.g. a web server processing a username/password form
> - -login might get a ticket for its own HTTP/host@REALM principal), which
> - -it can then verify. Note that this requires that the verifier has its
> - -own Kerberos identity, which is mandated by the symmetric nature of
> - -Kerberos (whereas in the LDAP case, the use of public-key cryptography
> - -allows anonymous verification).</p>
> - -
> - -<p>With this version of the pykerberos package a new option is introduced
> - -for the checkPassword() method. Setting verify to True when using
> - -checkPassword() will perform a KDC verification. For this to work, you
> - -need to provide a krb5.keytab file containing service principal keys for
> - -the service you intend to use.</p>
> - -
> - -<p>As the default krb5.keytab file in /etc is normally not accessible by
> - -non-root users/processes, you have to make sure a custom krb5.keytab
> - -file containing the correct principal keys is provided to your
> - -application using the KRB5_KTNAME environment variable.</p>
> +<p>Мартин Прпик сообщил в Red Hat Bugzilla (системе отслеживания ошибок Fedora)
> +о возможности осуществления атак по принципу человек-в-середине в коде pykerberos. Ранее
> +о проблеме было <a href="https://www.calendarserver.org/ticket/833";>сообщено автором основной ветки разработки</a>. Ниже
> +приводится сообщение об ошибке из основной ветки разработки:</p>
> +
> +<p>Метод checkPassword() в python-kerberos в предыдущем выпуске
> +оказался небезопасным. Он использовался для выполнения (и по умолчанию используется до сих пор) kinit
> +(AS-REQ) для запроса TGT у KDC для данной учётной записи, а также
> +интерпретирует успешное выполнение этой операции или ошибку, указывая то, верен
> +пароль или нет. Тем не менее, этот метод не выполняет проверку того, чтобы
> +взаимодействие осуществлялось с доверенной KDC: злоумышленник может ответить вместо KDC сообщением с AS-REP,
> +совпадающим с переданным им паролем.</p>
> +
> +<p>Представьте, что вы проверяете пароль, используя аутентификацию LDAP, а не
> +Kerberos: конечно, вы будете использовать TLS с LDAP для того, чтоб
> +убедиться, что вы взаимодействуете с настоящим доверенным сервером LDAP. Тут применяется
> +то же требование. kinit не является службой проверки паролей.</p>
> +
> +<p>Обычно, вы используете TGT, полученный вместе с паролем пользователя,
> +затем получаете билет для учётной записи, для которой у проверяющего
> +имеются ключи (например, веб-сервер, проверяющий имя пользователя и пароль в форме
> +аутентификации, может получить билет для своей собственной учётной записи HTTP/host@REALM), которые
> +он затем может проверить. Заметьте, что это требует того, чтобы проверяющий имел свою
> +собственную учётную запись Kerberos, что требуется из-за симметричной природы
> +Kerberos (а в случае с LDAP использование шифрования с открытыми ключами
> +позволяет осуществлять анонимную проверку).</p>
> +
> +<p>В этой версии пакета pykerberos добавлена новая опция для
> +метода checkPassword(). Установка опции verify в значение True при использовании
> +метода checkPassword() приведёт к выполнению проверки KDC. Это этого вам
_Для_ этого
> +следует предоставить файл krb5.keytab, содержащий ключи учётных записей для
> +службы, которую вы намерены использовать.</p>
> +
> +<p>Поскольку по умолчанию файл krb5.keytab в /etc не доступен
> +пользователям и процессам, не имеющим права суперпользователя, вам следует убедиться, что ваш собственный файл
"прав_ суперпользователя", можно также "привилегий", но по смыслу
будет правильней просто "кроме суперпользователя"
Reply to: