【悲報】Javaのライブラリ「log4j2」に外部からコマンド実行可能な脆弱性が発見されIT業界が阿鼻叫喚 既に悪用コード出回る [413535533]
■ このスレッドは過去ログ倉庫に格納されています
ソース
https://search.yahoo.co.jp/realtime/search?p=log4j2&fr=top_ga1_sa&ei=UTF-8
既にマイクラのサーバなどが攻撃されている模様
SaziumR
@SaziumR
【重要】バニラ、Spigot、Paperなど全Minecraftサーバーでログインに関するライブラリ「log4j2」に任意のリモートコードを実行される重大な脆弱性が発見されました。
既に攻撃が始まっているとのことですので、管理者は今すぐサーバーを止め、最新バージョンにしてください。 マージ後、機能のプルリクエストだした奴がトンズラ
↓
しゃあないからプロジェクト側で面倒見てた
こんなんマージすんなよ >>337
このライブラリじたいも7人くらいしかメンテナいないからな
オプソに有りがちな人不足ってやつ Log4j2の脆弱性を利用したLog4j2の脆弱性を無効化するソフトが出てきて草。Cybereasonは列記としたサイバーセキュリティ会社。
https://github.com/Cybereason/Logout4Shell >>340
ゴミすぎて草
普通にアップデートしろよ この話日本らしくて心温まるわ
https://twitter.com/hasegawayosuke/status/1469888560077897731
@hasegawayosuke
log4jの脆弱性に関して実際に観測された攻撃や様々に難読化された攻撃パターンなどについて、本来であれば広く共有されたほうが脅威の理解や対策に役立つ情報が、日本国内では不正指令電磁的記録に該当するのではないかという懸念から表立っての共有が敬遠される様をいくつも見かけた。
https://twitter.com/5chan_nel (5ch newer account) てかもうそろそろjavaとか言う化石使うのやめたら? >>343
たまたまJavaのライブラリだっただけ
脆弱性の発生の仕組みから考えると他で起きる可能性は十分にある
というかJavaみたいに枯れかけ扱いされてる言語より勢いある言語のほうが多分ヤバい >>342
立件ミンスがワクチン予約サイトのハッキング手段を新聞記事にしやがったからな
あいつら反省しろよ >>344
Javaの成り立ちレベルから現在に至るまでの問題だから
お前が言ってるのは全く関係ない 歴史が長いからこそのバグって感じ
新しい言語で作り直したときに洗練されてってるから新しい言語ほどこういうバグは出ない ElasticがうちはJava Security Manager使ってるから問題ないよというアナウンス出してるのみたとき負けたと思った まああいつらはRMI使っとるから当然と言えば当然なんだけどあれをまともに使えるとかすげえよ >>346
どんだけ認知能力歪んでたらそういうデマを平然とばら撒けるようになるんだ? >>340
これええな。ホワイトハッカーが255^4個のサーバに対して打つだけで治るやん
ああ、でも名前ベースのApacheとか使ってると駄目なのかな。じゃあ全ドメイン Japのプログラマーはレベルが低い
外国ではJavaは時代遅れだと聞いた 海外でもエンプラはJavaが強いし、Googleが妙にJava好き。 >>344
少なくとも無制限に外部からの動的ロードを言語レベルで許す仕様がセキュア重視の今の時代に合ってない >>355
無制限ではないんだな
ちゃんと制限かける仕組みがある
問題は日本国内だと話題にならないだけ 便利だなと思ってと恐ろしい仕組みを提案しちゃう人とレビューで通しちゃう人が居たんだから、そのペアは別の言語なら別のところでやらかすのでは GoogleのJava好きは凄いよね
今回の問題はどちらかというとあまりJavaっぽくない問題の出方というか
設計レベルでそんなところに森羅万象機能盛り込むのがおかしいっていう「お前はPHPerか」みたいな話 「お前はPHPerか」草ww
PHPerもJavaerもピンキリですわ >>356
まあ死ぬほど使いにくいセキュリティマネージャを細心の注意を払って使わないとセキュアにならない
というのがそもそも設計としてヤバいっていうかログごときでそんなセンシティブなの嫌すぎる >>360
根本はそっちだね
なぜロガーごときがパースしてんだよという いま会社で一斉点検してるけど、全員warファイルをガン無視してて草。
まぁ、ここまで気にすると一生終わらんしな。簡易チェックで済ませたい気持ちは分かる。試しに自分で攻撃すりゃいいのに これプロジェクト側でlog4j使ってなくても
内包しているjar側で使ってたらあかんから全部確認しないといかん奴?
だとしたら相当めんどくさいんやが… まあそのへんは人次第でなんとかなるんだよな
悲惨なのはベンダーが提供してるフレームワークやらミドルウェアがlog4j使ってて提供元で対応してくれないとどうにもならない場合 弊社一応アイテーの会社なんやけど、誰も対処できてなくて
「セキュリティベンダーに問い合わせたところ〜だそうです」
「ベンダーが言ってるので〜してください」
「そういう事らしいので〜してください」になってて草生える
これはもうだめかもわからんね >>365
FWで必要最低限以外の通信を全てブロックすりゃあ良いのでは
外部からjavaクラスファイルをダウンロードされなければ大丈夫だと思うんだが >>367
通信要件を誰も把握してなかったりとか…😇
こういう時こそどれだけ真面目に設計してるかが問われるな 「クラスファイルのDLすらできてしまう」であって
クラスファイルをDLしなければ問題ないっていう話ではないのよ
まずロガーのフォーマッタが環境情報を参照できる、つまりDB情報などを参照できてしまう
で、クラスファイルをDLしなくてもそもそもhttpが叩ける時点でGETパラメータとして環境情報を持ち出せるのでhttpアクセスが通ること自体がアウト
なんならhttpをシャットアウトしていても、ホスト名の部分に埋め込めばDNS Lookupとして抜くことも可能だから、DNSすら引けてはいけない
というようなことを踏まえるともうこれ設計の根本がフェイルセーフじゃないってことになる >>107
素人で申し訳ないが{}と+の違いってどういう事? orcaクラウド版とか、大丈夫なの?
あれから漏れたら、洒落にならんだろ Ciscoも製品にこの脆弱性があるって発表しているし、
通信経路上のどこで問題が起こるかわからんぞこれ。 外部のクラスファイルをロードする謎のプラグイン的なことやる仕組みが紛れてる可能性あるからjar内のクラスをgrepするだけじゃ不十分かも知れないな
チェックしたからと言って例のオプション付けるのも忘れずに >>370
log4jには第一引数に{}を書くと第二引数以降の値をパラメータとして埋め込めるという機能がある
で、単なる引数からの参照だけでなく{foobar}のような書き方で様々な環境情報を埋め込めるという(クッソ余計な)機能がある
ここまで前提
log.debug("user-agent={}", userAgent);
↑この書き方だと{}のところに変数userAgentの内容を埋め込むだけ
log.debug("user-agent=" + userAgent);
↑userAgentこれだとuserAgentに{foobar}を書き込むことでインジェクションできてしまう >>372
大後悔時代だよ
丸投げで作らせて後は知らん顔されてるようなサービスが続々死ぬんじゃないか 「もしもし、御社に頼んだプログラムに脆弱性があるんですけど」 クソコードに対処しなきゃならんのだからライブラリ作成は辛いわ >>378
ITゼネコンとかこのレベルの温度感よな
責任逃れのプロかて あと2週間遅く公開してたら阿鼻叫喚だったのにな
クリスマス〜年末年始の時期だし オリンピック期間中とかでもなくてよかったな
4億回の攻撃を防いだ(キリッ)とか言ってる場合じゃなくなってしまう ログをjndiでgrepしてヒットなかった👍
ベンダー的にはパロアルトはセーフ、オラクルweblogicがアウト、オラクルDBはセーフっぽい感じ >>367
実は外部からダウンロードしなくてもこの脆弱性使って攻撃できる 金曜日にjvmオプションについて書いたけど
バージョンが古いとこれもダメかあいたたた ■ このスレッドは過去ログ倉庫に格納されています