Apache Log4j 2 で非常に深刻なリモートコード実行の脆弱性が見つかる 69
ストーリー by headless
深刻 部門より
深刻 部門より
Apache Log4j 2 でリモートコード実行の非常に深刻な脆弱性 (CVE-2021-44228) が見つかり、修正版の Log4j 2.15.0 が公開された
(Apache Log4j Security Vulnerabilities、
The Register の記事、
LunaSec のブログ記事、
The Verge の記事)。
この脆弱性はLog4j 2 の JNDI 機能が攻撃者にコントロールされた LDAP やその他の JNDI 関連エンドポイントに対する保護を行わないというもので、Log4j 2.0-beta9 から 2.14.1 までのバージョンが影響を受ける。攻撃者は脆弱性のある Log4j 2 に特定の文字列をログとして記録させることで、LDAP サーバーから任意のコードを読み込んで実行させることが可能だ。この脆弱性を使用するエクスプロイトが既に公開されており、「Log4Shell」などと呼ばれている。
これについて あるAnonymous Coward 曰く、
この脆弱性はLog4j 2 の JNDI 機能が攻撃者にコントロールされた LDAP やその他の JNDI 関連エンドポイントに対する保護を行わないというもので、Log4j 2.0-beta9 から 2.14.1 までのバージョンが影響を受ける。攻撃者は脆弱性のある Log4j 2 に特定の文字列をログとして記録させることで、LDAP サーバーから任意のコードを読み込んで実行させることが可能だ。この脆弱性を使用するエクスプロイトが既に公開されており、「Log4Shell」などと呼ばれている。
これについて あるAnonymous Coward 曰く、
CVSSスコアは驚異の9.8 (スコア:5, 参考になる)
RedHatのCVE-2021-44228ページ [redhat.com]
攻撃元区分: ネットワーク
攻撃条件の複雑さ: 低
必要な特権レベル: 不要
ユーザ関与レベル: 不要
スコープ: 変更なし
機密性への影響: 高
完全性への影響: 高
可用性への影響: 高
うーんヤバい。
log4jでアクセスログとか取ってるサーバーは普通に攻撃条件を満たすから範囲が広すぎる。
まさかアクセスログでインジェクション受けるとは思ってないですよ…。
Re: (スコア:0)
まさかアクセスログでインジェクション受けるとは思ってないですよ…。
ログ爆弾とかゴミ箱爆弾とか
全世紀から想定されていた手法かと
集積や解析の場はターゲットに最適みたいな
忘れた頃に穴が生み出されるものなんですよ
Re:CVSSスコアは驚異の9.8 (スコア:2, おもしろおかしい)
全世紀からとは大きく出たな
Re: (スコア:0)
スラド名物後出し全知全能博士
Re: (スコア:0)
そもそもログライブラリーになぜこんな強力な謎機能が実装されてたんだろう。
と今回のニュースを見て多くの開発者が思ったんではないかと。
log4jを使ったことがあるだけにかなり衝撃的だよ。
他者か提供するライブラリーはソースを読むところから始めないといかんのか！？
Re:CVSSスコアは驚異の9.8 (スコア:2)
オブジェクト指向実行環境ならではの素晴らしいネットワーク透過性の発露ではないですか。クラスファイルがたまたまリモートに存在していてもちゃんと名前を解決してログが取れるんですよ! これはSun Microsystemsに惜しみない👍を送る [impress.co.jp]べきでしょう。
Re: (スコア:0)
どちらかというと🖕を送りたい
Re: (スコア:0)
OSにログ機能が無くてもカバーできるようにする為、という辺りかな？
PC関係だけをターゲットにするなら無くてもいいだろうけど。
Re: (スコア:0)
ソフトウェアから見たログの出し方も、
Javaの実行環境についてもご存知ない？
ログってのは開発言語上で扱う様々な情報を文字列化できると便利に使える物なので、
開発言語に依存しないOS機能がいくらか充実してた所で言語に依存する機能は充実しない。
そしてJavaは一度書いたコードが大きく異なる環境でも動かせるというコンセプトを持っているので、
コンセプトが機能する範囲において「ターゲット」という概念を持ち出すこと自体何かがおかしい。
Re: (スコア:0)
おめーはやってんの？暇だね。
Re: (スコア:0)
あなたが確認していないのなら，他の誰かが確認してくれているから安全性が保たれているわけです。
私もソースレベルでの検証は完全にできているわけではないので，
「暇だね。」じゃなくて「いつもお世話になっております。」と申し上げます。
Re: (スコア:0)
当たり前ならこんな問題になってないし、
log4j使ってるプログラマの1%でもそうしてたとするならこんな脆弱性とっくに見つかってる。
誰かが作った優れた仕組みをインターフェイスだけ見れば使えるというのがソフトウェアの発展の礎そのものだろう。
あんたは当然Linuxもgccも全部ソース読んでるんだよな。
マジリスペクトだわ。
Re: (スコア:0)
知ったかこくのやめたら？
Re: (スコア:0)
ソース読めても安全性まで確認できるのはスーパーなハッカーだけなんだよなあ
Re: (スコア:0)
本来はそうだがソースを見たところでバグを見つけられるわけではない。
貴方が使っているライブラリにだって発見されてない多数のバグが存在しててもおかしくないですよ。
ちゃんと確認しててバグを取り除いた上で使っているのであれば、その証拠（issueやPRなど）を出せば批判コメントは減ると思いますよ？
Re: (スコア:0)
> 証拠
そんな活動してるとすれば
> 当たり前
なんて言う訳がないよね
それがいかに当たり前でないかよく分かってるはずだもの
Re: (スコア:0)
こういうバグを見ると、国家情報機関はとっくに知っていて、
使っているんだろうなと思ってしまう。
シンプル版も出してほしい (スコア:1)
こういった高機能ライブラリでも、ほとんどの人が一部のシンプルな機能しかつかってないのでは？
シンプル版があれば余計な馬具も入りにくい
Re:シンプル版も出してほしい (スコア:1)
標準ライブラリのLoggerでいいんじゃない。
Re:シンプル版も出してほしい (スコア:1)
そういう君だってprintfじゃあ機能が足りないからログライブラリを使うわけだし
そのprintfでさえ複雑すぎでセキュリティホールの原因になるのもありがちな話
Re: (スコア:0)
あなたがフォークして作れば良いのでは？
実際問題、機能を削るのだって手間だしデグレの恐れもある。メンテも本家とは別にしなきゃならない。
誰もやってはくれないと思うよ。
Re: (スコア:0)
確かに馬具は余計というか使わないプロジェクトの方が多そうですね……。
＃お馬のゲームとかもあるのでゼロとは言わない
Re: (スコア:0)
餅は餅屋ということだな
だからログ取りはaspectJでやれと… (スコア:0)
2010年代javaシステムのほぼ100%が深刻なセキュリティホールを持つことになるのか
だからうちのjava部が徹夜作業してるんだな
//年末だからと思ってた
Re: (スコア:0)
> だからうちのjava部が徹夜作業してるんだな
USだとホリデーシーズン入ってんじゃないかな？
みんな休暇取っててやばそう。
Re: (スコア:0)
担当者に連絡が取れなかったのでサービス終了。部署ごとスクラップアンドビルドでまるごと解雇。
Re: (スコア:0)
風の噂ではバージョン2系だけでなく1系も駄目な可能性アリとか。
すいませんが追い切れなかったので、事情分かる方が追記していただければ。
Re:だからログ取りはaspectJでやれと… (スコア:1)
1系は影響ないことが確認取れたみたい
https://github.com/apache/logging-log4j2/pull/608#issuecomment-991387493 [github.com]
Re: (スコア:0)
6年も前にEoLになった1.x [apache.org]を使い続けることをヨシするか否か…
Re: (スコア:0)
いや、15年位サーバリプレースで続いてるプロジェクトに携わっていたので。
当然1系そのまま使ってたのですよ。
同僚の終末が守られて良かったです。
Re: (スコア:0)
同僚の終末が守られて良かったです。
週末でなく終末か・・・安らかな最後をおくれたな＞同僚
合掌。
Re: (スコア:0)
そうやってAspectJしか使ってる認識ないプロジェクトでロギングのバックエンドにLog4jが入ってて大惨事って世界で数件は起こりそうなのが怖い。
Re: (スコア:0)
Log4j2よりLogbackの方がメジャーなはずだから100%ってことはないんじゃないかな
Re:だからログ取りはaspectJでやれと… (スコア:1)
log4j-over-slf4jは影響受けないんだな。API互換だからこれに移行するのもいいかもしれない。Struts2もアレだったがバグは1匹見つけたら20匹はいると思ったほうがいい
Anonymous Coward (スコア:0)
うちはコンテナ隔離してるから大丈夫・・・
ではなくて、外部からダウンロードしたJavaコードを実行されられるので、
情報を盗まれなくても仮想通貨マイニングソフトウェアを動かされたり、DDoSのボットにされたりと
なんでもござれの脆弱性。
大変危険。外部に接続されているシステムで使用している場合は直ちに対処すべきだ。
Re:カウピス (スコア:1)
実際のところ速やかに対処ができないなら、停止しなければならないくらいの問題なんだよなこれ。
Re: (スコア:0)
実際のところ速やかに対処ができないなら、停止しなければならないくらいの問題なんだよなこれ。
巫女召喚フラグですね
Re: (スコア:0)
info.gbiz.go.jp とか止めてるところは止めてるっぽいね
Re: (スコア:0)
サーバというのは外部からの通信は受けても、外部への通信はダメになっているものと思っていたが、そうでもないのだろうか。
Re:Anonymous Coward (スコア:1)
内から出る方はブラックリスト方式というか、デフォルトで全開放じゃね？
ntpとか、ソフトのインストールとかで穴開けるとか作業したことないし。
こういう事でもないと、大概は外固めときゃ問題ないしな。
Re: (スコア:0)
LDAP はまだしも DNS すら通していないのは珍しいのでは
Re: (スコア:0)
外部との通信が一切不可になってるのは珍しいからなー。
ポートスキャンとか疎通確認も内側からできそうだし気付いたら関連会社のサーバを攻撃してましたなんてのもありそう。
Re: (スコア:0)
DNSとかNTPとかは開けます。
さらにセキュリティフィックスのダウンロードに支障がない程度には開けますよ。
必要なケースではそれらに加えてLDAPも。
Re: (スコア:0)
弊社のシステムは閉域網内にDNS/NTPサーバをわざわざ作っていてセキュリティフィックス用のマネージャー
(プロキシ)も一台建てている。
まさにこういうことを想定して外部との通信を極力排するためだったんだな。今やっと理解したよ。
ありがとう、辞めた前任者の人。
Re: (スコア:0)
プロキシのログ定期的に見てあげてね。
見慣れないログがあったら、ヤラれた証拠なので。
30億のデバイスで脆弱性 (スコア:0)
30億のデバイスで脆弱性
cf.「30億のデバイスで動いて客先で動かないJava」
「30億のデバイスで走るJava」
短慮かも知れないが (スコア:0)
普通に考えて、ロギングライブラリとして求められる機能ではないように思うのだが、
開発者にもともと脆弱性を仕込む意図があったのでは無いかと勘ぐってしまうな
Re:短慮かも知れないが (スコア:1)
例えば、
異常検知やユーザーの異常行動の解析のためログの吐く先がDBの場合に、
Appender インタフェースを使った JDBCAppenderがよく使われますが、
そこでJNDIが使われてたりします。
ご参考まで：https://logging.apache.org/log4j/2.x/manual/appenders.html
これに限らず、
サービス化されている機能を介してログや設定を取ったり、ログを吐き出すのに、
JNDIを使うことはまあ一般的です。
といっても、
今回の脆弱性が、URI書式異常時の例外をトラップするもスルーし、
しかも、”This is OK.”とかコメントを書いときながら、
異常URIをそのままJNDI接続処理に回してた、
修正はreturn文を1行追加するだけ、
ってー感じの、
ちょっと恥ずかしくなる類のミスなので、勘繰りたくもなりますよね…。
Re: (スコア:0)
"This is OK."のコードは今回の脆弱性の修正過程で一時的に入ったもので、今回の脆弱性の原因じゃないですよ。
Re: (スコア:0)
こちら [github.io] に詳細な説明がありますが、ログ出力時に動作環境に関する様々な情報を出力したい、という要件から作られたものですから、意図的ではなかったと思いますよ。