今日の出来事 (Jun, 2018)

展開と解凍...

　久々にと言いますか Twitter の TL で「『展開』か『解凍』か？」のネタを見掛けたのですが， 程度の大小は別として， 昔も今も不定期に この話題で賑わう気がします。 そういえば結論って出たのかしら？ いえ， 出しようがないとは思いますけれど， ルーツや経緯的なものは知りたい気がします。 (笑)

「解凍」が広まった原因として良く LHA が挙げられますけれど， ドキュメントを参照すると一目瞭然なのですが， LHA では そもそも「圧縮」ではなくて「凍結」を使っているのでした。 ただ， 「凍結」だけだと「？」となりそうなので， 殆どの箇所で「凍結（圧縮）」となっていますけれど…。 なので， 「圧縮・解凍」の組み合わせとしては LHA は無実なのです。 (笑) 　PKZIP/PKUNZIP など当時の海外組アーカイバーでも「Freeze」と「Melt」…「凍結・解凍」のパターンが多いですね。 コマンド説明などでも Add (書庫への追加格納) と Extract (書庫からの抽出) なんて表現になっていますから， 「圧縮・解凍」の組み合わせとしてのルーツは， LHA を含めて その方面には存在しないことになります。

といいますか， アーカイバーのドキュメント方面に限っていえば， データーの符号・復号としての「圧縮・伸張」と， 書庫操作としての「格納・抽出」を どうしようもなく区別する必要がありますから， 「圧縮・解凍」の組み合わせにならないのですよね…少なくともドキュメント上では…。 何かあるとすれば， 「圧縮 (compress)」の表現は割と頻繁に登場するのに「伸張 (expand その他)」の表現が省略されて登場しないことかしら？ 　まぁ， 確かに書庫作成時と異なり展開時に「伸張，伸張」と意識することはありませんものね。 (笑)

ちなみに拙作については， UNLHA.DLL の頃が LHA のドキュメントに習って凍結・解凍の表現を使っていたのに対して， UNLHA32.DLL では初期はともかく その後圧縮・展開の表現に統一されています。 「解凍」は「自己解凍書庫」の表現で登場するくらいかしら？ 　そういえば， 「decompress」の訳として使われることがあるように， 「展開」は「伸張」に近い意味を持つ用語なのですが， ノリとしては「extract (抽出)」を付加したハイブリッド的意味で使われることの多い気がします， 少なくとも UNLHA32.DLL のドキュメントにおいては。 (^^;)

　まぁ， 「どちらが正しい」とか考えずに好きな用語を使えば良いのではないかしら？ 「どちらも同じ意味だよ～」と頭の隅に置いておけば十分だと思います。 あとは， 「圧縮＝圧縮して格納」「展開＝抽出して展開 (伸張)」「凍結＝凍結して格納」「解凍＝抽出して解凍」と， どの用語も大抵の場合は 2 つ以上の手順を含んだ意味で使われている点ですね。

Zip Slip...

　今月 6 日， Synk セキュリティチームが書庫の展開処理における脆弱性『Zip Slip』に関する情報を公開しました。 これは， "../../file.bin" といったメンバーを展開することで， ユーザーの意図しない箇所でのファイル上書きが発生， 引いてはシステム改竄にも繋がる…というものです。 要は 14 年前に『窓の杜』での News 記事等をきっかけとして， 広く一般で認知されるに至った『指定外の場所へファイルが展開されてしまう脆弱性』の Web アプリケーション版ですね。

広範に出回っているソースが震源ということで， 修正が行き渡るには時間を要することでしょう。 …というのは置いておいて， 個人的には「え？ こんなネタまだ残っていたの？」というのが正直な印象です。 いえ， 少なくとも国内で使われているものなら， それこそ 14 年前に駆逐されているはずなのです。 (^^;)

　それはともかく， 今回は "../../file.bin" のパターンのみ話題に登っていますが， その脆弱性が発生しているということは， その修正のみで終わりにすると危ないのですよね。 少なくとも以下のような類似のパターンはチェックする必要があるでしょう：

• ".../.../file.bin" ： プラットフォームによっては '.' が 3 つ以上連続しているものも "../" として認識するので， 同様に排除する必要がある。
• "/tmp/file.bin" ： 絶対パス。 ZIP 系のソースでは相対パスへ変換するのが普通。 しかし， "../" の処理が抜けているということは， こちらも危ないと思っておくのが得策。
• "//host/share/file.bin" ： 絶対パスのバリエーションともいえるので， こちらもチェックが必要。 "file:" などで始まるものも同様。 もっとも， Web アプリケーション系なので， こちらは頭から厳しくチェックしていそうではある。
• "Explo<ZWNBS>rer.exe" ： 制御文字。 アーカイバーなどを使用しているユーザーを対象とした表示で騙すものではなく， ここではチェックの甘さを期待してのもの。 処理順などが甘いと ".<ZWNBS>./.<ZWNBS>./file.bin" が "../../file.bin" として通ってしまう。 もっとも， そんな処理系はコマンドだろうがタグだろうが入れ放題で大変なことになっていそうではある。 (^^;)

この辺りで再発するようなら， その開発元は信頼度が一段落ちる…と言えそうですね。 報告されたものしか修正できない…同様のパターンまでは目が届かないということですから。 要は， 例えば 1024 バイトのバッファーオーバーフローの報告を受けた際に， 「1024 バイトのデーターで溢れない」だけの修正しか行わないパターンです。 確かに 1024 バイトでは大丈夫でも， 64 キロバイトのデータを試すと…というやつですね。 (笑)

　あと， ヘッダー周りの脆弱性も…と言いたいところですが， こちらは過去に CVE-2010-0098 が報告されるなどもしていますから， 大丈夫でしょう…多分。 (^^;)