Rackの脆弱性対応を! (CVE-2022-44570,CVE-2022-44571,CVE-2022-44572)

2023年1月18日にRuby on Railsの脆弱性^[1]とは別にRackの脆弱性が公表されました。

https://discuss.rubyonrails.org/t/cve-2022-44570-possible-denial-of-service-vulnerability-in-racks-range-header-parsing/82125

https://discuss.rubyonrails.org/t/cve-2022-44571-possible-denial-of-service-vulnerability-in-rack-content-disposition-parsing/82126

https://discuss.rubyonrails.org/t/cve-2022-44572-possible-denial-of-service-vulnerability-in-racks-rfc2183-boundary-parsing/82124

どれもReDoSの問題であり、CVE-2022-44571とCVE-2022-44572は以下の特徴により危険性がとても高いです。

• multipartの解析部分での問題であり、数MBの文字列を攻撃に利用可能
• RailsがHTTPリクエストを受け付けた際に呼び出される
• 呼び出しの際に認証が不要
• 殆どのRailsサーバが影響を受ける

CVE-2022-44572は短い文字列で攻撃可能でPoCでは326byteの文字列で0.3秒の実行時間、416byteで22秒でした。1MBを超える文字列が攻撃として送信された場合の実行時間は1日以上になることが予想されます。

Rackのバージョンを2.0.9.2, 2.1.4.2, 2.2.6.2, 3.0.4.1のいずれかに更新することで解決します。^[2]

---

補足

Rubyを3.2.0に更新していた場合は、CVE-2022-44571はReDoSにならないのですが、CVE-2022-44572ではReDoSが発生します。Regexp.timeoutが設定されている場合は設定値でエラーが発生するので影響は緩和されます。(https://zenn.dev/ooooooo_q/articles/ruby_3_2_redos)

Unicornをサーバとして利用している場合はUnicornのタイムアウトが発生します。応答しない状態が続いてた場合にインフラ側で自動対応するようにしていることもあるかもしれません。どちらの場合も緩和策として有効ですが、攻撃側がworker数を超えるリクエストを送り続けている場合はサーバとしては応答しにくい状況が続きます。

GitHub Advisory DatabaseではSeverityが low と設定されていますが、過去の脆弱性で影響範囲が全く同じものであるCVE-2022-30122では High と設定されています。(https://github.com/advisories/GHSA-rqv2-275x-2jq5, https://github.com/advisories/GHSA-hxqx-xwvh-44m2)

脚注

1. https://rubyonrails.org/2023/1/17/Rails-Versions-6-0-6-1-6-1-7-1-7-0-4-1-have-been-released

2. 2.2.6.1にはCVE-2022-44570の修正が含まれていない https://github.com/rack/rack/blob/v2.2.6.2/CHANGELOG.md