  |
はてなキーワード: LOG4Jとは
ナチ礼賛する感じのデータを与えて最悪な助言をさせる。実際にChatBotとのやりとりをもとに自殺した人が存在する。
他の攻撃の足がかりにもなる。
これも基本技で、権威や品質を保証させた上で恐ろしいことを起こしてトドメをさす。
デマゴーグ。Googleサジェスト汚染からの間違った記事がトップに出てくるコンボで有効性は実証済み。
社交性の高いエンジニアは、意図せずにこの攻撃を行うことを「ハルシネーション」が起きたと、幻覚でも見てるかのようなうわ言でごまかす。
Chatbotが出したソースコードを置いて、レビューは「Chattyが言ったんですもの」で済ませる（済ませられた場合、暗に「権威振りかざし」攻撃が成立している）。後々クソバグる。
log4jが逝った時大変だったろ？残業したくなきゃやめとけ。
「汚染」して「間違った知識を広める」ことでエコーチェンバーを作る。
各々のエコーチェンバーに「権威振りかざし」バトルをさせ、蠱毒の原理でクソデカいカルトを作る。
そうこうしている内に、それぞれが日々の労働をChatbotに頼って行い「間違った文言を大事な場所に放置」していたものが爆発する。
めちゃくちゃになった世界の中心では獣が叫びながら、遍くワクチンの接種を拒み、いかなる疾病をも陰謀と断じる。
「100分de名著」ローティ篇第３回「言語は虐殺さえ引き起こす」
https://x.com/hee_verm/status/1759564599987478894?s=20
まあ、知識をつけながらバズってるブクマ（だいたい本文読んでねーーーバカが適当な根拠のない自論をお披露目する糞放り出し会場になってる）くらいの信用度でChatGPT等々使って、裏付けとったら有用なんじゃないすかね。
単に産業革命時の機織りと違うのは品質の低下が生む「結果」なんだよね。服がスカスカでもそこまで困らんし、目に見えるから直せる。知らんけど。
docomoの平文保存が話題だけど、そもそもNTTの中にはセキュリティの専門家なんていないからな
平文保存みたいなことを平気でやる一方で逆にクラウド一切信用しないマンみたいなのもいたり
GitHub禁止とか社内網をプロキシでガチガチにしちゃってるのに
一部のクラウドサービスはザルになってて（接待でも受けたんだろうね）シャドーIT天国になってたりする
ちなみに研究所にはセキュリティの研究者や暗号の研究者とかはいるんだけど
ペネトレーションテストっていう意味は知ってても実際に出来る人はいない
子会社に行くとそもそも意味を知ってるかどうか怪しい（知ってたら外注すると思う）
ただ部署としては各子会社が「情報セキュリティ部門」みたいなのを作ってるんだけど
実際に業務してる中の人は地方から参勤交代で人事異動してきた素人
「〇〇県の教育委員会にITシステム納入実績あり」→「ということはセキュリティ分かるよね？」
一週間ぐらいの研修受けたら「スペシャリスト認定」みたいなの貰える
「我が社には専門家が多数在籍！」
とかはそういうこと
そのくせに多大なる権限を持っているので、業務効率化のために社内サーバを建てようとしてもデフォルトDenyになってる
仮に設置しても四半期に一度はエクセルでできたセキュリティチェック表をPDF化して上長の手書きサイン貰うとかそういうレベル
社外向けにクラウドでサーバ構築する時も導入必須のソフトウェアがズラーッと並んでて
とかいうのを指摘しても
「規則なので導入してください」
当然土日とかは返事が無いのでlog4jのときも週明けになってようやく
ちなみに苦情とか改善要望を上げても上長はまだしもその上の偉い人とか役員は重要性がさっぱり分かってないからどこかで消えてしまう
問題が起きたらどうするか？もちろん揉み消す！流石だね！
オープンソースcURLの作者、某大企業から「24時間以内にこの質問に答えるように」との無礼なメールを受け取る － Publickey について思ったことをつらつらと。
log4shell と呼ばれる脆弱性が 2021 年 12 月にあった。これは Java というプログラミング言語でプログラムする際に、動作のログを記録するのに非常によく使われるライブラリ log4j にとても危険な脆弱性があった。なにがそんなに危険かっていうと
マインクラフトのサーバが乗っ取られたとか被害も有名。詳細は Piyolog さんの Log4jの深刻な脆弱性CVE-2021-44228についてまとめてみた - piyolog あたりを参照。
そんなわけで即座に影響範囲、脆弱性のない新しいバージョンになっているか調べろ！って IT 関連企業はとてもバタバタしていた。
という背景の中、オープンソースのソフトウェアである cURL の作者にとても失礼な log4j の問題に関する質問メールが送られてきて、「サポート契約すれば即座に教えてあげますよ」ってかっこいい返しをして盛り上がっている。
cURL (https://github.com/curl/curl]) はオープンソース(以下 OSS)の通信ライブラリとコマンドラインツール。 Linux などのサーバ上からファイルをダウンロードしたりするのにとてもよくつかわれるライブラリ。
C言語で書かれている。
ライセンス は MIT を参考にした独自ライセンス https://curl.se/docs/copyright.htm]
OSS は基本的に無保証で提供される。そのことはライセンスに明記されている。
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
そんな OSS に対して、
「あなたがこのメールを受け取ったのは、■■があなたが開発した製品を採用しているためです。私たちはこのメールをあなたが受け取ってから24時間以内に、お読みいただいた上でご返答いただくよう要求します」
といった上から目線のメールを開発者に送るというのは、IT 企業として無知にもほどがあるといったところ。加えて log4shell 問題、名前のとおり log4j の脆弱性なので Java でかつ log4j を使ってなければ影響はないのに、C言語でかかれた cURL に問い合わせているので問題を全く理解していない。(Java の j が消えるので log4shell という命名はどうなんだというのは個人的にある。つーか Poodle とか Spectre とかファンシーな名前つけてあそんでんじゃねーとも思う。)
なお cURL はどうやら開発者の Daniel Stenberg 氏が wolfSSL というところを通じて商用サポートを提供しているらしい。 https://curl.se/support.html]
ということで、「サポート契約を結んでいただければ、喜んですべて速やかにお答えしますよ」 というのはネタでもなんでもなく、普通の対応。
そしてブログに書いてある2回目の返信で、David と名前を間違えられたのに対して、Fotune 500 の巨人ということで "Hi Goliath," と返しているのも最高にクールですね。
こういうフローが事前に規定されていて CVE とか問題が検知されると発動する。このときに担当が大丈夫です！って回答するときにエビデンス（証拠）を求められるのだけど、クソな情セキは自社の担当の言葉を信用せず、開発会社からの言質をとれ！って命令するので、くそメールがスパムされるという背景があったりする。（担当が無知だったりイケイケだと、とにかく下請けにやらせればいいというパターンももちろんある）
そして情セキも経営層に報告するのに必要で、経営が0リスク信者だと報告が大変なのはわかる。わかるがそれを説得するのが情セキの仕事やで。
加えて担当レベルになると大手は「そんなん下請けにやらせればいいだろ」ってマインドのところが多く、上から目線かつ丸投げすることが多いように思う。
もちろん担当者はピンキリだからこうとは限らないけど比較的多い印象。
ま、これ今回 Daniel Stenberg 氏が公表したからばずってるだけで、日本でもしょっちゅう行われているし、Hacker News みると海外でも一般的なムーブのようです。 LogJ4 Security Inquiry – Response Required | Hacker News
小さいところは
とかであんまり上から目線でこない感じはするけど、これはあくまで個人の資質なのでやべー人はやべーです。オラオラ系の中小とかやっぱいます。でもこんな細かいことはあんまり聞いてこない。（個人の感想です）
この手のメールになんでカチンとくるのかって言えば
ということで、皆ちゃんと保守・サポート契約して、契約範囲で質問しような！
そして金払ってても相手は人間なんで、お互い敬意をもって接しような！
Public Key でこの件にからめて記載されている奴について
https://www.itmedia.co.jp/news/articles/2201/11/news160.html]
ちな、これ詳しくないんだけど、OSS 作者が 「もうただ働きで支援をするつもりはない。これを機に、私に6桁ドルの年間契約書を送るか、プロジェクトを分岐させて他の人にやってもらうかしてほしい」 というのもよくわからないんだよなぁ。
火事で財産失ってむしゃくしゃしてやったのかなんなのか。人気 OSS になったのに全然金にならんぜ！ってのが辛いのはわかる。が、OSS のライセンス的に支援を義務としてやる必要はないので、そんな義務的になってる報告は無視してええんちゃうんと思ってしまう。今回みたいにサポートフィーよこせみたいなスキームが必要だったのかもしれない。
あと個人開発で、善意でこれ便利だろ？って公開しているものに対して、辛辣な言葉の心ないバグ報告やら改善要望は心には刺さるので辛いのはある。それで辞めてしまう人も居る。
ブコメでフリーライドって書いている人が居るけど、MIT ライセンスでだしてんだから OSS の理念である自由なソフトウェアという意味で、再配布、改変、利用は自由でいいんだよ。イヤなら MIT 以外のライセンスでだせばよい。古くは MySQL の Dual ライセンス、最近の Redis とか Mongo みたいに。
ただ、金欲しいとか大体 Donation 募集したりするとかやってると思うんだけど、そういうのもあったのかなかったのかがよくわからにぃ。ポートフォリオになるので、採用にはつかえるんじゃないのかね？
じゃなきゃ GitHub に Public でコード公開しないと思うんだけどな。いまいちピンとこないのであんまり言及しない。
https://www.publickey1.jp/blog/19/redismongodbkafkaaws.html]
で、商用ライセンスの問題。これ今回のくそムーブの問題じゃないのここに並べられるのに非常に違和感がある。なんか OSS と大企業の対立を煽るようなミスリードを誘っているように感じてしまう。
大手クラウドベンダは OSS のライセンスに則って利用・改変するのは問題がない。つーか儲かってるから金よこせっていうのはちょっと違うんじゃないかなと思う。
オリジナルを開発した会社がリスペクトされず、商業的に儲からないってのは、心情的、道義的、人気的にどうなの？クラウドベンダも金払ってあげれば良いんじゃないの？とは思うよ。（2社は協業したけど）
ただ、オープンソースで公開するということは次のような利点を求めてするこって、それがイヤならプロプラで良いわけさね。
Apache License 2.0 とかのライセンスの OSS として公表しているものの利用をフリーライドと表現するのも、それがなんか嫌儲で Evil ってのはちょっと判断できないかなぁ。
大手が自社でメンテできてしまう（できるようにする）というのは経営戦略であり、開発元がクローズにするってのも経営戦略。罵り合い合戦はちょっとなぁという感じ。
OSS の理念的に改修した分は元のソースにもっとフィードバックしろよってのはあるけど AGPL とかで出してないんだよなぁ。
この辺は賛否両論色々あるので気になったら調べてみて。
以上。ご査収ください。
多くの方がご存知の通り、Log4j 2 (以下面倒なので Log4j) の脆弱性 CVE-2021-44228 が公開されて一週間が経過しようとしています。
ちなみに、数時間前に修正不備として CVE-2021-45046 が出ています。formatMsgNoLookups による対策はできません。大変ですね。皆さん対応のほう、いかがでしょうか。
自組織で Java アプリケーションを開発している場合は、把握しやすいかもしれません。ですが、Elasticsearch や Apache SOLR などのソフトウェアなど、インフラ基盤として利用しているソフトウェアへの影響を確かめるのはなかなか大変な作業だったのではないでしょうか(もちろん素早くアナウンスを出してくれたところもありますが、ゼロデイだったこと、US は夜であったことから、アナウンスを待つ前に対応が必要だったところもあると思います)。
OSS なら依存パッケージを比較的調べやすいですが、Splunk や Salesforce のようなアプライアンス製品などはどうでしょう。スイッチやルーターは? クライアントの Java アプリケーションもですね。さらに、業務委託先はどうでしょう。考えることが山積みです。
ソフトウェアサプライチェーン管理の難しさを痛感した組織も多いのではないかと思います。
ゼロデイだったため、最初は対策方法についてもまとまっておらず、間違った対策方法が流布しているのも見かけました。
「特定のクラスファイルを削除する」という正しい対策も、「えっ マジかよ。クラスファイル消して他に影響でないのかよ。それはないだろ。」と思った人もいると思います。私は思いました。なんだその対策。
その他 Web Application Firewall のバイパスなど、ご対応された皆さん、本当に大変だったと思います。お疲れ様です。
これも全部 Wizard Bible 事件やアラートループ事件の影響なんだろうけど、それにしても具体的な攻撃手法が共有されてなさすぎだろ。
最初てっきり LDAP 閉じたり、WAF で jndi:ldap を弾けばいいと思ってたよ。対象を把握して全部対応するの大変だから、まずはそれでいこうと思ってたよ。全然ダメじゃん。RMI とかいうよく分からないパターンもあるし、${lower} とか使って WAF バイパスするとかしらねーよ。そんなのできんのかよ。
攻撃のメカニズムなどを解説してくれている記事があれば、最初から迷わず頑張ってアップデートする方向に舵取れたと思う。
誰も情報共有しないとセキュリティ業界衰退しますよ。人材育成もできないし。サイバー人材育成不足とか言う前に、ちゃんと然るべきところに意見言いましょうよ。
小学校で配られた端末のセキュリティ突破が話題というのもニュースで見たし、放っておくと規制の方向にエスカレートしてしまうと思いますよ。
そういえば情報共有でいうと CISA は動きが素早かった。最初は個人の gist に影響のあるソフトウェアがまとめられていたけど、数日後には https://github.com/cisagov/log4j-affected-db で網羅され始めた。Pull Request も取り込んでいて、素晴らしい。
一方で JVN DB の方はどうでしょう。https://jvn.jp/vu/JVNVU96768815/
報告を受けている製品しか書いていないのですかね。国内製品はもっと影響あると思うし、公表している製品もあると思うんですが。積極的にまとめていかないんですかね。こんな状態だと、組織は影響範囲を調べるのに苦労しますよ。
「セキュリティ業界このままじゃダメだと思うのですが、なにか動きはあるんですか？」「皆さん利用している製品やソフトウェアの把握どうされているんですか? 」の2点をお聞きしたかったのです。
まずはバグの原因を突き止めてそれが何故テストをすり抜けたかを調査
調べてみるとテスト中に出てくるエラーメッセージが微妙に違うけど気付かずにスルーしてしまったらしい
再発防止策としては社員のマインド醸成とか言い出しててアホかと
上流工程でもっと詳細な検討をするべきとかも言い出しててホントアホかと
報告書を上司の上司の上司まで報告し終わったらようやくバグ改修の予算が下りるらしい
そんでその予算を使って契約書作って上司の上司の上司まで承認を貰えたら修正開始
修正そのものは3行ぐらいなんだけど、もう一回テストやり直すんだって
多分だけどマインド醸成するための研修とかもやることになるんだろうね
この手の人達にアジャイルをいくら説いてもそりゃぁわからんよなぁ
要するにこの手の人達って骨の髄からミスが嫌いでこんなことになってるんだと思う
電車が遅延するとか、お釣りを2円間違えてるとか、書類の提出が1日遅れたとか
そういうのが大っ嫌いな国民性だからソフトウェアのバグも根本的に嫌いなんだと思う
「よく考えて作れば間違いは起こらないよね？」
「ちゃんとチェックしたの？」
とかそんなことばっかりやってる
とか平気で言ってくるんだもんな。どうかしてる
あと、心の底では機械を信頼していないっていうのもあると思う
コンバインで刈ったお米よりも手作業で刈ったお米の方が美味しいと思ってる
Excelが計算した数字よりも、自分で電卓叩いた方が正しいと思ってる
（電卓の中身は分かってないのだが、電卓はもはや自然の一部だと思ってる）
ちなみに本当にExcelは間違えることがあるのでタチが悪いのだけれど
そもそもExcelを使う利点は「入力すべき数字だけを入れれば、必要としている数値や情報が自動的に計算される」という点にあるんだけど
そこまでいくともう信用されない
なのでプログラミングみたいなことをやるときにも「信用できない」っていう前提で作るから
とにかく慎重に作るし、間違いが無いように丹精込めてじっくりゆっくり作る
人間が指さし確認でExcelの表を一つ一つ埋めていくし、それをダブルチェックする
誇張でもなんでもなくて、割とこういう開発は日本中で行われてる
結局彼らにアジャイルマインドを教えるのなんて天動説を信じてる人に地動説を教えるぐらい不毛な話なんだと思う。
天動説が廃れたのは、ただ天動説を信じてた人が死んでいったから、という話と同じで
この手のマインドの人達が定年して退場して頂くまでこれは続くんだろう
ただ、若手が彼らのマインドを引き継いでいる様子もあるので地獄しか待っていない気もしなくはないが・・・
ちなみにLog4jのことは昨日知ったらしくこれから対処予定らしい。
この件の最大のミスは、大半の人間が必要としていないどうでもいい（しかも過剰にパワフルな）機能をデフォルトで有効にしてリリースしていたことで、それは言語とは独立していると思う
第一引数にlookupを含む文字列が入るとフォーマットプロセスが操作される可能性があることを理解していないユーザーも問題だが、それでもLDAP経由でclassをダウンロードしてRCEできるとならなけりゃここまで問題にはならなかったのだから、ユーザー側の責任はlog4j側に比してだいぶ小さい
HTML 出力し得る文字列の HTML 特殊文字を全部エスケープして、内部からのものもエスケープしているので二重エスケープになっているのが増田
その辺の指摘が正しいのではないかと思うんだけど
そもそもはJavaで分散オブジェクト指向が流行したのが問題の歴史的な発端だと思ってる
つまり、RMI（いわゆるRPC）とかCORBA（それは紛れもなくヤツさではないです）とかHORB（産総研だっけ？）とか、
ネットワーク透過だのRPCのスケルトンだの、そういう話が発端な気がする
つまり、インターネット上ではマシンは当然ネットワークで繋がってはいるけど、
マシンAのJavaのプロセスがマシンB上のJavaのクラスを読み込んで実行できたり、
マシンBに肩代わりさせても、それを意識しないように書けると便利だよね、
という話であって、
ぶっちゃけ、今になっても、
世の中的に、今はJavaよりイケてると思われてる言語にも、この手のネットワーク透過にする機能とか、
よー知らんけど、クラウドコンピューティング（）だなんだの機能としてあっても不思議ではない気がする
昔で言うなら、ソニーのTelescriptとかよー知らんけど、
ネットワーク上の複数のマシンを渡り歩くプロセスというかプログラムみたいなのが実現できるのって、
今になって考えてみると脆弱性の温床でしかない気がするし、理解はできる
理解はできるが、じゃあ、まったくメリットがないのかというとそうでもなくて、
しかし、Javaのかつての流行が放置されたままになってるとか、そういう問題はあるわけで、
その辺がセブン＆アイだったかの、Struts2のOGNLインジェクションもそんな感じで、
ぶっちゃけ、マシンAからHTTPでマシンBのJavaクラスとか実行できたら便利だよね、みたいな話で、
マシンAとマシンBが外のネットワークと敷居があるという前提があるから問題がないのであって、
CGIでもよくあったけど、サーバー側の任意のコマンドを実行できるというのは、
サーバーの状態を監視するとかには便利だけど、当たり前だけど危険だよね、という話であって
眠くてまとまらない…
おやすみ…
あ、言い忘れるところだった
知らんけど
