要約

  • 1985年のFTPは制御用の会話とデータ転送を分け、利用者がPORTでデータ接続先を示せば、二つのサーバーが直接ファイルを受け渡せた。
  • RFC 2577は1999年、この宛先指定でFTPサーバーを無関係なサービスへ接続させる跳ね返り攻撃を説明した。

荷物を倉庫Ａから倉庫Ｂに移すのに、依頼主の家を経由する必要はない。とりわけ家への道が細くて遅ければ、倉庫同士で運んだほうがいい。FTPにはそんな現実的な工夫があった。ただし配送伝票は依頼主が書く。そこに倉庫Ｂではなく、まったく別の建物が記されても運転手が従うなら、話は急に面倒になる。

1985年10月のFTP仕様、RFC 959は、命令を交わす制御接続とファイルを運ぶデータ接続を別にした。利用者は二つのFTPサーバーをそれぞれ操作し、片方を待ち受けさせ、もう片方から直接接続させられる。PORTは通常と異なるデータ接続先を指定する命令だ。仕様には第三者のホストや遠隔のラインプリンターまで登場する。利用者の低速回線をファイルが往復しない利点は大きかった。

この設計で、指示を出す人と実際に接続する機械が分かれた。正当な代理転送なら、PORTに書かれた先はもう一台のFTPサーバーだ。しかし宛先を無条件に受け入れれば、サーバーは別のサービスにも出向く。相手のサービスから見える接続元はFTPサーバーであり、行き先を選んだ利用者は制御接続の向こう側にいる。伝票を書いた手とドアをノックした手が違う。

Steve Bellovinが1994年2月に書いたRFC 1579は、この二本立ての接続をファイアウォールの側から考えた。従来の能動型FTPでは、サーバーが利用者側のポートへ接続しに来るため、パケットフィルターで扱いにくい。BellovinはクライアントにPASVを勧めた。サーバーが待ち受け、クライアントが外向きにデータ接続を始める方法だ。彼はAPSVという案にも触れたが、当時の実装は把握していないと書いた。接続の向きは、管理者がどちらの扉を開けるかという運用の問題になった。

さらに1998年9月のRFC 2428は、IPv6とアドレス変換に対応するためEPRTとEPSVを定めた。EPRTはアドレス体系、ネットワークアドレス、TCPポートを指定する。EPSV ALLを使ったセッションは二者間の転送に限られ、後から三者間転送が必要なら新しいセッションを始める。新しい住所を書けるようになり、二者か三者かも明示できた。だが、サーバーの車を誰の住所へ走らせるかという権限は、自動では決まらない。

1999年5月のRFC 2577は、その穴を跳ね返り攻撃として示した。利用者がPORTに第三の機械のサービスのアドレスとポートを書き、FTPサーバーにデータを送らせる。送り込まれた内容がそのサービスの命令として通用すれば、サーバーが利用者の代わりに接続したことになる。RFCの例は、SMTP命令を含むファイルを使って第三の機械のメールサービスへ到達するものだ。利用者自身はそこに接続しない。配送車だけを借りて、別の建物の玄関に立たせる。

対策には機能上の代金が付く。RFC 2577はTCPの1024未満のポートへのデータ接続を拒み、そのようなPORT要求には504を返す案を示した。1024以上で待つサービスは残る。ファイル権限を適切にすれば、命令を含むファイルを置いて再送させる道をふさげる。PORT自体を無効にすれば三者間転送も失う。多くの普通の転送はPASVでこなせる、と著者たちは述べた。便利な近道を残すか、宛先の自由を削るかは、サーバーを運用する側の判断だ。

FTPの配達員は有能だった。二つの倉庫を直結し、ファイアウォールに合わせて走り方を変え、新しい住所形式も覚えた。1999年に問われたのは能力ではない。依頼主が書いた地図を、車の持ち主がどこまで許可するかだった。