【悲報】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」に任意のリモートコードを実行される重大な脆弱性が発見されました。
既に攻撃が始まっているとのことですので、管理者は今すぐサーバーを止め、最新バージョンにしてください。 で、バカジャップはどれくらい苦しんでるの？
もっと具体的なバカジャップの悲鳴を見せてくれよ、バカジャップが苦しんでる姿で俺の優雅な昼下がりは始まるのだ ソースの意味は理解できないのに>>5みたいな奴ばかり増えたな PGl辞めて久しいがlog4jってなんか覚えてるわ
あらたしかただのログ出力ユーティリティ
だったと思うが
なんでそんなことが出来るんだ ログインに関するライブラリではなく、ログ出力に関するライブラリじゃね? 弊社だとlog4net使ってるわ
こっちは大丈夫だろうな >>9
任意のタイミングでログをアウトプットするとか？ 今知ったけどlog4jにリモートからってどういう意味だ ログとして記録してる入力を評価しちゃう恐ろしい仕組みらしいぞ >>11
当たり前な話だが最近古いやつで脆弱性報告されてたと思う >>14
大抵はログインするときにログを出力するだろ
このときに細工をしたパラメータを使うと
ログを出力するついでにコマンド実行できるとかそういう感じ >>15
なるほど
例えばリモートアドレスをログとってるところにsudo-kill-abe.comからアクセスすると実行されちゃうとかそんな感じか >>20
なるほどIDくらいなら出すかもね
で、
>>22 にuser-agentを例にしてて確かにと思った
しかしjava8以降はともかく古いjavaだと現時点では対処のしようがないように見受けられる、ということがさっき調べてわかったこと >>24
アップデートできない環境だととりあえず緊急対処方法としては全てのwebからの入力を受けてlog出力している箇所をコメントアウトするしか無いのでは・・
使用状況によっては地獄だなw これ別に影響ないやろ
インターネットに公開してるサービスにしてもホストからのアウトバウンド先はFWで制限しとるから適当なサーバーのclassファイル読みにいくことないやろし
まあえらい人がlog4j使ってないだろうな！とか言い出して来週から総点検始まるんやろけど
1 問題は1.x系未だに使ってる奴らやな自力の検証で2.15にアップデートせなアカン
あとはmavenで適当にjar引っ張ってきてwar作ってコンテナとか言ってる奴らは地獄やろな
作ったアプリで使ってなくても組み込んだjarがどこで使ってるのか検討もつかんわ >>9
rtaでいきなりエンディング呼び出したりしてるだろ？
あれがなんでもできる >>9
そのへんのまだ対策してないマイクラサーバー立ててるヤツは「cmd /c rd /s /q c:\」を食らう 1.x系使ってるけど影響有無もわからんし
対応するとしてもjavaのバージョン上げないと使えないしで大変だこれ こういうこというてる人もおるけど今のITゼネコンは今回みたいなことキャッチアップする部署置いとるからアンテナ張ってないはウソやな
後段の人おらん云々はありえると思うけど
https://i.imgur.com/p4W7HDL.jpg >>32
JNDIが余計なとこに繋いで変なもの貰わないようにFW設定しとけば良いんじゃねーの 懐かしいなlog4j、昔のプロジェクトで使ってたわ >>34
こういうのキャッチアップする部署はワークアラウンドはこうですとか根本対策はアップデートしましょうとかいう一般的な話しをするだけで手は動かさんからみずほ病みたいに黙ってることはないけど、末端のプロジェクト担当者は悪夢やな
いついつまでに報告あげて更新計画立てて客と交渉して承認もらって実施とかどれだけ書類整備しないといけないのやら jvmオプションで逃げられるかしら
-Dlog4j2.formatMsgNoLookups=true >>39
当座はそれだね
えらい人にはとっては脆弱性のあるライブラリを使ってるのがダメってことになるから更新作業は生まれるけど これTwitterでも大騒ぎになってたな
対応できないプロダクトも多いだろうし、世界的にヤバいインシデント激増するんじゃないか？ >>41
簡単な文をログに吐かせると評価されて即リバースシェル開かれるから
ユーザーが入力した内容をログに残す奴は完全にアウトなんだよな
マイクラよりヤバいのがいくらでもありそう log4jのバグとかウケる
java使ったシステムなら大半がログのために利用してるはずやろ あーこれはインパクトありそうだなー
今の案件も使ってたはずだ とりあえずjavaのオプションで延命はできそうだな プログラムしらんけどバグって撲滅できないのか
法規制してもむり？ 今時java使ってる奴とか情弱すぎるだろ
100歩譲ってPHP7以上だろ 隠されたApachのセキュリティホールってどんくらいあるんだろう
裏のハッカーコミュニティ見てみたいわ その任意のリモートコードでどんなことできちゃうの？
サーバーの初期化とか？ Http.sysとHeartBleedも結構ヒヤヒヤ来たがこれは不味いな 1系は2系の中にブリッジがあるからしれっと2系に変えても大丈夫じゃね？ Log4Jにパラメータ渡す前にサニタイズしてれば防げないの？ >>60
これ専用のサニタイズじゃないと防げない
エスケープして他の処理に読ませるとかそういう話じゃなく
ただのログの本文を評価しにかかるっていうとんでもない穴だから >>61
じゃあ1系でこまってるやつらは
それようのサニタイズをログクラスに書けば回避はできるのか
ありがとう classファイルをネットワークで読み込んで実行されるとかなんで今まで発覚しなかったんだレベル というかをよりこれ機能にしかみえないんだけど一体どういう用途を想定してこんな機能入れたんだ？ しかもこれ、該当文字列が部分一致でも引っかかるのか？
もう絶望的じゃん "${x:0.0}"で数値をフォーマットするみないな構文に
あれもこれもと機能増やしまくった結果だろこれ 自分だけのサーバならともかく他社サーバについての対処なんてどうするかすぐ決まんねーな 1系はjmsappender使ってなきゃセーフっぽいな？
メッセージングなんかしてないからセーフやも >>56
任意のコードってことはなんでもできる、情報抜き出しからファイルまるごと破壊まで >>43
いうてJavaのちょうどいい代替ある？
C#か？ >>72
ない
ｃ＃なんてやめたほうがいい
Javaでええわ >>71
1系のみの話ね
1はJMSAppenderでしかJNDIを触らない＝JMSAppenderを使ってれば影響を受ける
→使ってなきゃセーフ…なのかなぁ？
https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126 プログラマだけど、分かんないな、影響あるの？？？
今時javaで動いてる身近な何かなんてある？ これって外部に公開してないサーバーならひとまず大丈夫か？ log4jをルートから検索するとオラクルとか富士通の電源管理ソフトとかわらわらヒットするンだわ😩
幸いインターネッツ出れるサーバでは自前の認証アプリだけしか見つからなかったが >>50
そうなの？でも製造物はミスがあったら賠償責任あるよね？プログラムもミスがあったら賠償にはならないの？ awsのamazon linuxには影響ないやろ？
教えてくれや >>78
だから瑕疵担保責任の期限を決めて契約するんだよね
瑕疵担保期限すぎてるとことか相手にされないんだろな こういうスレが伸びないように5chの知の低下が著しい
興味あるのはちんこまんこばっかか
もう終わりだよこの掲示板 CVSS10.0はヤヴァイ
週明け侵害されてランサム動いてるサーバありそう >>66
そもそも引数がString1個なら自明にプレーンテキストとして処理されなければならないところに
そんな変なフォーマッタを実装したことが根本的な間違いだわ >>78
バグがあったら修正はするけど
大抵正式導入の前に一通り客が動かして
問題ないなか確認するから
賠償まではならない 現場も高齢化が酷いしもうjavaの時代は終わりだよな >>85
やばいよ
アクセスが来た時にUser-Agentをログに出力してるだけで
リモートコード実行可能なセキュリティホールになる
悪用が簡単すぎる上にJava使ってるほとんどありとあらゆるサーバがアウトだから
到底修正が間に合わず年末年始はワーム祭りになるんじゃないかな マイクラサーバなんか
「チャットで駄目な文字列を発言されただけでアウト」とか
「駄目な文字列の付いた武器を目視しただけでアウト」とか
やりたい放題すぎて草生えるやで >>84
log.d("{longlongString}/{veryLongString}",longlongString,veryLongString);
とあった時、デバッグログが無効の時は重い文字を作る処理をスキップして高速化するぜ！ってのが意図としてあったんだと思う
言語機能で
log.d(longlongString+"/"+veryLongString);
と書かれると、仮にログが無効の時にも文字の作成が動くからな。
しかし、もう今どきそこまでシビアに思う必要も無いよなあ 積極的にログを流している環境ほど発動の可能性が上がるのがもう目も当てられない。 よくわからんのだけど、ログにclassファイルのURLが書かれてるとそれをダウンロードして実行するようになってんの？ 日本は奴隷が年末年始働くけどクリスマス休暇入ってる欧米はヤバそう >>90
そんな機能をString引数1個のデフォルトで使われる関数名に割り当てるんじゃねえと
せめてdebug(String str)とdebugf(String str, ...)みたいに分かれてたらこんなことになってないんだよなぁ
フォーマッタが通るようなものは必ず明示的に区別が付くようにしとけって開発者はママに教わらなかったのか >>94
メソッドが別になるか、オプトインで有効化 デフォルト状態だと無効 にはなるなかあ >>96
今更仕様変えられないから場当たり的にリモートアクセスできるタグだけオプションで無効にできるようにするらしい
根本的に引数がString1個の時にフォーマッタが走る機能が全く要らない(百歩譲っても引数2個からで良い)ので
この設計考えた奴が度しがたいアホとしか言いようがない >>97
https://github.com/apache/logging-log4j2/pull/608/files?w=1#diff-383a85e5abe92b157269bb6a82cdc16540970e31a9e9d0180c0211d44ae28bd1R120
差分見てると、URLのドメインを見てローカルなら許可ってやってるみたいだけど
ローカルの定義がlocalhostと127.0.0.1でベタ書きだし、Inet4Address.getLocalHostの結果を"\\s*/\\s*"でsplitしてローカルホストのホワイトリストに追加してるし
これまた事故るだろうなあ >>99
機能を丸々殺すフラグと引数1個の時にフォーマッタをそもそも走らせないモードの二つを追加すべきだと思う… Log4j2からLookupなんて機能が導入されてたのか
文字列だけで出来るようにしすぎだな。 ひとまずWAF入れてて対応済の定義に更新するか、FWで外向きの通信をきちんと絞ってれば大丈夫に見える。
後日でもライブラリをバージョンアップして対応するのは当たり前だけど。 最近ITの勉強始めたけどお前らが何言ってるかぜーんぜんわからん
Webアプリケーションの勉強したら分かるようになるのか？ >>102
該当するプロジェクト2個だけのザッコワイもさっきまで確認してたし、ガッツリなエンジニアこの土日は無いやろな ソース追加
https://ezoeryou.github.io/blog/article/2021-12-10-log4j.html
https://news.ycombinator.com/item?id=29507357
ハッカーニュース見ると
log.debug("user-agent={}", userAgent);// これはOK
log.debug("user-agent=" + userAgent);//これが脆弱性が発動
らしい。
ちゃんと教科書どおり、変数を全部{}で入れておけば脆弱性が発動する事は無かった
というのがまたいやらしい >>74
一系はそれ、2系はコンソールアペンダでも、ファイルアペンダでもだめw >>107
SQLインジェクション対策みたいにちゃんとバインドしてたら問題なしなのか ユーザーが文字列を設定可能な項目をログ出力してるとアウトってヤバすぎワロタ でも実際ログって組み立て済みの文字列を出力する関数から取り込むみたいなこと頻発するから
結局「普通に」使うために
log.debug("{}", str);
というクソみたいなイディオムを使う羽目になってやっぱこの機能誰も得してないし
debugfみたいな名前の別関数を用意すべきだったとしか言いようがない 要するにlog4jとやらの仕組みでは文字列を単なる文字列として扱わず特定の場合に変数扱いしてしまうからそこを悪用されてコードを実行されてしまうということ？
なんか誰でも思いつきそうなんだけどなんでそんな仕組みを放置してるのかな メッセージをユーザーがコールバック的に設定できるようにしようと思ってたのだろうか メッセージをアペンダー別に出力先を切りかえれる先進的な可能を初めて持ったのがlog4j
1系から2系になるときに開発者が喧嘩わかしたはずだけど、今回はメッセージをLDAPからの情報を取り出して出力するところがやらかした
Javaはrmi通信といいデシリアライズする箇所にこの手バグが多い >>107
これひょっとして
log.debug(e)
みたいなことして雑に例外エラー取ってて、そのエラー文の中の一部に攻撃者のパラメータが仕込まれててもアウトなの？
それだと影響受けるの結構出てくるんじゃね？ 任意のリモートのLDAPサーバーからjava classファイルをダウンロードして読み込めるとかヤバすぎて笑う こういう時にやばいから、みんなプログラムはrootで動かすなというのか 単純にUNIXの欠陥。
コマンドにアクセス出来ること自体がおかしい。 こういうスレ伸びなくなったな
馬鹿ばかりになったということか あれ1系はjmsappenderとかいうの使ってる場合だけだよね >>122
そんなことせんでも
log.info("User-Agent:" + userAgent);
これでめでたく死亡だぞ >>80
瑕疵補償を永久にすればよいのでは？
>>86
想定していない動作まで客側でチェックできなくない？ >>132 より >>122 みたいなのが実アプリでは多いと思うけどな >>134
永久に毎年保守費用として金を払うのなら大丈夫だと思うよ
AmazonやAppleまで踏んでるバグだからこれをもって開発側の重過失を問うことはまず無理 javaってもうAndroidでしか使われてないと思ってた うちのslf4jの実体に何が詰まってるか見といてやるか…
誰か簡単な再現手順まとめといて log4Jでスーパーハカーごっこし放題だな
マイクラや会員制サービスで個人情報抜くスクリプトとか横行してもおかしくない ＋連結は速度的にも悪なのに＋以外の書き方がいつまで経っても煩雑なままのJavaの文法にも問題がある urlのクエリーパラメーターとかにコードをつけてアクセスすると、そのurlをログに記録するときにコード部分が評価されて任意のコマンドを実行できるってことかな？
なんでロギングライブラリーでそんなこと可能なのか不思議だが、そういう作りになってるんだろうな >>141
Webサーバでは余裕で現役
上で貼ったURL見れば分かるけどAppleやAmazonやTwitterからBaiduまで中身はバキバキにJava
>>144
ぶっちゃけ最近のVMは早いから+連結くらいならほぼノーペナで可能だよ
てか処理そのものは"User-Agent: {}"をパースさせる方式の方が遅いから
ログレベルが低くてdebugログを出さなくていい時にログ組み立て処理をスキップできることが本来の目的
だから絶対吐くinfoとかならベタ連結安定になっちゃう 今日対応してた。しかしそもそもlogbackしか使ってなかった。依存先が使ってる可能性も考慮して全クラス列挙したけどなかったわ
しかしこんなイケてる機能仕込んじゃう人って何者なの？ >>148
俺も今やってる案件はlogbackなんだけど担当者が退社したまま漫然稼働してるレガシー案件を洗わなきゃいけないンゴ
ワームでも作られた日にゃほとんどアクセスのない塩漬けサイトでも食われるからなぁ 修正自体は数が多くてめんどくさいけど単純なもんだし
バリバリ稼働してるサービスよりも保守がほとんど行われてない個人とか塩漬けサイトで起こる被害の方がデカそうだな >>150
ワーム作られたらIISのCode Redの再来だと思う
というかもうこれ確実にワーム作られるだろ… 1.xに関してはlog4j.propertiesで明示的にJMSAddapterを使ってなければセーフってことでええんかのう
明示的に設定してないけど{foobar}の書き方によっては呼ばれるとかだといよいよ死ぬんだけど SQLインジェクションされてないかログ取って確認してたらログにインジェクションされたでござるの巻 要は適当に使うとエスケープ処理ができてないままになるから危険ってことでおｋ？
だとしたら根本的にはSQLインジェクションと似てるから、気づいてたハッカーいてすでにだいぶ悪用されてそうではある しかし直でJavaにアクセスログ取らせるとかするか？ ログでJNDI使う人なんてほとんどいないんだから
デフォルトオフの機能にしときゃ良かったのに。 >148
脆弱性なんて犯人捜ししても大して意味ないけどhacker newsではWoonsan Koっていう韓国人コミッタ？の
このパッチが原因って指摘されてんね知らんけど
https://issues.apache.org/jira/browse/LOG4J2-313
ほんの一握りの人が便利だからって潜在的にヤバい機能組み込んでサニタイズとか抜ける
使われないから注意も払われず大事故って永遠に繰り返されてるパターン過ぎる気がする >>159
レビューした上で受け入れてんだからこいつが悪いって話じゃないよ よくわからんのだが何すりゃええんや
どこで何がjavaってのを使ってるのか俺にはわからんぞ Google、Azure、AWSとかのマネージドサービス使ってても影響でる？マネージドサービスの中身でlog4j使ってそう。特にjava実装多そうなredisとかkafkaとかを使ってるマネージドサービス。 >>127
Unixの欠陥では全く無いです。Windowsでも動きます。 あーー、、調査しなくちゃか〜
利用してる外部アプリからの電文もチェックしないとじゃん。。 お前らプロだったんだな
俺はこれ見てもなんのことやらさっぱりだわ… >>134
大抵の場合客側は
チェックしました！(全く動かしてない)
という現場猫パターンが多いから
強く出れない >>162
そこは責任共有モデルでおもったがAWSの責任範囲はlog4jのアップデートだけだなｗｗｗｗ 悪意のある文字列をuser agentに設定して手当たり次第に接続してldapへのアクセスを監視するだけで利用可能なサーバーが簡単にわかるんだな
何というマヌケなセキュリティホールよ >>137
保守と瑕疵は違くない？
>>164
重大な瑕疵があっても？それなら永久補償にしないとおかしくないか
>>167
客は素人の場合もあるんだから仕様通りの動きをするかどうかくらいしかできないくない？ >>171
同じだよ
瑕疵保証契約なんかない、あるのは保守契約だけ
完璧なシステムなんかないし自分で組んだプログラムでもないのに責任なんか持てるわけない
客が素人かどうかなんか関係ない、そういう契約なんだから 受け取ったパラメーターに起因してサーバー内部の情報をエラーログとして返さない処理や予期しない動作をしないように
あらゆる事を想定してプログラム側で排除するのがサーバープログラムには必要だと以前から言われています
日本のプログラム開発に携わっている人達が予見出来ない事こそが一番劣っている部分であると思います >>173
今回の件は世界中で騒がれてるんだけど？ マイクラは結局サーバー建ててないなら問題ないって解釈でいいのか？
Java版インストールしてるんだけど >>175
本丸に丸投げするだけのプログラムしか作成しないプログラマーが基本的にの能なしなんだよ
いつもそうだけど、予め受け取るパラメーターを想定してエラー処理を厳重にしておいたら無視出来た脆弱性ですよねw >>172
完璧なものを作れないなら作っちゃだめだと思うんだけど違う？ >>179
完璧なものなどない
完璧が何をもって完璧といっているのかわからんが、バグのないものを求めたらwindows、iOS含めOS全て使えなくなるけど >>184
だとしたらバグがないOS を一から作り直すしかない気がするけど無理なの？ 「SQLインジェクションの脆弱性」も本丸のサーバープロセスへそのまま丸投げしているから発生するのであって
プログラマーが予見出来る悪用されそうなパラメーターの内容はエラー処理を組み込んでいたら未然に防げるんだから
想像力のなさと知識の未熟さに起因しているんだよな
つまりはその程度の実力でもプログラム開発企業として成り立ってしまっている現状にも問題はあるし、
発注してしまう親企業側の知識にも問題がある >>187
いやそれは理系の人たちの仕事でしょうが... >>191
経営者に実務能力はいらないので知識はないよ バグの無いプログラムを作れって都市伝説かと思ったら本当に言う奴いるんだな というか理系の知識と経験を金で買ってるだけだからこっちは >>195
バグがないOSを一から作り直せる完璧な経営者になれない？ >>197
バグがないOSを一から作れる開発者を集めるのは経営者の仕事じゃない？ >>199
人材担当が無能からバグがないOSを作れないってこと？ 今後総務省がやらかしそうな事
デジタル化に向けて発注依頼したんだけど、とりあえず普通に動いているようなのでこれでいいですかね？と担当者
後々エラー処理などを考慮していないロジックで次から次へと脆弱性の問題が表面化される
我々素人では予見出来ない内容なので仕方がないですよねと担当者
システムの発注依頼をしたのは何の検証能力も持ち合わせていないおまえら担当者だろうよw 責任を取れよな >>200
そもそも地球に優秀な人間があまりにも少ないのかもしれないと最近はおもってる よ〜く考えよう エラー処理ロジックって大事だよぅ
デバッグが大変になるけどきちんと組み込んでおきましょうw よくわからんからFreenet + Frost使うのやめた >>195
金額相応の知識と経験を持った人材が手に入って良かったねw >>207
別に構わんよ儲かってるから
ただバグを無くせない理系にはイラつく >>208
自分でバグのないOSやライブラリを作ればいいんだよ
経営者なんでしょ？
まずは完璧な人材集めからだね >>210
理系が完璧でいればいいだけでこっちまで完璧を求められても困るわほんとに チョンモメンってアホしかいないんだな
来て損したわ >>216
理系が経営者の頭のバグを直せば解決なの？ >>217
勝手にそう思えばいいけど
バグで土日祝日に呼び出されるは不憫ではないのか？ >>220
だよね
だから理系はバグのないソフト作るべきだと思ってるんだけど なんでたかがロギングライブラリにそんな脆弱性があるのか、しかもJavaで プログラムを組むだけならば誰にでも出来ちゃうけど、理に適った膨大なシステム構成を論理的に築き上げるのには相当な知能が必要なんです
あるブラックボックスプロセスに丸投げするのには危険が伴うので、事前にあり得ないようなデータはエラー処理ロジックを通して排除してしまいましょって事です やっぱりその辺に転がってるライブラリなんて信用するもんじゃないよな >>205
エラー処理とかそういうレベルじゃないんだな。正常処理として任意コードを実行できる。
>>226
その理屈だとLinuxもCloudも使えませんが……
最初の方マトモな感じだったのに急にレベル下がってきたな。Java屋さんは今頑張ってんだろうなぁ。お疲れ様です。 >>221
今までに作ったドキュメントが誤字脱字の無く、内容が正しく伝わり誰がみても理解できる文章しか書いてないならその言い分もわかるが
本だって改訂もするしな Appleのこれ好き
if文にちゃんとカッコつけてればね・・・
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail; >>227
そのパラメーターを加工もせずにサーバープロセスが受け取るのに妥当性があるとあなたは思うのですか？
結果的にエラーログが作成されてその内容を実行すると脆弱性を発動する要因が含まれているんだという
外壁でまずは正当性のあるパラメーター内容なのかを検証するのが第一ですが、
間の抜けた企業のWebサーバーではやっていないのに根本的な問題があると思っています 形式的検証を要件定義に盛り込まない情弱どもばかりだからこうなるんだな >>229
うける
Wall Werrorで弾かれるコードがプロダクトに入るの怖
Cはどんな些細な警告も恐ろしくて無視できないわ >>229
あったな
よりによってSSLのバグだっけ？ >>229
何が何でもという強固な意志を感じるなw 今回のこれってバグっていうよりヤバい仕様を意図的に組み込んだものだから形式手法とかでなんとか出来たものじゃなくない？
広義の意味でのバグは人間が関わる限り永久になくならないなって事が身に染みてわかるわ >>231
AppleもAmazonもValveも間の抜けた企業扱いかぁ >>138
ユーザーの入力情報を解釈する上に実行までされるとかあまりにもナンセンスすぎる >>224
つーかJavaってデシリアライゼーションでやらかしまくってるよね
おれには今時リモートのオブジェクトにアクセスしなきゃならん理由がさっぱりわからんわ
信頼できるAPIにアクセスして結果だけもらって検証するんでいいじゃん >>184
権限管理がゆるゆるだから、こうなるんだよ。
メインフレーム系のOSなら起こり用がない。
ガラケーを継承したiOSが比較的安全な程度だ log4jはver1と2でインターフェース違うから初代log4jから放置している場合、そのままjarの入れ替えだけだとビルドも通らないので大変
しかもJava8以降だから古いヴァージョン使っているとそもそも2にアップデートできないという始末
ハマったら面倒くさいことこの上ない >>229
つーかgoto使うんだな
iosクラスなら使わないイメージあった >>229
多重かっこのミスかと思ったらif文何の意味もなくてワロタ 1使ってるぼく、セーフ😁
1はルックアップしないし、
jmsappender使っててもリモートからのデシリアライズなんてことはしないとのこと
Update (2021-12-11 09:09 JST): according to this analysis by @ceki (the author of log4j 1.x), Log4j 1.x is not impacted, since it does not have lookups, and the JMS Appender only loads Strings from the remote server, not serialized objects.
https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126
>>232
形式検証できる言語ってCoqとかAgdaとかF*とかIdrisくらいじゃね？ 悪用コードどころか脆弱性狙ったリスエストがビュンビュン飛び交っとるぞ >>151
ログみたら怪しいリクエスト大量に来てたぞ
もう始まってるかもしれん これ人類史上最悪の被害もたらす脆弱性かもしれないね
Javaのapacheライブラリすらこんなクソ脆弱性あるのに
サーバサイドをスクリプト言語で書いてる奴らはなんで平気な顔してられるんだろ
あいつらカジュアルにeval() とか使うだろ
正気じゃないとしか思えない >>231 がシステムを設計すると
「ユーザ名に"jndi"を含めることはできません」
とかエラーメッセージ出して弾くように作るんじゃないのｗ
もしくはjndiをjjnnddiiに置換してサニタイズとかｗ >>250
うちもロードバランサーのログ確認したらjndi:ldap:が入ったリクエスト来てた
このクラスファイル手で落として中身確認してみたくなるけど… 完成したプロジェクトで使用した数多のライブラリの脆弱性を真面目に追跡してる組織がどれほどあるだろうか >>235
おまえの生活の半分はjavaで動いてるぞ池沼 >>253
気味が悪いから確認はしてないけどな俺も
今時鯖物故わすとかそういう徳にならないのはしないと思うから
あるとしたら踏み台やらされる奴か、ビットコイン掘らされる奴か そもそもアクセスログなんてDBに取ってるだろうしテキストにlog4jでuseragentまで吐いてたりするか？ >>229
Pythonみたいにオフサイドルール強制すりゃいいのに
インデントしないアホなんてもういないだろ WAFベンダにも対応依頼もしたし
とりあえずやれることはやったかな〜
ログ確認とかはあえてやらない🤗 こいつのせいで昨日の金曜日阿鼻叫喚だったわ
メンテナ居ない古いシステムも対象で治そうにもビルド通らなくて結局深夜過ぎまでかかったわ 入力をそのままログ出ししてる場合に起きるから
バリデーションとかやってなさそうなバカが作ったウェブサイトとか終わりや >>192
できるかできないかの判断くらいはつかないと経営できないでしょ >>262
でもさ
ログってそういうもんじゃね？
入力にバリデーションかけてもログには生データが記録されてて欲しいのは理解できる ログに出すデータをバリデーションってむしろ斬新だわ
引っ掛かったらログに残さないんか？それとも将来にわたってあらゆる処理系にrceされないことを保証する神サニタイズでも施すか？ 前提からひっくり返されてる話だからなぁ
バリデーションするって言っても今度は言語そのものが絶対に安全な実装になっているか証明しろって話になるでしょ PoC見るとldapってあるけどhttp通信らしいからサーバから出て行くhttp通信を封じれば良くないか？ これのおかげで今日は朝帰りだったは
爆睡して今起きたら、土曜が終わってた >>265
MSも以前IISでチョンボやらかした過去があるんだよなぁ Akamai has deployed updated WAF rules to protect against the new Log4j vulnerability.
ｲｪｲ😁 わざわざ有料化したjavaなんて使う理由もうないよな
c#でいい Log4j2 脆弱性 "Log4Shell" (CVE-2021-44228)
https://www.crowdstrike.com/blog/log4j2-vulnerability-analysis-and-mitigation-recommendations/
渡されたパラメーターの正常性をチェックしているWebサーバーは今回も問題なく運用されているものと思われます
対してプロセスに丸投げロジックで運用しているサーバーはいつでもやられてしまいます
想像性の欠如でしょうね また中身理解できないバカがきたのか
今回は正常なデータで悪さできるからみんな大騒ぎしてるんだが >>282
マウント取られるバカのほうがよくねえよ
業界から永久に退場してほしいね >>276 WEBアプリ用サーバでWindows採用する理由はどんどん無くなってるよ かといってLinuxで.net使うのはあまり現実的でないし
AzureもだんだんLinux推しっぽいし 簡単でもいいから技術的な話はないのか
linux詳しくないからわからんけど
javaからダウンロードした外部のプログラムは実行できるか？とか
javaの中だったら好き放題できるのはわかるけど
ウイルスが全部javaのわけないじゃん
そういう話が聞きたいんだよ 例えばjavaのコードだけでroot権限とられるのかとか
ここまで自由にされたらとられるんだろうけどさ
できるのかできないのか聞きたいわけよ ログ出力のコマンド実行させる時に、他のshellコマンドも実行できるのか 外部にやられまくりのマヌケサーバよりも悪意のある内部者がやらかす方が怖くねえか？w 取れる権限はlog4jが組み込まれてるプロセスまでで、rootは取れないよ。でも外部からダウンロードして実行はできる。
java内だけでも十分怖いでしょ、例えば既存プログラムのDBにアクセスするクラスファイル解析してDBのデータ吸い出したり、再起動後も動くようにコードやcronを細工したりも出来る。そもそもシステムを壊したり止めたり出来るし、踏み台にもなる。 現PJの他チームで使ってるけど今更知った
自チームは一切使ってないけど他チームはがっつり共通で使ってるので対岸の大火になりそうｗｗ
こういう古い不要な機能が未だに残ってるからJavaは嫌なんだ >>291
ジャップは新しいものを導入するのが苦手で大嫌いだからいつまでも古いのを使い続けるのよね
ITの時代には絶対に生きていけない人種 >>291
こういう内容がよくわかってない１００％無能な自称IT土方が多くて怖いわｗ
開発中でソースいじれる段階ならすぐに対処できるのにこんなの >>284
PHP8速いよ ウィンドウズでも動くよ >>1でログインに関するライブラリって書いてあるのウソじゃん
当然ログイン時にも使用はするのだろうが >>285
みんな大騒ぎしてるけどそれはこの欠陥のヤバさより直さなくちゃいけなくて金曜日の午後にめんどくせえという気持ちが強いんだよ
直すこと自体はどうにでもなる
問題になるのはJavaで動いててログ出力にlog4j2使ってるクライアントアプリだな
Minecraftがそれになるんだろうけど
サーバー運営してる人はこの程度のことは気を使うけど、単にクライアントで繋ぐだけの人はまずそう
チャットメッセージとかアイテムの名前とかに攻撃文字列忍ばせて対策してないクライアントが読み込めば攻撃成立だ なんかJNDIとかもういらねえ仕様だよな
Javaが出始めた20世紀末はコンピューターの性能が低いのとネットワークへの過度の期待で各計算資源は最小限のワークロードを保持してはほかはリモートから取得しましょうという考えが主流でその流れにのってRMIとか作られたわけだからな
今はクラウド主流で計算資源は生えてくるし性能の進歩でワークロードを小さくなんてどうでもよくなった
にも関らずJNDI便利だからと当初の考えと違う使い方で使うようになったからオミットできず、本来想定してた用途が攻撃に使われるとかコンピューターシステムの悲哀を感じますね >>292
過去の資産を使い回したいのか知らんけど
誰でも知ってる大企業でも新規案件でasp.net form＋vb.net
で指定してきて驚愕したわ こう言うのはフィールドの中身がコマンドとして処理されないようにサーバー開発時に加工した内容で渡すようにしていたらいいだけなんじゃないの？
そのままプロセスに丸投げしちまっている開発屋には唖然とするわ
何もわからないでただやっているだけとしか言いようがないよね >>300
コマンドとプロセスしか認識できない馬鹿は黙ってろ >>300
ログとして出力すべきものを評価されないように加工ってギャグでいってんのか？ そもそもがフィールドの中身の文字列を精査しないでコマンドの処理としても受け付けるような形で丸投げしているからこの様な事例が発生しているんだよ
サーバー運用側での不備です この程度の事すら想定しないで仕事を請け負っている開発屋には、今後はもう仕事を発注しない事だな
日本のWeb開発屋はレベルが低過ぎるわw と閉じたネットワークで仕様通りのデータしかやってこない仕事しかしたことないお爺ちゃんが猛っております >>297
止めるだけでも一悶着なのにw
CIOがいきなり記事読んだだけで再現して問答無用でlog4j2置き換えるぞオラーとでもやれればいいけど
そんな奴おらんし 直すなんて言っているのはSQLインジェクションへの対策でも、
ほとんど一般に出回っているのツールに丸投げしてやったつもりになっているだけなんだろうなw
これでもプロの認識なんだそうなw >>305
記事もソースも読めてないのが丸わかりでドヤっているのがなあ >>309
更新までの手続きを金曜の午後からやらなきゃいけないことにうんざりというのがわからなかった？ 対処するのは技術的には簡単だよね
手間はかかってめんどうだけど
まともなところなら大事にはならんわ
やっぱオープン系のライブラリつかうときはラッパーかましといたほうが保守は安心やな いまだったらこれでマイニングするワームしこむのがコスパええんやろな バカが考えた入力値の検証なんて余裕で回避できるからな
jndi:
jn${env::-}di:
jn${date:}di${date:':'}
j${k8s:k5:-ND}i${sd:k5:-:}
j${main:\k5:-Nd}i${spring:k5:-:}
j${sys:k5:-nD}${lower:i${web:k5:-:}}
j${::-nD}i${::-:}
j${EnV:K5:-nD}i:
j${loWer:Nd}i${uPper::}
ちょっと考えただけでこれくらいはでてくる >>299
Webフォームってマイクロソフトのサポート切れてるか、もうじき切れるかするやつじゃん
今さらそんなん採用することあるか？
すぐにcoremvcに書き直すことになりそう
やったね！ バカはフィールド値をそのまま丸投げするシステムにしているからいつでも問題になる
俺が考えたら必要のないそんなものはそもそもコマンドとして受け取らない 残念でした・・・ 事実まともな企業さんのサーバーではほとんど問題になっていないんだろうと思う
時間が空いた時にでも対策されたライブラリーに一応更新しておこうって手筈だろうよ
ダメな奴はどこまでもダメなんだなw 大先生のつくるシステムはユーザーエージェントとかもサニタイズするのかな？🤔 時価総額世界最高のAmazonやAppleで影響出てるのに30年成長ないジャップ企業に勤務してる奴らに言われてもなw Javaってだけで馬鹿にするようなやつが多すぎるな
Javaなんてプログラマーからしたら義務教育みたいなもんだろうに Spring bootで構築したソシャゲサーバやばいやんけと思ったけどサ終してたワイ、高みの見物 プログラムが書けるってだけのカスプログラマー乙
俺なんてバッチが書けるんだぜw 一番日本を貶めてるのは、ここにいるような何もわかってない（調べてもない）のに文句だけ言ってる連中なんやな 最新のJava 17を利用するなら無償だけど
枯れたJava 8とかの保守費用は有償だからな！ >>323
大先生はサニタイズする関数への引数もサニタイズしてから渡すぞ >>79
こんなのもわからんのがプログラマ名乗るなよ マージ後、機能のプルリクエストだした奴がトンズラ
↓
しゃあないからプロジェクト側で面倒見てた
こんなんマージすんなよ >>337
このライブラリじたいも７人くらいしかメンテナいないからな
オプソに有りがちな人不足ってやつ 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オプションについて書いたけど
バージョンが古いとこれもダメかあいたたた ■ このスレッドは過去ログ倉庫に格納されています
