元の修正が KDC の検証サポートをデフォルトで無効にしておらず、checkPassowrd() の署名を変更していることが判明しました。この更新ではこの問題が解決されます。

元のアドバイザリのテキストは次のようでした：

Martin Prpic 氏は、pykerberos コードに中間者攻撃の可能性があることを Red Hat Bugzilla（Fedora バグトラッカー）に報告しています。元の問題は、それよりも前に Upstream で報告されています [1]。
下記で一部が報告された Upstream のバグを引用しています：

これまでのリリースにおいて、python-kerberos の checkPassword() メソッドの安全性はひどい状態でした。以前は、指定されたユーザープリンシパルに対する TGT を KDC に要請するために、kinit（AS-REQ）を行っていました（今でもデフォルトで行います）。さらに、その成功または失敗を、パスワードが正しいかどうかを示すものとして解釈します。ただし、信頼できる KDC に本当に問い合わせたことを検証しておらず、攻撃者は、指定されたパスワードに一致する AS-REP を、代わりにただ返信するだけかもしれません。

Kerberos ではなく、LDAP 認証を使用しているパスワードを検証することを考えてみてください。本当に信頼できる LDAP サーバーに問い合わせていることを確認するには、言うまでもなく、LDAP と同時に TLS を使用するでしょう。ここで同じ要件を適用すると、kinit はパスワードを検証するサービスではなくなります。

これを通常の方法で行うには、ユーザーのパスワードから得られた TGT を持ち込み、続いて検証機能が保有しているキーに対するプリンシパル用のチケットを取得します（ユーザー/パスワード形式のログインを処理している Web サーバーは、そのサーバー自身の HTTP/host@REALM プリンシパルに対するチケットを入手する場合があります）。これで検証が可能になります。この場合、検証機能は独自の Kerberos ID を保有している必要があり、これは Kerberos の対称特性により必須であることに注意してください（一方、LDAP の場合、公開鍵の暗号を使用すると、匿名での検証が可能になります）。

このバージョンの pykerberos パッケージでは、checkPassword() メソッドに新しいオプションを導入しています。checkPassword() を使用する際に検証を True に設定することで、KDC の検証を行います。これを動作させるには、使用する予定のサービスに対するサービスプリンシパルキーを含む、krb5.keytab ファイルを用意する必要があります。

ルート以外のユーザー/プロセスは、/etc にあるデフォルトの krb5.keytab ファイルに通常ではアクセスできないため、正しいプリンシパルキーを含むカスタムな krb5.keytab ファイルが、KRB5_KTNAME 環境変数を使用して、お使いのアプリケーションに指定されていることを確認する必要があります。

注：Debian squeeze(-lts) では、既存の設定を損なわないようにするために、KDC の検証サポートはデフォルトで無効になっています。

[1] https://www.calendarserver.org/ticket/833

注：Tenable Network Security は、前述の記述ブロックを DLA セキュリティアドバイザリから直接抽出しています。Tenable では、できる限り新たな問題を持ち込まないように、自動的に整理して書式設定するようにしています。

検出

Debian DLA-265-2：pykerberos のバグ回帰の更新

high Nessus プラグイン ID 84507

変更ログが見つかりません