Rails の CVE-2019-5418 は RCE (Remote code execution) です

CVE-2019-5418_is_RCE.md

Rails の CVE-2019-5418 は RCE (Remote code execution) です

前置き

• これは休日に書いた記事で所属している組織とは一切の関係がない。

概要

• CVE-2019-5418 は実際のところ高確率でRCEなのだが File Content Disclosure という聞き慣れない名前で公表されて、CVE-2019-5419 で DoSが出来るという内容になっている
• やあ、脆弱性の開示方法というのは実際に難しい問題だ、広範に使われていて影響範囲が甚大になるようなソフトウェアの脆弱性となると、具体的な攻撃コードを載せるなと言う人が多いのはよく分かる。
• しかしながら、影響範囲についてまでも、不正確な記述がされてしまっている。これは悪い傾向だと自分は思う。これは配慮の結果なのか？ それとも無知の結果か？

前提知識

3/13 に Railsのsecurity updateが出ている。

• https://weblog.rubyonrails.org/2019/3/13/Rails-4-2-5-1-5-1-6-2-have-been-released/

CVE-2019-5418, CVE-2019-5419 の 報告者は github の John Hawthorn となっていて、Railsのアップデートから間を置かずに、github enterpriseの修正版もリリースされている

• https://github.blog/jp/2019-03-14-github-enterprise-server-vulnerabilities-response-patches-released/

同じタイミングで CVE-2019-5420 も報告されていて、こちらは日本人のななおく氏が報告者になっている。

• https://twitter.com/ooooooo_q/status/1105889191127179264

この脆弱性は実際のところ何なのか？

• CVE-2019-5418 Railsアプリケーションサーバー上の任意のファイルを取得できる。
• CVE-2019-5420 Railsのsecretが漏れると任意コード実行が可能で、開発モードを使っているとsecretを推測することが出来る。だから、開発モード限定での潜在的なRCEというタイトルとなっている

CVE-2019-5418について、一般的には「パストラバーサルでアプリケーション実行権限で読み取り可能な任意のファイルを盗み出すことが出来る」と説明したほうが話が早いだろう。検索して出てくる実証コードでは、もっぱら ../../../../../../../../../../etc/passwd を読み出そうとしている。

/etc/passwd は無害すぎる例で、脅威が正しく伝わっていない。任意のファイルを読み取ることが出来るため、例えば ../../../config/secrets.yml を読み取ることが可能であることを確認した。このファイルには CVE-2019-5420 での攻撃に必要な secret_key_base という変数が書かれている。つまり CVE-2019-5418 が成立する環境においては、CVE-2019-5420の「開発環境限定」という条件が外れて、単に CVE-2019-5420 によるRCEが出来るということになる。

一般にパストラバーサルで意図しないファイルが露出するというのは、そこからもっと悪いことが起きる。Railsのsecurityアナウンスを確認したところ、パストラバーサルでは以下の内容があった。

• CVE-2016-0752 https://groups.google.com/d/msg/rubyonrails-security/335P1DcLG00/OfB9_LhbFQAJ
• CVE-2016-2097 https://groups.google.com/d/msg/rubyonrails-security/ddY6HgqB2z4/we0RasMZIAAJ

unexpected places like outside the application's view directory, and can
possibly escalate this to a remote code execution attack.

CVE-2019-5418 のアナウンスにおいては、なぜかこのような記載がなく、CVE-2019-5419 で 巨大なファイルを読み出すことによる DoS が出来るなどと書かれている。(githubの人が考えた最大の脅威がそれだったのかもしれない)

2019-03-22: 訂正

• DoSの要因を勘違いしていた。後述のペパボの記事に影響を受けた https://tech.pepabo.com/2019/03/18/analysis-rails-vulnerabilities/ もので、オリジナルのアナウンスにはこのような記載は無い。
• これはおそらくヘッダの処理過程で複雑な正規表現を使ったDoSが出来るというもので、任意のファイル出力とは独立してDoSが可能であるため、別のCVEに分けたのだろう。

補足1: ファイル漏洩でsecretが漏洩するかどうか？

Rails5.2 からファイル上のsecretを暗号化して保存するようになった

• https://www.engineyard.com/blog/rails-encrypted-credentials-on-rails-5.2

しかし、これの効果は、もっぱら暗号化につかう key ファイルをgitignoreに入れておくことで間違ってsecretをソースコード上に含めたり公開してしまったりすることを抑止することにあるようだ。ファイルが読み取れるのであれば、暗号化済みの enc ファイルと key ファイルの両方を取得することが出来る。

secretを環境変数に入れるという作法もある。

• しかし、その場合でも linux上であれば /proc/self/environ を読み取ることで環境変数に書かれた secret を読み取ることが出来る
• https://diary.sorah.jp/2014/06/05/securing-environment-variables

補足2: secretが漏洩した場合にどこまで悪いことが起きるのか？

