リモートホストにインストールされている FreeBSD のバージョンは、テスト済みバージョンより前です。したがって、55fbe7b1-a0fe-11f1-ae1f-bc241121aa0a のアドバイザリに記載されている脆弱性の影響を受けます。

    FreeBSD 15.0では、ユーザーの認証情報を表現するために使用されるカーネル構造が変更されました。以前は、プライマリグループ ID は補助グループ ID のリストを含む配列の最初の要素に保存されていましたが、現在はプライマリグループ ID は専用フィールドに保存されています。この変更は、大部分がカーネル内部で行われ、ユーザーには見えません。
    1 つの関数である group_is_primary() は、この移行の一部として適切に更新されませんでした。この関数は、移行ルールを適用した後、認証情報のプライマリグループ ID を決定するために mac_do が使用します。ルールターゲットがグループを明示的に指定しない場合に使用されます。
    結果として、特定のmac_doルールにより、認証情報の切り替えが、プライマリグループ ID を、元の認証情報の補助グループ配列の最初の要素に保存されている ID に不適切に設定する可能性があります。補助グループのリストが空の場合、この値はホイールグループに対応する 0 になります。
              たとえば、プロセスがもともとグループ 0 に属していなくても、uid=1001>uid=1002 などのルールを悪用してプライマリグループ ID を 0 に設定できます。
    特定のmac_doルールが悪用され、プロセスのグループ ID が 0 に設定される可能性があります。ただし、バグを発生させるには、ルールが呼び出し元に適用されている必要があります。例えば、ルールセット uid=1001>uid=1002 の場合、バグを発生させるには、ユーザーはユーザー ID 1001 を持っている必要があります。
    さらに、ログイン済みユーザーは一般に空でない補助グループリストを持ちます。この場合、最悪の場合、バグを利用して認証情報の最初の補助グループ ID をプライマリグループ ID として設定する可能性があります。
              プロセスは、バグを悪用してプライマリグループ ID として 0 を設定するため、権限のある setgroups(2) システムコールを使用して、すべての補助グループから自身を明示的に削除する必要があります。
    グループ 0 のメンバーシップは、制御された権限昇格を有効にするためにしばしば使用されるため、システム構成によっては、このバグをさらに悪用して、root 権限を取得する可能性があります。たとえば、次のようなルールセットが、空の補助グループリストを持つユーザー 1001 として実行しているプロセスによって悪用される可能性があります。
              uid=1001>uid=1002;gid=0>uid=0です。

Tenable は、前述の記述ブロックを FreeBSD セキュリティアドバイザリから直接抽出しています。

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

検出

FreeBSD:FreeBSD -- 認証されていない認証情報の切り替え(55fbe7b1-a0fe-11f1-ae1f-bc241121aa0a)

medium Nessus プラグイン ID 340055

依存が見つかりません