xrdp の vnc-any 経路に整数オーバーフローで情報漏えいとクラッシュ

Critical（CVSS 9.1）に分類されるneutrinolabs xrdpの脆弱性です。オープンソースの RDP サーバ xrdp に整数オーバーフローがあり、vnc-any 接続モードで画面更新メッセージを処理する際に発火する。悪意ある VNC サーバが細工した画像サイズを送ると、バッファサイズの計算でオーバーフローが起きて実際より小さい領域しか確保されず、そのあと元の大きいサイズの想定で画像データを処理するため境界外読み取りになる。認証されていないリモートの攻撃者が、ヒープ上の機密情報を読み出すか、プロセスをクラッシュさせてサービス停止に持ち込める。影響を受けるのは 0.10.6 およびそれ以前のすべてで、修正版は 0.10.6.1 である。NVD の CPE も同じ範囲を示す。攻撃の起点が接続先の VNC サーバ側にある点が特徴で、vnc-any モードで繋ぐバックエンドを利用者が指定できる構成では、攻撃者の用意したサーバへ繋がせることが前提になる。CVSS は評価元で割れており、NVD（Primary、nvd@nist.gov）は 3.1 で 9.1 Critical（AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H）、CNA の GitHub（security-advisories@github.com）は 3.1 で 8.2 High（AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:L）としている。差は可用性への影響を高いと見るか低いと見るかだけで、機密性への高い影響という見立ては一致する。CWE は CWE-190。CISA KEV には未収載。NVD の vulnStatus は Analyzed。

判定は 2 段で、まず xrdp の版、次に vnc-any モードを使っているかを見る。版は xrdp --version、あるいは dpkg -l xrdp / rpm -q xrdp で確認し、0.10.6.1 より前ならすべて該当する。次に /etc/xrdp/xrdp.ini を開き、セッションの定義で lib=libvnc.so を使い、ip や port を利用者入力（ask で入力させる形）に任せている vnc-any 系の項目が有効になっているかを確認する。この経路を使っていなければ、当該コードには到達しにくい。見落としやすいのは、開発者が Linux の GUI に入るために立てた踏み台の xrdp、検証用に一度立てて放置されている VM、それとデスクトップ用途のイメージにデフォルトで xrdp が入っているケースである。xrdp は 3389 で待ち受けるため、セキュリティグループの棚卸しで 3389 が開いているホストを起点に探すのが早い。すぐに更新できない場合の緩和は、vnc-any の経路を閉じることである。xrdp.ini から vnc-any のセッション定義を無効化し、接続先の VNC サーバを利用者に指定させる構成をやめて管理下のバックエンドに固定する。加えて 3389 をインターネットに直接晒すのをやめ、VPN や踏み台経由に限定すると、そもそも細工されたやり取りを始められる相手が減る。完了条件は、（1）全ホストの xrdp が 0.10.6.1 以降になっていること、（2）vnc-any で任意の接続先を指定できる設定が残っていないこと、（3）3389 の公開範囲が意図した範囲に収まっていること、の 3 点である。ヒープの内容が読み出せる欠陥なので、公開状態で長く運用していたホストがあるなら、そのセッションで扱っていた資格情報の再発行も検討しておく。

neutrinolabs xrdp を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2026-41521）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。