The version of FreeBSD installed on the remote host is prior to tested version. It is, therefore, affected by a vulnerability as referenced in the 2acdf364-9f8d-4aaf-8d1b-867fdfd771c6 advisory.

  - The checkPassword function in python-kerberos does not authenticate the KDC it attempts to communicate     with, which allows remote attackers to cause a denial of service (bad response), or have other unspecified     impact by performing a man-in-the-middle attack. (CVE-2015-3206)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

リモートホストにインストールされている FreeBSD のバージョンは、テスト済みバージョンより前です。したがって、2acdf364-9f8d-4aaf-8d1b-867fdfd771c6 のアドバイザリに記載されている脆弱性の影響を受けます。

  - python-kerberos の checkPassword 関数は、通信を試みる KDC を認証しません。これにより、リモートの攻撃者が、サービス拒否 (不適切な応答) を引き起こしたり、中間者攻撃を実行することで、他の詳細不明な影響を与える可能性があります。(CVE-2015-3206)

Nessus はこの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

It was discovered that the original fix did not disable KDC verification support by default and changed checkPassowrd()'s signature. This update corrects this.

This was the text of the original advisiory :

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 reported upstream [1].
We are quoting the upstream bug reported partially below :

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.

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.

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).

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.

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.

Note: In Debian squeeze(-lts), KDC verification support is disabled by default in order not to break existing setups.

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

NOTE: Tenable Network Security has extracted the preceding description block directly from the DLA security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - The checkPassword function in python-kerberos does not authenticate the KDC it attempts to communicate     with, which allows remote attackers to cause a denial of service (bad response), or have other unspecified     impact by performing a man-in-the-middle attack. (CVE-2015-3206)

Note that Nessus relies on the presence of the package as reported by the vendor.

元の修正が 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 では、できる限り新たな問題を持ち込まないように、自動的に整理して書式設定するようにしています。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - python-kerberos の checkPassword 関数は、通信を試みる KDC を認証しません。これにより、リモートの攻撃者が、サービス拒否 (不適切な応答) を引き起こしたり、中間者攻撃を実行することで、他の詳細不明な影響を与える可能性があります。(CVE-2015-3206)

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

已发现原始补丁默认未禁用 KDC 验证支持，并更改了 checkPassowrd() 的签名。此更新修正此问题。

以下是原始公告的文本：

Martin Prpic 已向 Red Hat Bugzilla（Fedora 缺陷跟踪程序）报告 pykerberos 代码中存在中间人攻击的可能性。原始问题此前已在上游报告 [1]。
我们将报告的上游缺陷部分引用如下：

python-kerberos checkPassword() 方法在之前的版本中非常不安全。过去它执行（现在仍默认执行）kinit 命令 (AS-REQ) 以要求 KDC 提供给定用户主体的 TGT，并将其是否成功解释为指示密码是否正确。但是它未验证与其实际对话的 KDC 是否受信任：攻击者可直接回复，而不是由与其给予您的密码相匹配的 AS-REP 进行回复。

想象一下，您正在使用 LDAP 认证（而不是 Kerberos）验证密码：您一定会使用 TLS 配合 LDAP 以确保正在与真实可信任的 LDAP 服务器对话。此处的要求是一样的。kinit 不是密码验证服务。

通常的做法是使用与用户密码一同取得的 TGT，然后取得校验器拥有其密钥的主体的票证（例如处理用户名/密码表单登录的 Web 服务器可获得其自己的 HTTP/host@REALM 主体的票证），然后校验器才能进行验证。请注意，这要求校验器具有自身的 Kerberos 身份，这是 Kerberos 的对称性所强制要求的（而在 LDAP 的情况中，使用公钥密码允许匿名验证）。

通过此 pykerberos 程序包版本，为 checkPassword() 方法引入了一个新的选项。当使用 checkPassword() 并将验证设置为 True 时，将执行 KDC 验证。为了使其生效，您需要提供包含有您想要使用的服务的服务主体密钥的 krb5.keytab 文件。

由于 /etc 中的默认 krb5.keytab 文件通常无法被非根用户/进程所访问，您必须确保向使用 KRB5_KTNAME 环境变量的应用程序提供包含正确主体密钥的自定义 krb5.keytab 文件。

注意：在 Debian squeeze(-lts) 中，默认禁用 KDC 验证支持，以防中断现有的设置。

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

注意：Tenable Network Security 已直接从 DLA 安全公告中提取上述描述块。Tenable 已尝试在不引入其他问题的情况下尽可能进行了自动整理和排版。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - python-kerberos 中的 checkPassword 函数未对其尝试通信的 KDC 进行认证，这允许远程攻击者通过执行中间人攻击造成拒绝服务（错误响应）或产生其他不明影响。 . (CVE-2015-3206)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

