アカウント名:
パスワード:
コイツいっつもお漏らししてんな
セーフなやつを教えてくれwマイナーな物はニュースにならないだけで、どの言語、環境でも致命的な問題は常に見つかっているよ。
Javaの場合は言語(SDK/ライブラリ)の問題とVMという実行環境の問題がセットになってますから目立つんでしょうね。
他言語でも、たとえば C/C++であれば glibc の脆弱性が今年はじめに見つかっていますがこれはWin環境(MSコンパイラ)では影響ありませんからC/C++ そのものの脆弱性とは認識されないところがあります。https://www.security-next.com/133636 [security-next.com]
あるいは C# だとVMがある点でJavaと似た感じですが、実行環境の脆弱性は Windows update で勝手に対策してくれてる感あってWindows自体の脆弱性に紛れている感ありますよね・・・。
それだけじゃない。Java製フレームワークって脆弱性を作り込みやすい危うい設計のものが多い印象。例えを単純化すると、ユーザー入力を受け入れる口にそのまま生のSQLを流し込める作りというか。
Struts2が脆弱性連発してSpringに移行する流れがあったけど、SpringもELでgetterにアクセスし放題な構造はまったく同じなのでは? と思っていたら案の定だった。https://www.scutum.jp/information/waf_tech_blog/2022/04/waf-blog-082.html [scutum.jp]
今回はSpringのCVE-2022-22965について、それが12年前の脆弱性が蘇ったものであるという点などについて技術的な解説をしてみました。個人的にはStruts2と同じく、外部からgetterやsetterをかなり自由に呼べてしまうという根本的な設計思想そのものが非常に危険だと考えており、自分や自社の開発でSpringを利用することはありえないと考えています。あるクラスがgetterやsetterで「公開」しているのは基本的にJavaプログラム内のアクセスの話であり、HTTP経由でインターネットの向こう側からプロパティをセットしてくれ、と考えているわけではありません。TomcatのAccessLogValveを開発した人は間違いなくそう考えているだろうと思います。長いJavaの(特にエンタープライズ寄りの)開発の歴史においてJava Beansという概念があり、その流れからこのようなプロパティアクセスがウェブフレームワークに入り込んだのだろうと推測しますが、普通に常識的に冷静に考えてセキュリティ的にあり得ないのではというのが個人的な見解です。
今回はSpringのCVE-2022-22965について、それが12年前の脆弱性が蘇ったものであるという点などについて技術的な解説をしてみました。個人的にはStruts2と同じく、外部からgetterやsetterをかなり自由に呼べてしまうという根本的な設計思想そのものが非常に危険だと考えており、自分や自社の開発でSpringを利用することはありえないと考えています。
あるクラスがgetterやsetterで「公開」しているのは基本的にJavaプログラム内のアクセスの話であり、HTTP経由でインターネットの向こう側からプロパティをセットしてくれ、と考えているわけではありません。TomcatのAccessLogValveを開発した人は間違いなくそう考えているだろうと思います。長いJavaの(特にエンタープライズ寄りの)開発の歴史においてJava Beansという概念があり、その流れからこのようなプロパティアクセスがウェブフレームワークに入り込んだのだろうと推測しますが、普通に常識的に冷静に考えてセキュリティ的にあり得ないのではというのが個人的な見解です。
"Bean" 規約が良くなかった。publci field が開放されてる物であり、getter/setter でアクセス出来る物は隠蔽されてる物、としてFWが設計されていれば getClass() 経由でのアレコレは無かった。
もうちょっと遡るとOOPでカプセル化の過剰なアゲが良く無かった。
con.ecec(“delete“+hoge+...なんてことくらいどの言語の標準APIでもできるでしょ。標準APIというか各言語のDB操作関連APIの仕様か。
.NET Frameworkは更新してくれるが.NETCore以降はしてくれないよ。さらに言えば自己完結型でビルドするとビルドし直さないと修正は反映されない。
（インストールの仕方よっては？）Windows Updateで入ってくるよ最近だとKB5013437(.NET 6)/KB5013354(.NET 5)/KB5013353(.NET Core 3.1)
Windows Updateではなく、Microsoft Updateで入ってくるんじゃないかな 「.NET 5.0」「.NET Core 2.1/3.1」が“Microsoft Update”経由で更新可能に [impress.co.jp]
なお、“Microsoft Update”は“Windows Update”とは異なるので注意。「.NET」「.NET Core」は「.NET Framework」と異なり、Windows OSとは独立した製品だ。そのため、更新プログラムの詳細オプションで［Windows の更新時に他の Microsoft 製品の更新プログラムを受
Javaも自己完結型押しなんだよね。JREの単体配布やめちゃた。
型押しとか言うから自己完結でエンボス加工される革があるのかと思ったじゃないか。
正しくは自己完結型推しだな
今回の件についてはOracleとOpenJDKが自前で実装していたからという点が挙げられる。C#というか.NET Coreだと、OpenSSLかWindows APIを使うので、.NETの脆弱性としてこういうのが出てくる可能性は非常に低い。
もちろん、代わりにOpenSSLの脆弱性の影響を受けるトレードオフ。
MS一社提供だと「実装が仕様です。使う側がチェックしないのが悪い」も出来るし
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
まーたJavaか (スコア:0)
コイツいっつもお漏らししてんな
Re: (スコア:0)
セーフなやつを教えてくれw
マイナーな物はニュースにならないだけで、どの言語、環境でも致命的な問題は常に見つかっているよ。
Re:まーたJavaか (スコア:2)
Javaの場合は言語(SDK/ライブラリ)の問題とVMという実行環境の問題がセットになってますから目立つんでしょうね。
他言語でも、たとえば C/C++であれば glibc の脆弱性が今年はじめに見つかっていますが
これはWin環境(MSコンパイラ)では影響ありませんから
C/C++ そのものの脆弱性とは認識されないところがあります。
https://www.security-next.com/133636 [security-next.com]
あるいは C# だとVMがある点でJavaと似た感じですが、
実行環境の脆弱性は Windows update で勝手に対策してくれてる感あって
Windows自体の脆弱性に紛れている感ありますよね・・・。
Re: (スコア:0)
それだけじゃない。
Java製フレームワークって脆弱性を作り込みやすい危うい設計のものが多い印象。
例えを単純化すると、ユーザー入力を受け入れる口にそのまま生のSQLを流し込める作りというか。
Re:まーたJavaか (スコア:2, 興味深い)
Struts2が脆弱性連発してSpringに移行する流れがあったけど、SpringもELでgetterにアクセスし放題な構造はまったく同じなのでは? と思っていたら案の定だった。
https://www.scutum.jp/information/waf_tech_blog/2022/04/waf-blog-082.html [scutum.jp]
Re: (スコア:0)
"Bean" 規約が良くなかった。
publci field が開放されてる物であり、getter/setter でアクセス出来る物は隠蔽されてる物、
としてFWが設計されていれば getClass() 経由でのアレコレは無かった。
もうちょっと遡るとOOPでカプセル化の過剰なアゲが良く無かった。
Re: (スコア:0)
con.ecec(“delete“+hoge+...なんてことくらいどの言語の標準APIでもできるでしょ。標準APIというか各言語のDB操作関連APIの仕様か。
Re: (スコア:0)
.NET Frameworkは更新してくれるが.NETCore以降はしてくれないよ。
さらに言えば自己完結型でビルドするとビルドし直さないと修正は反映されない。
Re: (スコア:0)
（インストールの仕方よっては？）Windows Updateで入ってくるよ
最近だとKB5013437(.NET 6)/KB5013354(.NET 5)/KB5013353(.NET Core 3.1)
Re: (スコア:0)
Windows Updateではなく、Microsoft Updateで入ってくるんじゃないかな
「.NET 5.0」「.NET Core 2.1/3.1」が“Microsoft Update”経由で更新可能に [impress.co.jp]
Re: (スコア:0)
Javaも自己完結型押しなんだよね。
JREの単体配布やめちゃた。
Re: (スコア:0)
型押しとか言うから自己完結でエンボス加工される革があるのかと思ったじゃないか。
Re: (スコア:0)
正しくは自己完結型推しだな
Re: (スコア:0)
今回の件についてはOracleとOpenJDKが自前で実装していたからという点が挙げられる。C#というか.NET Coreだと、OpenSSLかWindows APIを使うので、.NETの脆弱性としてこういうのが出てくる可能性は非常に低い。
もちろん、代わりにOpenSSLの脆弱性の影響を受けるトレードオフ。
Re: (スコア:0)
MS一社提供だと「実装が仕様です。使う側がチェックしないのが悪い」も出来るし