まだ誰も知らない脆弱性／攻撃に備える方法

セキュリティを考えると全ての入力データはアプリケーションがバリデーションすべきで、長さ／形式は厳格にバリデーションすべきです。¹

厳格なバリデーションは開発者が意識／把握していない各種インジェクション脆弱性にも対応できること、インジェクション攻撃が持たらす被害が致命的であることが、その理由です。

適切なバリデーションは最強のセキュリティ対策の１つ²です。強いデータ型は弱いバリデーションの一種ですが、それでもセキュリティ対策として高い評価を得ています。にも関わらず強いバリデーションである厳格なデータバリデーションはコンピューターサイエンティストのセキュリティ専門家³以外にはあまり評価されていないように感じます。

今回は低レベルのライブラリにもコードインジェクション脆弱性のリスクがあること、その対策としてバリデーションが如何に効果的であるか紹介します。

CVE-2017-14952

これはICU バージョン59.1までのICUライブラリに存在する脆弱性です。ICUは広く利用されている文字エンコーディングとロケール処理ライブラリです。

あまり話題になりませんでしたが、2017年の秋に任意コード実行脆弱性として報告されています。

CVSS Severity (version 3.0):
CVSS v3 Base Score: 9.8 Critical
Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (legend)
Impact Score: 5.9
Exploitability Score: 3.9

一言でいうと「文字データで任意コード実行が可能になる」問題⁴です。CVSS Base Scoreで9.8なので攻撃に成功した場合のインパクトが非常に大きいことが解ります。

ICUライブラリを利用されている方なら59.1というバージョンは比較的新しいバージョンで、多くのディストリビューションではこれより古いICUを利用していると知っていると思います。例えば、RHELではこの脆弱性は修正しないとアナウンスしています。攻撃が困難であることがその理由だと思われます。

ダブルフリー脆弱性とは？

同じメモリ領域を2回以上解放してしまうプログラムの問題です。

この問題の修正と思われるパッチ

