Rの1.4.0から4.4.0より前のバージョンにあるとされる任意のコードを実行できる可能性があるとされるCVE-2024-27322問題の自分用のメモ。
邦文
「R 1.4.0」から「R 4.4.0」より前のバージョンでは、このRDS形式によりシリアライズされたPromiseクラスのオブジェクトを「eval()」関数で評価・読み込む際、そのオブジェクト内の値が未評価の状態で参照されると、オブジェクト内の式が適切な遅延評価の実行タイミングより前に実行されてしまう問題がある。そのため、悪意あるコードを含むシリアライズファイルを読み込ませることで、そのコードを実行できてしまう可能性がある。
CVE-2024-27322で指摘されているRの安全でないデシリアライズの脆弱性は、データ指向のプログラミング言語に共通して潜む問題とも言えるだろう。シリアライズ機能は利便性が高い反面、データの復元時に悪意あるロジックが紛れ込む危険性を孕んでおり、その対策は容易ではない。
中略
プログラミング言語のシリアライゼーション機能は利便性と安全性のトレードオフになりがちで、仕様上の制約から根本的な解決は難しい側面もある。Rに限らず、データのシリアライズを伴う処理の安全性確保は喫緊の課題と言える。言語仕様の改善と平行して、データのライフサイクル全体を見渡したガバナンスの仕組みを構築していくことが、開発者とユーザー双方に求められていると言えるだろう。
発見者の解説ページ
具体的なCVE-2024-27322についての発見者の詳細な解説は次のページが詳しい。
ここで
This means R packages are vulnerable to the deserialization vulnerability and can, therefore, be used as part of a supply chain attack via package repositories.
とあり、悪意のあるパッケージを介し任意のコードの実行もできる。
Posit社からのコメント
Posit社は次のようなコメントを出している。
CVE-2024-27322 - R-bitrary Code Execution https://support.posit.co/hc/en-us/articles/23170092899607-CVE-2024-27322-R-bitrary-Code-Execution
Use trusted sources for R packages like Posit Package Manager, Posit Public Package Manager, and CRAN.
Rを4.4.0にバージョンアップすることだけでなく、信頼できるソースからのパッケージのインストールをしましょうと書いている。
ところで、前出のhiddenlayerの記事では、CRANリポジトリへのアップロードにはこの地脆弱性チェックは含まれていないとなっているが。最近変わったのだろうか？
その他の脆弱性の指摘
CVE-2024-27322以外にもシリアライゼーションの仕組みをつかって任意のコードを実行できる可能性の指摘がある。詳細は次の通り。
ただ、この方法についてはバグというより、仕様ではと思う。ただ一方で、Rのなかみに興味がない場合には注意が必要になると思う。
ここでもある通り、
The big takeaway is (again) to not trust R data files you did not create or know the full provenance of.
とある通り、信頼できないソースからのバイナリファイルの実行は避けた法が良いのは、その通り。
R Core Teamからのステートメント
R-projectのブログにあるR Core Teamを代表するとするCVE-2024-27322に対するステートメント
The ability to write malicious code in R does not imply that the language itself is insecure. The base R language is maintained by a select group of high-trust individuals in The R Core Development Team, most of whom have been working on the language for decades.
We reject the idea that there are wider security implications associated with promises or serialization, both of which are core features of the language.
要約すると遅延評価やシリアライゼーションがRのコア部分での脆弱性に直ちにつながるとは言えないという話（だと思う、ややはっきりしない物言いで何を言いたいのかわからなかった）。
個人的な所感
「CVSS 3.1」の基本値で「8.8」となっており、確かに意図しない任意のコードが実行できるので、セキュリティ上の脆弱性になり得るとは思う。ただ、遅延評価とシリアライゼーションの仕組み上は言われてみれば確かにできそうではあると思ったし、Rの1.4.0はリリース日が2001年12月19日なので、20年以上のものなので、やや仕様よりではと思う。脆弱性といえば脆弱性だが......。もちろんこの脆弱性を過小評価するつもりはないが。
ただ、Rの信頼性を確保するうえで、xexeqにあった
Rコミュニティでは安全なシリアライゼーション手法の確立と普及が急務となるだろう。現在主流のRDS形式に代わる、デシリアライズ時の副作用を排除した新たなフォーマットの策定も検討に値する。加えて、シリアライズデータの完全性検証を自動化するツールの開発や、静的解析による危険なパターンの検出など、開発者を支援する仕組み作りも欠かせない。一方でRを利用する組織には、適切なデータ管理体制の整備とセキュアコーディングの徹底が求められる。
というのは一考されても良いとは思う。しかし、R 4.4.0のNEWSにCVE-2024-27322についての記載が見つけられなかったという点と、R Core Teamのステートメントを見るとあまりそういう方向にはいかなそうかなと思う。
そもそもCVE-2024-27322についてR 4.4.0で修正されたのでNEWSに記載がないのはややユーザー側の不信感につながると思う（記載があったら教えてほしい）。R Core Team的にもそれ仕様じゃない？まぁ問題があるなら直すけど、などと思っているのではないかと思ったりする（真意は不明）。
ところで、その他の脆弱性の指摘として上げたものは個人的には仕様では。と思わなくもない。確かに、よく知らないバイナリファイルを実行するとよくないよというのはその通りなのだが……。
いずれにせよ、信頼できないソースからのパッケージやバイナリファイルの実行は慎重になったほうが良いのは従来どおり。ユーザーとしては特段の理由（研究中でRのバージョン固定中など）がなければ最新バージョンのRを追いかけてパッケージも精査して使っていく必要があると思う。
