Telnet 脆弱性 CVE-2026-24061:27年前の問題の再発による root アクセス

27 Years old Telnet Vulnerability Enables Attackers to Gain Root Access

2026/02/26 CyberSecurityNews — GNU Inetutils に含まれる telnet daemon (telnetd) に、新たな脆弱性が確認された。注目すべきは、この脆弱性により、27年前のセキュリティ不具合が再燃していることだ。不適切な環境変数サニタイズの悪用により、認証を必要としない root アクセス取得が可能になる。この脆弱性 CVE-2026-24061 は、GNU Inetutils バージョン 2.7 以下に存在する。悪意のクライアントが、 USER 環境変数の値として “-f root” を指定した場合に、リモートからの認証回避が可能となる。

この脆弱性は、セキュリティ研究者である Ron Ben Yizhak により発見/報告された。これを受けるかたちで詳細調査が実施され、現代の telnet 実装において、1999年の脆弱性 CVE-1999-0073 の影響が残存しているかどうかが確認された。この 1999年の脆弱性では、LD_LIBRARY_PATH などの環境変数の注入により、システム・ライブラリの改竄が可能であった。

根本的な問題は、telnetd が “/bin/login” を起動する方法にある。この 2 つのプロセスが root から root へのコンテキストで実行されるため、Linux カーネルは補助ベクター内の AT_SECURE を “0” に設定する。

AT_SECURE は重要な値である。正の値である場合、動的リンカ (ld-linux.so) および glibc は “secure-execution mode” に入る。このモードでは 、LD_LIBRARY_PATH、GCONV_PATH などの危険な環境変数が自動的に破棄または無効化される。

しかし AT_SECURE が “0” の場合には、動的リンカは当該セッションを完全に信頼されたものとして扱う。その結果として、telnet クライアントから渡されたすべての環境変数が無制限に受理される。サニタイズの責任は telnetd 側に委ねられるが、適切に実装されていない。

最近のコミット (4db2f19f) では、unsetenv (“CREDENTIALS_DIRECTORY”) が追加されたが、この修正は不完全である。現在の telnetd は、ブラックリスト方式で有害な変数を遮断しようとしている。接頭辞または完全一致の変数名でフィルタリングする方式であるが、これでは不十分であると、研究者たちは確認している。

攻撃者たちが可能にするのは、GNU gettext 固有の OUTPUT_CHARSET や LANGUAGE などの変数を glibc の GCONV_PATH と一緒に、telnet プロトコル経由で直接注入することである。たとえば、UTF-8 システムに対して ISO-8859-1 を注入し、文字セット不一致を宣言する。これにより gettext は iconv_open() を呼び出せる。

AT_SECURE が “0” であるため、iconv_open() は攻撃者が指定する GCONV_PATH を無条件に参照する。その結果として、任意の gconv-modules ファイルが読み込まれてしまう。さらに攻撃者は、root 権限で任意の共有オブジェクトをロードする。

27年前の telnet 脆弱性の PoC

Justin Swartz による実証では、低権限のローカル・ユーザーが通常の telnet セッション経由で環境変数を注入し、悪意の共有ライブラリ libcash2trash.so をロードした。

“/bin/login” がローカライズされたプロンプト表示を試みる際に、gettext がエクスプロイト・チェーンを起動し、接続が切断される前にペイロードが実行された。その結果、”/bin/sh” が SUID/SGID 権限付きで複製された。

生成されたバイナリは、euid=0 (root) および egid=0 (root) で実行された。それにより、非特権ユーザーに完全な root 権限が付与された。なお、telnetd による認証は実施されておらず、不要であった。

研究者たちは、「telnetd における不適切な環境変数サニタイズとして、単一の CVE に統合することを提案している。CREDENTIALS_DIRECTORY ベクターと動的リンカ回避の両方を包括的に扱う必要がある」と述べている。

推奨される対策は、ブラックリスト方式からの脱却である。OpenSSH の AcceptEnv 方式に倣い、”/bin/login” に渡す安全な環境変数名の、厳格なホワイトリストを構築する必要がある。また、値に対する厳格な入力サニタイズも必須である。これが長期的に信頼できる、唯一の解決策とされる。

遺残として telnet サービスを運用している組織は、直ちに telnetd を無効化すべきである。そして SSH へ移行すべきである。telnet の利用を回避できない場合には、GNU Inetutils の更新および厳格なネットワーク・レベル・アクセス制御を適用する必要がある。ただし、包括的パッチが公開されるまでの暫定措置である。