信用できないオブジェクトのデシリアライズでコード実行が可能だというのは、よく知られている

• https://www.owasp.org/index.php/Top_10-2017_A8-Insecure_Deserialization

Railsでは、encrypted cookie based sessionを使った場合のシリアライズ方法を、MarshalからJSONに変更したようだ。互換性のために Marshalもサポートする hybridが用意されている。

• https://railsguides.jp/upgrading_ruby_on_rails.html#cookies%E3%82%B7%E3%83%AA%E3%82%A2%E3%83%A9%E3%82%A4%E3%82%B6

最大の影響範囲は任意コード実行だが、コード実行が出来なくても、暗号化ベースのsession cookieを使っているなら、任意のユーザーのセッションを偽装することは引き続き出来るだろう。また、各種外部サービスのAPI Keyなどを保存しているケースも考えられるので、各アプリケーションの仕様には依存することにはなるが、基本的にはsecretが漏洩すれば最悪レベルの影響が考えられる。

トリアージへの影響

これは自分の個人的な話だが、CVEで流れてくる脆弱性情報や、各種著名どころのOSSの脆弱性情報などは基本的に全部少なくともタイトル程度は目を通すようにしている。自分が CVE-2019-5418, CVE-2019-5419, CVE-2019-5420 を見たときに、これはDoSと開発環境限定でのRCEであって「これはあまり自分の仕事とは関係無さそうだな」と考えて、優先度は低く設定された。(deserialize起因でのRCEだろうというのは一瞬で予測がついた)

Railsをメインで使っているような会社だったら、もちろんもう少し真面目に内容を読むだろう。Slack channelの通知では code execution がキーワードハイライトされるので、自分が優先して内容を確認するのは、CVE-2019-5418 ではなくて、 CVE-2019-5420 のほうだ。

もう少し具体的に影響範囲の精査をしたのは以下の記事が公開されてからになる

• https://tech.pepabo.com/2019/03/18/analysis-rails-vulnerabilities/

さらにいうと、この記事を読んだのは、以下のようなコメント付きで言及があったから。

• "社内共有ならともかく公式アナウンスとかで攻撃手法への言及は敢えて避けてるというのが殆どだと思うのでドヤ顔でこういうのを書くな"
• https://twitter.com/sora_h/status/1108192564002209793

おお、本当なのか？ みんな、実はRCEできるというのを分かってたけど黙ってたのか？ Railsの公式アナウンスの内容で、十分に伝わる人には伝わるのだから、わざわざ攻撃方法を広める必要は無い？

実際、ふだんからRailsを使っているわけではないわたくしなどはすっかり勘違いをして、

• 意図しないコンテンツ露出が起きる脆弱性があったけど
• 影響範囲は 巨大ファイルを出力することによる DoS で
• 開発モードに限定のRemote code executionがあった

というふうに、全然影響を正しく理解していなかったよ。 なぜ、Remote code execution と書いてくれなかったんだ？

誰が気付いていますか？

読む人がちゃんと読めば、CVE-2019-5418 がRCEにつながるということはわかる。

• https://twitter.com/ooooooo_q/status/1106867937321717760
• https://twitter.com/iblueconnection/status/1106304210902093840

逆に、気付いてい無さそうな言及やニュース記事は多い。DoSじゃねえよ。

むすび

自分は、これを読むような読者にとっては文章での解説と実証コードの違いはさほど無く、内容が悪用される可能性についても十分に理解して予見している。対応が出来ていない企業もあるだろうし、誰かに恨まれたりするかもしれないし、下手すると訴えられたり馬鹿な警察に逮捕されたりするかもしれない。

自分は、この文章を公開する意味があると思って書いているが、わざわざ書いていなかったり、言及を避けていたり、書いておいて公開していないようなことも多い。

理由を言語化すると以下のようなことが主な理由になるだろう。

• 自分の関わっている、あるいは間接的に関わっているサービスで、対応が万全ではない状態で公開することが憚られるため
• 公開することで、自分の関わっている、あるいは間接的に関わっているサービスの対応が万全であると、勘違いされることが困るため
• みんな当然に気付いてて、意図的に黙っているのだから口に出すなというコミュニティによる圧力

自分は無法者なので法律や警察のことは実際には気にしていないんだ。だから脆弱性情報について語るときには悪用される可能性も予見して書いているとハッキリ書いておく、嘘をつきたくない。

そんなことよりも自分が気にしているのは、コミュニティによる圧力のことだ。黙っているのは本当に配慮の結果なのか、本当にちゃんと影響は理解されているのか、無知の結果ではないのか、どうやればそれを確認できるのか？

今回の Rails の Advisory は実際に書き方が悪い。最大の影響範囲が Remote code execution であるならば、影響は Remote code execution だと書くべきだ。

---

更新履歴

• 2019-03-22 CVE-2019-5419 について誤解があったので訂正
• 2019-03-21 公開