リモートのSUSE Linux SUSE15ホストには、openSUSE-SU-2021:3647-1のアドバイザリに記載された複数の脆弱性の影響を受けるパッケージがインストールされています。

  - 攻撃者は、ネゴシエートされた SMB1 クライアント接続とその機能をダウングレードする可能性があります。Kerberos 認証は、NT1 方言と拡張セキュリティ (spnego) 機能を使用する SMB2/3 プロトコルまたは SMB1 でのみ可能です。必須の SMB 署名なしで、プロトコルを CORE、COREPLUS/CORE+、LANMAN1 または LANMAN2 のような安全でない古い方言にダウングレードできます。SMB 署名が必要な場合でも、拡張セキュリティ (spnego) がネゴシエートされない場合は、NT1 方言にダウングレードすることが可能です。攻撃者は、Kerberos 認証が必要な場合でも、平文パスワードをネットワーク経由で送信することができます。この問題は、以下のすべてのオプションが明示的に一緒に設定されている場合にのみ可能です : client NTLMv2 auth = no client lanman auth = yes client plaintext auth = yes client min protocol = NT1 # またはそれ以前。現在サポートされているSambaバージョンでは、上記のオプションすべてに異なるデフォルト値があるため、問題が発生する可能性はほとんどありません。Samba 4.5以前では、ntlmv2、ntlm、または lanman の応答を送信するため、デフォルトの構成でも追加の問題がありました。これは、平文のパスワード、lmhash または nthash の値を復元するために、攻撃者がオフライン攻撃をできる可能性があることを意味します。SMB1/ 2/3 接続に Kerberos 認証を要求することは、以下のようなさまざまなツールの「-k」/「--kerberos」または「-k yes」/「--kerberos=yes」コマンドラインオプションで制御できます。smbclient、smbcquotas、smbcacls、net、rpcclient、samba-tool など。
    注意 : 4.15は、「-k /--kerberos*」を廃止し、「--use-kerberos=required」コマンドラインオプションおよび smb.conf オプション client use kerberos = required を導入しました。libsmbclient ベースのアプリケーションの場合、Kerberos の使用は次の関数呼び出しによって制御されます。smbc_setOptionUseKerberos()、smbc_setOptionFallbackAfterKerberos() および smbc_setOptionNoAutoAnonymousLogin()。(CVE-2016-2124)

  - Windows Active Directory (AD) ドメインには、ms-DS-MachineAccountQuota によって制御される、コンピューターアカウントの作成をユーザーに許可する機能がデフォルトであります。さらに、一部の (おそらく信頼される) ユーザーは、Samba ドメインと Windows Active Directory ドメインの両方で新しいユーザーまたはコンピューターを作成する権利を持っています。このようなアカウントを作成するユーザーは、単に作成してパスワードを設定するだけでなく、後で名前を変更する幅広い権限を持っており、唯一の制約は AD の既存の samAccountName と一致しない可能性だけであるため、これらの機能が悪意のあるユーザーの手に渡ると非常に危険です。AD ドメインメンバーとしての Samba が Kerberos チケットを受け入れる場合、Samba はそこにある情報をローカルの UNIX ユーザー ID (uid) にマッピングする必要があります。これは現在、Active Directory が生成した Kerberos Privileged Attribute Certificate (PAC) のアカウント名、またはチケットのアカウント名 (PAC がない場合) を介して行われます。たとえば、Samba は、フォールバックしてユーザーの user を探す前に、ユーザーの DOMAIN\user を見つけようとします。DOMAIN\user 検索が失敗する可能性がある場合、権限昇格が可能です。これを説明する最も簡単な例は、攻撃者が root という名前のアカウントを作成し (MachineAccountQuota ベースのマシンアカウントの名前を変更する)、Kerberos PAC なしでログインを要求する場合です。チケットを取得してからサーバーに提示するまでの間に、攻撃者はユーザーアカウントの名前を別の名前に変更します。Samba は DOMAIN\root の検索を試みますが、失敗し (これが存在しないため)、ユーザー root の検索にフォールバックします。これは 0 の特権 UNIX uid にマッピングされます。このパッチは、Samba を変更して、PAC (アクティブディレクトリドメインに関連するすべてのシナリオ) を要求し、PAC の SID とアカウント名の値を使用します。これは、組み合わせが同じ時点を表すことを意味します。処理は NTLM ベースのログインの場合と同様になりました。
    SID は一意であり、繰り返されないため、別のユーザーと混同されることはありません。さらに、新しいパラメーターが min domain uid (デフォルト 1000) に追加され、プロセストークンで使用する UNIX uid を取得する方法 (最終的に /etc/passwd または同様のものを読み取る可能性があります) に関係なく、デフォルトでは以下の UNIX uid はありません。この値は受け入れられます。nss_winbind が使用される場合は危険であり、必要ないため (「winbind use default domain = yes」が設定されている場合でも) 、このパッチは「DOMAIN\user」から「user」へのフォールバックも削除します。
    ただし、認証のためだけにアクティブディレクトリドメインに参加するセットアップがありますが、承認は、nss_file、nss_ldap、または類似のものによって提供されるローカルユーザーにドメインアカウントをマッピングすることで、nss_winbind なしで処理されます。注：これらのセットアップは、ユーザーを明示的にマッピングしないと機能しません。これらのセットアップでは、管理者はドメインユーザーをローカルユーザーに明示的にマッピングするために「ユーザー名マップ」または「ユーザー名マップスクリプト」オプションを使用する必要があります。例：user = DOMAIN\user 「username map」または「username map script」に関する詳細は「man 5 smb.conf」を参照してください。また、上記の例では、「\」は「winbindセパレーター」オプションのデフォルト値を参照しています。(CVE-2020-25717)

  - Active Directory ドメインコントローラーとしての Samba は RODC をサポートできます。これは、ドメインで最小限の権限を持つことを意図しています。ただし、Samba または Windows RODC からチケットを受け入れる際に、Samba は msDC-NeverRevealGroup およびmsDS-RevealOnDemandGroup (通常はAllowed RODC Replication Group および Denied RODC Replciation Group ) を通じて、RODC がそのようなチケットを印刷することを承認されていることを確認していませんでした。これにより、RODC が管理者チケットを印刷する可能性があります。(CVE-2020-25718)

  - Active Directoryドメインコントローラーとしての Samba は名前ベースの認証を提供する Kerberos に基づいています。これらの名前は認証に使用されることがよくあります。ただし、Microsoft Windows および Active Direcory は SID ベースです。Linux/Unix の UID と同様に (適切に管理されている場合 )、Windows の SID はグローバルに一意であり、名前の変更を切り抜けます。これらの 2 つの承認スキームの会議で、別のチケットを保持しているときに、サーバーをあるユーザーとして機能させることができます。一度発行された Kerberos チケットは、しばらくの間、多くの場合10時間有効ですが、場合によってはそれより長くなることがあります。Active Directory では、PAC を伝送する場合としない場合があり、ユーザーの SID を保持します。この問題の簡単な例は、Samba の LDAP サーバーに関するものです。require_pac = true が設定されていたため、Kerberos チケットの名前のみを使用するフォールバックが許可されます。(すべての Samba AD サービスは何らかの方法で同じ問題に該当します。LDAP は良い例です ) 。他のユーザーまたはマシンのアカウントを作成する権限を持つ委任された管理者が、チケット発行の時間とプレゼンテーションの時間 (AD DCに戻る ) の間の競合を悪用して、権限の高いアカウントを含む別のアカウントになりすます可能性があります。これにより、ドメイン全体が侵害される可能性があります。
    (CVE-2020-25719)

  - CVE-2020-25717AD Kerberos などの問題を回避するために、サービスを受け入れる Kerberos は、承認を実行するために、ユーザーの一意の、理想的には長期間安定した識別子にアクセスする必要があります。AD PAC はこれを提供しますが、最も有用な情報は NDR エンコードされたバッファに保持されます。これは、これまでのところ、Free Software のみで Samba および FreeIPA や SSSD のような Samba コンポーネントを使用するアプリケーションが PAC をデコードすることを意味します。
    Samba に見られる問題は一意ではないことを認識し、Samba は AD PAC のコンポーネントである UPN_DNS_INFO への拡張を、基本的なポインター処理を使用して解析できる方法で提供するようになりました。これにより、Samba ベースでない将来の Kerberised アプリケーションは、LDAP の objectSID と同じパッキングでユーザーの SID を簡単に取得でき、その後の名前の変更に関係なく、チケットが特定のユーザーを表していると確信できます。これにより、そのような非 Samba アプリケーションは、たとえ同じ文字列名を持っているとしても、 (KDCによるチケット印刷の時間とチケット承認の時間のギャップによる ) 1人の Kerberos ユーザーを別の Kerberos ユーザーと混同することを回避できます。プロトコル展開の脆弱性は、Sambaの CVE-2020-25717で Active Directory に展開された場合に実証されているように、ほとんどのLinux および UNIX アプリケーションが Kerberos チケットからのクライアント名に依存するだけになっています。KDC から見たクライアント名が複数の Kerberos リクエストにわたって攻撃者の制御下にある場合、そのようなアプリケーションは、これらのリクエスト間でクライアント名を相互に関連付けるために、追加の情報を必要とします。完全な管理者のみがユーザーを作成できるディレクトリは問題ではありません。問題は、ユーザー/コンピューターの作成権限が何らかの方法で明示的にまたは ms-DS-MachineAccountQuota を介して委任されている場合です。(CVE-2020-25721)

  - Active Directory ドメインコントローラーとしての Samba は、多数の機密属性を保護し、NT セキュリティ記述子と下層の X.500 Directory Access Protocol (その後　LDAP で表現される ) セキュリティスキーマ制約のインターセクションにトータルで依存する Active Directory のセキュリティモデルをフォローします。Samba AD の一部の属性は機密性が高く、1 つのオブジェクトに適用されますが、他のオブジェクトは保護されます。msDS-AllowedToDelegateTo を設定できるユーザーは、このリストが指し示すサーバー上のドメイン内の任意のユーザーになることができます。同様に、Microsoft Windows が混在するドメインでは、SambaのsidHistory の保護の欠如も同様の問題です。これは、ユーザーを作成または変更する権限を持つユーザー (通常は作成者 ) に制限されますが、他の欠陥により、すべてのユーザーが新しいユーザーオブジェクトを作成できます。最後に、Samba は userPrincipalName と servicePrincipalName の一意性を強制しませんでした。また、検証された SPN 機能を正しく実装していなかったため、マシンアカウントが独自の SPN を安全に設定できました (チェックは簡単にバイパスされ、さらにobjectClass =コンピューターに制限されているはずです ) 。Samba はこの機能を実装しています。これにより、ユーザーを domian に追加する権限があるユーザー間のサービス拒否 (UPN ) またはサービス偽装 (SPN ) が回避されます (上記のポイントを参照 )。このリリースでは、目標は類似していますが、Windows 2012 のフォレストの機能レベルで見つかったものよりも実装の範囲が広い機能が追加されています。(CVE-2020-25722)

  - Samba は DCE/RPCを実装しており、ほとんどの場合、「SMB署名」のような保護とともに、下層の SMB トランスポートにより提供および保護されています。ただし、大きな DCE/RPC リクエストペイロードが交換され、いくつかの断片にフラグメント化される場合もあります。これが信頼できないトランスポートで発生する場合 (例：
    TCP/IP または匿名 SMB クライアントを介して直接 ) 、通常クライアントは、DCE/RPCレイヤーでの明示的な認証によって保護します (例：GSSAPI/Kerberos/NTLMSSP または Netlogon Secure Channel ) 。ヘッダーのポリシーコントロールと後続のフラグメントの間でフラグメント保護のチェックが行われなかったため、攻撃者がリクエスト内の後続のフラグメントを独自のデータで置換し、サーバーの動作を変更する可能性があります。DCE/RPC はすべての Samba サーバーのコアコンポーネントですが、集中的に信頼されているサービスとしての役割を考えると、ドメインコントローラーとしての Samba を最も懸念しています。アクティブディレクトリドメインコントローラーとして、この問題は Samba のバージョン 4.10.0以降に影響を与えます。NT4 クラシックドメインコントローラー、ドメインメンバー、またはスタンドアロンサーバーとして、この問題は Samba バージョン 4.13.0以上に影響します。(CVE-2021-23192)

  - DCE/RPC では、「関連グループ」と呼ばれるメカニズムを介して、複数の接続間でハンドル (リソース状態のクッキー ) を共有することが可能です。これらのハンドルは、sam.ldb データベースへの接続を参照できます。ただし、データベースが正しく共有されている間、ユーザーの認証情報の状態はのみを指しており、その関連グループ内の 1 つの接続が終了すると、データベースは無効な「struct session_info」を指したままになります。ここで最も可能性が高い結果はクラッシュですが、メモリ解放後使用 (Use After Free ) が代わりに別のユーザー状態をポイントさせ、より権限のあるアクセスを許可する可能性があります。(CVE-2021-3738)

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

検出

openSUSE 15 セキュリティ更新：samba および ldb (openSUSE-SU-2021:3647-1 )

high Nessus プラグイン ID 155177

バージョン 1.7