Index: trunk/icu4c/source/i18n/zonemeta.cpp
===================================================================
--- a/trunk/icu4c/source/i18n/zonemeta.cpp
+++ b/trunk/icu4c/source/i18n/zonemeta.cpp
@@ -691,5 +691,4 @@
                     if (U_FAILURE(status)) {
                         delete mzMappings;
-                        deleteOlsonToMetaMappingEntry(entry);
                         uprv_free(entry);
                         break;

メモリを解放する行が削除されていることから、ダブルフリー問題だと解ります。

この脆弱性を利用して任意コードを実行を行うには、メモリマネージャーが管理するポインタ操作と攻撃用マシン語を保存したメモリ領域とそのアドレスが必要になります。⁵

最近、攻撃者にとって都合が良いCPU脆弱性が見つかりました。誰もが最近よく聞くMeltdownとSpectreです。これらはメモリ内容を不正に読み取る脆弱性で、ダブルフリー問題を攻撃するにはとても都合が良い脆弱性です。攻撃に必要なメモリリーク脆弱性を探さなくても、Meltdown／Spectreが使えれば十分です。⁶

通常、ダブルフリー問題の攻撃は、攻撃に必要なメモリリーク脆弱性も一緒に見つける必要があり、攻撃が困難であることが多いです。Meltdown／Spectreが利用できるとメモリ内容を自由に盗めるので、攻撃可能になります。

対策：文字エンコーディングのバリデーションの効果

コードインジェクション脆弱性のリスクを軽減するには

• 文字エンコーディングのバリデーション

が欠かせません。単純に文字エンコーディングの妥当性を確認するだけで、知っていなくても文字エンコーディング処理の脆弱性を利用したインジェクション攻撃からソフトウェアを守れます。

マシン語のコードインジェクション攻撃に対してはどうでしょうか？

UTF-8だけ、ASCIIの英数字だけでもShell Codeは作れます。しかし、文字エンコーディングバリデーションが無ければ、攻撃者はShell Codeだでなくあらゆるマシン語命令を自由自在に実行できてしまいます。わざわざ自由にマシン語の攻撃コードを書けるようにして、攻撃者を助ける必要は一切ありません。⁷

妥当なUTF-8文字列のShell Code（41バイト）

greuff@pluto:/tmp$ hexdump -C out
00000000  31 d2 90 52 68 6e 2f 73  68 68 2f 2f 62 69 d6 89  |1..Rhn/shh//bi..|
00000010  e3 90 90 52 53 d6 89 e1  90 90 52 58 40 40 40 40  |...RS.....RX@@@@|
00000020  40 40 40 40 40 40 40 cd  80                       |@@@@@@@..|
00000029
greuff@pluto:/tmp$ iconv -f UTF-8 -t UTF-16 out && echo valid!
1Rhn/shh//bi4RSRX@@@@@@@@@@@@valid!

x86のASCIIプリンタブル文字のみのShell Code（28バイト）

 aPjjX4jHf5eOf5W0PZZj0X43P[HH

x86_64のASCII英数字のみのShell Code（111バイト）

 jZTYX4UPXk9AHc49149hJG00X5EB00PXHc1149Hcq01q0Hcq41q4Hcy0Hcq0WZhZUXZX5u7141A0hZGQjX5u49j1A4H3y0XWjXHc9H39XTH394c

工夫をすればASCII英数字だけのShell Codeが書けることが分りました。より複雑なコード実行も工夫次第で書けると考えるべきでしょう。

文字エンコーディングのバリデーションは、マシン語のコードインジェクション攻撃対策としては緩和策以上の効果を期待すべきではないです。

しかし、だからと言って文字エンコーディングバリデーションは無意味ではありません。自動的にマシン語を妥当な文字エンコーディング／文字のみの攻撃コードに変換する仕組みが作られない限り、緩和策として有効に機能します。⁸

文字エンコーディングのバリデーションには重要なセキュリティ上の効果があります。不正な文字エンコーディングだと正しい処理が不可能なので文字エンコーディングバリデーション用のコードが含まれていることが多くあります。

文字エンコーディングバリデーション用のコードがあること自体は良いことのなのですが、アプリレベルでバリデーションしていないと思わぬ誤作動が起きる場合があります。^9 10

文字エンコーディングバリデーションはインジェクション対策用としてのみではなく、アプリケーションが正しく動作することを保証する¹¹為には必要不可欠¹²です。¹³

対策：データのバリデーションの効果

上記のShell Codeから、文字エンコーディングのバリデーションだけではインジェクション攻撃対策としては不十分で、可能な限り厳格なバリデーションでなければバリデーションの意味がなくなってしまうケース、があることが分かります。

• データサイズのバリデーション（できる限り小さく）
• データ形式のバリデーション（できる限り具体的＆限定的）

このような発見しづらい（＆対応しづらい – 少なくともRHELではICUの更新版配布の予定がない）脆弱性のリスクに対応するには、これら2つバリデーションが必須であることが分かります。つまり、

できる限り厳格な入力バリデーションが必要

ということになります。（ISO27000が求める入力データバリデーションがコレです）

• 小さいサイズのデータしか必要ないのに、無制限にデータを受領＆処理するコード
• 商品コード形式が決まっているのに、文字種（英数字）であることしか検証しないコード

こういったコードは、開発者が意図していなくても攻撃者の攻撃を助けるコード、となるリスクがあるコードです。

紹介したShell Code作成の解説を見ると判るように、限定された条件であるため色々と工夫が必要であることが分かります。¹⁴

制限が多ければ多いほど（バリデーションが厳格であればある程）、ライブラリ等に存在する脆弱性を攻撃するために、より多くの工夫が必要になり、条件が合わず任意コード実行攻撃ができなくなる可能性が高くなります。

データバリデーションとビジネスロジックバリデーション

アプリケーションのソースコード検査ではデータとビジネスロジックのバリデーションがそれぞれ必要な部分で行われているかチェックします。

ここでは詳しい解説を省略しますが、データとビジネスロジックのバリデーションは異るバリデーションで、実施する場所が異なります。

データのバリデーション

• 入力データのバリデーションができる限り早い段階で行われているか？（データの正規化／デコード直後）
• 出力データのバリデーションが適切な箇所で行われているか？（エスケープもエスケープが必要ないAPIも使えない場合、バリデーションが必要）

ビジネスロジックのバリデーション

• データのビジネスロジックに対する整合性チェック（例：予約時間が過去の時間でないか？予約が許可される時間か？予約の権限をもっているか？など）

今あるアプリケーションの現状

データのバリデーションでは

• データサイズのバリデーション（できる限り小さく）
• データ形式のバリデーション（できる限り具体的＆限定的、文字エンコーディング検証も含む）

を行うべきです。¹⁵ しかし、残念ながら、ほとんどのアプリケーションはデータバリデーションは無いか、在っても不適切／不十分な物です。Fail Fastの原則¹⁶はエラー処理の一般原則ですが、不正なデータ（そもそもプログラムが正しく処理できないデータ）にこの原則が適用されているアプリケーションはとても少ないです。

まとめ

今回はマシン語のコードをインジェクションして実行させるダブルフリー脆弱性を例に、セキュアコーディングが求める厳格な入力バリデーションの有効性を紹介しました。

「妥当なデータであることを厳格にバリデーションする」とは「ソフトウェアが正しく動作することを保証する」です。そもそもソフトウェアは妥当なデータ（正しく動作できるデータ）でしか、正しく動作しません。

ここではマシン語のインジェクション攻撃を例にしましたが、HTML、JavaScript、SQL、Xpath、XML、LDAPなどあらゆるインジェクション攻撃を防止できます。¹⁷

出力対策は重要ですが、出力対策（一時的に攻撃できない形に変換）”だけ”では問題の先送りをしているだけです。”一時的に攻撃できない形に変換すること”だけに頼るのは明らかに悪手です。そもそも誤作動を起こすような不正なデータは入力処理の時点で完全に廃除するのがセキュアなコードです。

不正なデータを入力処理で廃除する、と解説すると何も考えず反射的に「できない」と思ってしまう人が居ます。この場合、入力データは3種類しかないことを理解していないか

入力データのバリデーションには「データのバリデーション」と「ビジネスロジックのバリデーン」の二種類があり、分けて処理する必要があることを理解していない、が多いようです。¹⁸

大多数のソフトウェアセキュリティ問題はソフトウェアの誤作動¹⁹です。セキュアコーディングが求める厳格な入力バリデーションを

• セキュリティ的には重要ではない、必要ではない

とするのは明らかにセキュアなコード記述を助ける考え方／設計ではありません。攻撃しやすい脆弱なコード作成を支援する考え方／設計であると、この解説から理解できればと願います。

Struts 2がHTTPヘッダーのContent-Lengthで任意コード実行ができてしまった例もあります。妥当な入力でない場合、コンピュータは整数演算でさえ仕組みとして正しく演算できません。文字列データのみでなく全てデータのバリデーションが等しく重要です。

最後に、幾ら頑張って文字データをバリデーションしても、例えばバイナリデータである暗号データ（ユーザーが送信した暗号ファイルの読み込みなど）などがあると、それに攻撃用マシン語を埋め込んで攻撃できてしまう、という可能性は無視できません。高度なセキュリティが必要なアプリケーションの場合、テキスト処理をするプログラムと暗号データ／画像ファイルなどを処理するプログラムは分離する方が良いです。

残念ながらメモリに対するコードインジェクション攻撃を完璧に防止することは、アプリケーションレベルでは難しいです。しかし、RHELのように理解っていて脆弱性を修正していないケースもあります。都合が良いメモリ内容をリークする脆弱性が使えるケースは限られます。このため、”強いバリデーション”は緩和策として十分に機能すると言えるでしょう。