據發現，原始修正依預設並未停用 KDC 驗證支援，並且變更了 checkPassowrd() 的簽章。此更新更正了此問題。

此為原始公告的文字：

Martin Prpic 報告，Red Hat Bugzilla (Fedora 錯誤追蹤器) 的 pykerberos 程式碼可能發生攔截式攻擊。上游先前已報告該原始問題 [1]。
我們引用之部分已報告的上游錯誤如下：

在先前的版本中，python-kerberos checkPassword() 方法非常不安全。其過去經常 (且依預設目前仍會) 以 kinit (AS-REQ) 為指定使用者主體的 TGT 要求 KDC，並以密碼是否正確解譯其為成功或失敗。不過，其不會驗證它是否真的與受信任的 KDC 對話：攻擊者可能會簡單回覆，而非以符合他剛剛所提供之密碼的 AS-REP 回覆。

想像您在驗證使用 LDAP 驗證 (而非 Kerberos) 的密碼：您當然會使用 TLS 並搭配 LDAP，以確保您與受信任的真正 LDAP 伺服器對話。此處適用相同需求。kinit 並非密碼驗證服務。

一般方法是以您透過使用者密碼所取得的 TGT，取得驗證器擁有金鑰之主體的票證 (例如，處理使用者名稱/密碼表單登入的 Web 伺服器可能為其自身的 HTTP/host@REALM 主體取得票證)，以便進行驗證。請注意，驗證器必須擁有其自身的 Kerberos 身分，該身分受到 Kerberos 之對稱性的限制 (不過在 LDAP 情況中，使用公開金鑰密碼編譯會允許匿名驗證)。

此版本的 pykerberos 套件為 checkPassword() 方法引入一個新選項。使用 checkPassword() 時，將驗證值設為 True，便會執行 KDC 驗證。您必須提供內含您欲使用之服務的服務主體金鑰之 krb5.keytab 檔案，此設定才能發揮作用。

由於非 root 使用者/處理程序通常無法存取 /etc 中的預設 krb5.keytab 檔案，您必須確保已將內含正確主體金鑰的自訂 krb5.keytab 檔案提供給使用 KRB5_KTNAME 環境變數的應用程式。

注意：在 Debian squeeze(-lts) 中，預設停用 KDC 驗證支援，以免中斷現有設定。

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

注意：Tenable Network Security 已直接從 DLA 安全性公告擷取前置描述區塊。Tenable 已盡量在不造成其他問題的前提下，嘗試自動清理並將其格式化。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - python-kerberos 中的 checkPassword 函式未驗證其嘗試與之通訊的 KDC，進而允許遠端攻擊者透過執行攔截式攻擊來造成拒絕服務 (錯誤回應)，或造成其他不明影響。 (CVE-2015-3206)

請注意，Nessus 依賴供應商報告的套件存在。

ID	名稱	產品	系列	已發布	已更新	嚴重性
174313	FreeBSD : py-kerberos -- DoS and MitM vulnerabilities (2acdf364-9f8d-4aaf-8d1b-867fdfd771c6)	Nessus	FreeBSD Local Security Checks	2023/4/14	2025/2/20	high
174313	FreeBSD : py-kerberos -- DoS および MitM の脆弱性 (2acdf364-9f8d-4aaf-8d1b-867fdfd771c6)	Nessus	FreeBSD Local Security Checks	2023/4/14	2025/2/20	high
84507	Debian DLA-265-2 : pykerberos regression update	Nessus	Debian Local Security Checks	2015/7/6	2021/1/11	high
218886	Linux Distros Unpatched Vulnerability : CVE-2015-3206	Nessus	Misc.	2025/3/4	2025/8/25	high
84507	Debian DLA-265-2：pykerberos のバグ回帰の更新	Nessus	Debian Local Security Checks	2015/7/6	2021/1/11	high
218886	Linux Distros のパッチ未適用の脆弱性: CVE-2015-3206	Nessus	Misc.	2025/3/4	2025/8/25	high
84507	Debian DLA-265-2：pykerberos 回归更新	Nessus	Debian Local Security Checks	2015/7/6	2021/1/11	high
218886	Linux Distros 未修补的漏洞: CVE-2015-3206	Nessus	Misc.	2025/3/4	2025/8/25	high
84507	Debian DLA-265-2：pykerberos 迴歸更新	Nessus	Debian Local Security Checks	2015/7/6	2021/1/11	high
218886	Linux Distros 未修補弱點：CVE-2015-3206	Nessus	Misc.	2025/3/4	2025/8/25	high

偵測

搜尋 Plugin

high

high

high

high

high

high

high

high

high

high