くま△@スタバマックしない系エンジニア retweeted
私が脚本書きました
半分くらいに削られたけどこの辺のセリフは直されないでそのまま使われてますね
自分でも何言ってるかよくわからん
シンクロコード15秒てのは長いかなと思ったけどワンタイムパスワードみたいな感じの、人間がキーで入力する用のコードなんで15秒が限度かなと思って15秒にしといた
情報漏洩が起きないことを数学的に保証するバックエンドフレームワーク「Nyxis」を公開しました!
たぶん世界初です。
Nyxisで書かれたバックエンドは、企業の持つ機密情報をより安全に守ることができます。
昨今急増しているサイバー攻撃を防ぐ手段として、このような方法があることをお伝えしたいと思い、今回の発表に至りました。
開発者は「どの権限を持つユーザーが何を実行可能であるか」のルールを管理するだけで、残りのコードをAIエージェントに任せても認可の安全性が担保されます。
Nyxisは大部分がLean言語で記述されており、形式検証によって
「任意のHTTPリクエスト列に対し、認証された主体の正当な権限を逸脱するデータの読取・変更・削除・権限付与は発生しない」
という認可安全性定理を機械的に証明しています。
認可の不備は、OWASP脆弱性ランキングにおいて2019年版から連続1位であり、最優先で対策すべきリスクの一つです。
形式検証を活用したこのフレームワークは、テストに頼る従来の開発に比べて、格段にセキュアなソフトウェアを実現します。
先日MicrosoftとGitHubが、形式検証を用いた開発キット「PDD Kit」を発表しました。
こちらはより幅広い性質を扱える一方、プログラムごとに仕様を作り、それが意図に合っているかを開発者が確認する必要があります。
Nyxisは証明する定理を認可安全性に絞ってあらかじめ定めているため、開発者はポリシーを管理するだけで済みます。
もちろん、一定の仮定は存在しています。証明外コードと実行環境は信頼する前提であり、開発者がポリシーを誤って書けば、意図した保護は得られません。
この定理の範囲内において、数学的保証は非常に強力です。実システムに組み込める技術としてここまでの保証を与えたものは、私の知る限りまだ存在しません。
一方で、表現力の乏しさやLeanのライブラリ不足など、改善すべき点はまだ山積みです。
本当はもっと完成度が高まった時点で公開しようと考えていましたが、昨今のセキュリティインシデントの状況を鑑みて、このタイミングで発表することにしました。
世界をセキュアにする一助になれば嬉しいです。
github.com/NyxFoundation/nyx…
"구루메" 였음 돈코츠 라멘 원조는 하카타도 구마모토도 아니고 후쿠오카현 구루메시 1937년 구루메 포장마차에서 시작된 거 하카타도 구마모토도 거기서 갈라져 나온 거라 둘 다 "우리가 원조" 라고 못 함 대신 서로 "우리가 더 맛있다" 로 싸움
아저씨가 그릇을 내밀면서 차이를 설명함 하카타는 면이 가늘고 국물이 담백하고 "카에다마(면 추가)" 문화가 있음 구마모토는 면이 더 굵고 국물에 "마유(튀긴 마늘 기름)" 를 띄워서 검은 기름이 돌고 카에다마 없음 면이 굵어서 한 그릇으로 끝
"하카타에서 면 추가했어?" "두 번요" "여기선 그거 안 돼 면이 굵어서 불어 그래서 처음부터 제대로 줘" 아저씨 논리
먹었음 마늘 기름 맛 하카타보다 진함 솔직히 "이게 더 좋은데" 했더니 가게 손님들이 박수 침 할아버지가 "구루메 가봐 거기가 할아버지야" 함 하카타는 형 구마모토는 동생 구루메는 할아버지
그 뒤로 규슈에서 라멘 얘기할 때 "원조" 라는 말을 안 씀 "하카타 스타일" "구마모토 스타일" 이라고만 함 그래도 구마모토 사람은 "하카타보다" 를 꼭 붙이고 하카타 사람은 "구마모토보다" 를 꼭 붙임 할아버지(구루메)만 조용함
구루메 갔음 진짜 할아버지 맛이었음 근데 구루메 가게 아저씨가 "하카타랑 구마모토가 싸우는 거 알아요?" 했더니 "애들이 그러라고 해" 함 할아버지 여유
구마모토 아저씨가 마지막에 그랬음 "다음에 하카타 가면 '구마모토가 더 맛있다' 고 말해봐" 안 했음 거기도 가게가 조용해질 거 같아서
くま△@スタバマックしない系エンジニア retweeted
【PHPセキュリティ問題 時系列順まとめ】
今回のPHPの事案を時系列順にまとめてみました。
----
2024年:PHPの潜在的な脆弱性を発見
外部監査をきっかけにメモリ管理の問題を認識。
しかし、修正方針がまとまらず約2年間対応が停滞。
↓
2026年8月:重大な任意コード実行リスクが判明
Calif(セキュリティ企業)やOpenAIなどが、認証なしで任意コード実行(RCE)が可能な攻撃経路を報告。
PHP開発チームが修正を最優先で進める。
↓
10月21日 0時頃:脆弱性情報が事前流出
修正パッチ公開前に、2件のCVE番号がHacker Newsへ投稿され、←何してんの
それがSNSや掲示板にも拡散。
※この時点では技術的な詳細は含まれていなかった。
↓
10月21日 4時30分:PHP公式が緊急告知
情報流出を受け、パッチ公開予定を22日から21日23時(日本時間)へ前倒し。
↓
10月21日 5時頃:攻撃実証動画が誤公開
Califが攻撃の動作動画を誤って公開。←最高にカス、バカ
すぐに削除されたものの複製が拡散し、攻撃コードの開発が加速。
↓
10月21日:研究者らによる未検証情報が拡散
パッチ公開前に、@ J4ck3LSyN などによって脆弱性の原因や再現方法をSNSなどで発信する動きが発生。←余計なことをするな
↓
10月21日 16時41分:修正済みバイナリを先行公開
Chainguard(セキュリティを専門とする米国企業)が公開予定の約6時間前に修正済みコンテナイメージを配布。←最大最悪のカス、超絶ルール違反
これにより攻撃者によるパッチの差分解析が可能な状態に。
※PHP Foundationもこれを一方的なエンバーゴ違反(事前に取り決めた情報の公開禁止期間を守らないこと)と明言しています。
↓
10月21日:国内外でサービスの緊急停止が相次ぐ
修正パッチがまだ提供されていないため、国内外のWebサービスや政府機関が予防措置として一時停止・メンテナンスを実施。
↓
10月21日 23時頃:PHP公式が修正版を公開
CVE-2026-109618、CVE-2026-109619への修正を含むPHP 8.2〜8.5の更新版を公開。
↓
10月22日:情報流出と管理体制の問題が焦点に
PHP Foundationが、2024年からの修正停滞を組織的な失敗と認める。協調的な脆弱性開示が崩れた経緯も問題視される。
----
【結論】人災。
特に、
⚠️ Califが攻撃の動作動画を誤って公開したこと
⚠️ Chainguardの勝手な判断による修正済みバイナリを含むコンテナイメージの公開
が最悪。終わってます。
言い得て妙
くま△@スタバマックしない系エンジニア retweeted
お祭り2日目はじまるよ~
Fortinet は詳細が不明だけどほぼ全製品
fortinet.com/blog/ciso-colle…
PAN-OSは管理インターフェースに影響っぽい
security.paloaltonetworks.co…
違うんです。みんなが気にしていなかっただけで、ウェブサーバやその上で動くウェブアプリケーションに携わる人達は、これまでずっと脆弱性と戦ってきたんです。
日々、脆弱性が報告され、そのたびに自分達のシステムへの影響の有無を判定し、影響があればパッチを当ててアップデートする。ログを監視し、アタックがあればブロックし、バグがあれば修正し、そしてまた次の報告が来る。何も起きない日は誰にも気付かれないし、褒められもしない。それでもインターネットが動き続けてきたのは、完璧なプログラムがあったからじゃなくて、壊れるそばから直し続けてきた人達がいたからなんです。
ただ AI の登場で、脆弱性を見つけて突くスピードが一気に上がって、直すスピードより壊すスピードの方が速くなってしまっただけなんです。
これからは、サーバアプリケーションを作る人達も AI を使って直すスピードを上げ、先を予見して穴を塞いでいかなければなりません。今はちょうどその過渡期なのです。
私は50年近くプログラミングをやってきたけれど、脆弱性のないプログラムを書くことは難しく、自分の技術力では到底たどり着けない領域だと感じていた。
それでも、世界には自分など及びもつかないほど頭のいい人たちが大勢いて、そういう人たちが書いた堅牢で美しいプログラムによって、インターネットという巨大な仕組みが支えられているのだろうと、どこか楽観的に信じていた。
自分にはできなくても、きっと誰かにはできるのだろうと、長いあいだ思っていたのである。
しかし、今日の騒動を見ていると、どうやらそうでもなかったらしい。
人類は月に人を送り、何十億もの人々が瞬時につながる世界を作り上げ、ついには人間のように言葉を操るAIまで生み出したというのに、それらを支えるプログラムから脆弱性をなくすという、一見ささやかな願いさえ、いまだに叶えられずにいる。
人類には、脆弱性のないプログラムを書くことは、まだ難しすぎた。
今日ぐらいは、そんなクソデカ主語で語っても許されるだろうか。
自分がブラウザーのセキュリティ報告を受け付ける責任者だったとして
「とあるCAの秘密鍵は4です。残りの7つも256以下の値です。opensslによる検証コマンドはこうです」
みたいなふざけた報告が来て1.5時間で連絡を返せるかねぇ。
秘密鍵が4だった問題、発端はちょっと遊びで公開鍵リストに対してたまたま秘密鍵を極めて小さいテスト用と仮定して簡単なテストを回したら発見してしまったらしい。
発見から1時間半後に各ブラウザーベンダーに通報。通報から2時間後にChrome責任者が反応。
bugzilla.mozilla.org/show_bu…
くま△@スタバマックしない系エンジニア retweeted
今回のPHP脆弱性にかかる保守契約内外の対応について
Xサーバ側でPHPバージョン8.2~8.5については、修正パッチがすべて適用されたようです。
なので、現在PHP8.2~8.5を使っている人は、今回の脆弱性については一旦リスクが回避できたと考えていいです。メンテモードにしていた人は、基本的に解除して大丈夫。
ただし、PHP8.1以前の人はまだ修正パッチの適用が完了していないので、メンテモードを解除しないほうがいい。
Xサーバ管理画面が復活したら、適宜PHP8.3以上などに上げることを検討してください。
なお、8.2~8.5を使っている人は、今回の脆弱性対策のためだけに無理にバージョンを上げる必要はありません。
PHPのバージョンは、下記の手順で確認できます。
【確認方法】
WP管理画面(サイトヘルス):
1. WordPress管理画面にログインする。
2. 左側メニューの [ツール] > [サイトヘルス] をクリックする。
3. 上部にある [情報] タブを開き、[サーバー] の項目を展開する。
4. [PHPバージョン] の記載を確認する。
【確認事項】
PHPのバージョンを上げると、旧バージョンのPHPでしか動かないプラグインや、ソースコードの記述が旧バージョンでしか動かないものである場合などで、どこかしらサイト上の機能やデザインが壊れたりする場合があります。
その場合は新バージョンに合わせてプラグインをアプデするか、プラグイン側がもしアプデに対応してくれない場合は、対応プラグインを探して代替させる形で、その部分を新たに作り直さなければなりません。
つまり、保守契約しているお客様の場合は、
1.定期で取ってると思いますが、何より最優先にバックアップ
2.phpのバージョン確認
3.phpを最新に上げる
4.上がった後にサイトの機能やデザインチェック。エラーが出てないか確認
5.プラグインやコードにエラーがあったら適宜修正
この順番で対応するのがいい。
で、保守をしていないお客様には、あまり積極的に案内をしないほうがよく、するにしても、必要以上の責任を追わないように注意すること。
冷たいようだけど、こういう場合においては自己保身を一番最初に考えたほうがよく、下手なことをいうとこちらに全責任を負わされ、損害賠償請求等の話にもなりかねない。
だから、保守契約をしていないお客様に連絡してあげるのはいいんだけど、もしする場合でも、「保守入ってないあなたが悪いんだから、復旧は約束できませんし、壊れても私は悪くないですよ」というスタンスでやらないと駄目。
「PHPのバージョンを上げる」までは一律料金でいいけど、バックアップからの復旧、あるいはクラックされた場合の復旧などは一律にはせず、都度見積もりにして、「直らなくても私は悪くない」というスタンスを貫いてください。
何でも責任を感じてこちらが悪いみたいな姿勢を取ると足元を見られかねませんし、「PHP対応1万円」「復旧2万円」とかで一律で案内しちゃうと、派手に壊れてたときにこちらに責任を負わされます。
金を取ると責任が発生する。
本当に大切なクライアントには案内していいけど、めんどくさそうなクライアントや、他責のクライアントには積極的に案内をせず、相手から問い合わせがあったときだけ対応でいいです。
冷たいようだけど、自分の身は自分で守ること。
お客様のために何とかしてあげたいという気持ちは大切ですが、それと、お客様が抱えている問題の責任を全部引き受けることは別の話です。
善意で対応して、自分の仕事や生活まで犠牲にしていたら何の意味もない。
プロとして責任を持つことと、何でもかんでも責任を背負い込むことは違います。
ここは絶対に間違えないようにしてください。
くま△@スタバマックしない系エンジニア retweeted
今回のPHP脆弱性問題で恐らく多くのエンジニアが認識したと思うのですが、
・OSSのメンテナーの居住地は欧米が中心
・そのため脆弱性パッチの公開時間は欧米のエンジニアが活動しやすい時間帯に設定されることが一般的
・その時間帯は日本では夜遅くか深夜である。
・AIの進歩により今後も即時の緊急対応が必要な脆弱性はかなりのペースで発見され続ける可能性が高い。
・つまり今回と同様な「深夜の緊急の脆弱性対応」が日本において定常化してしまう可能性が非常に高くなっている。
という由々しき状況なんですよね。
この問題に関して、OSSの未知の脆弱性発見のペースをコントロールすることは不可能ですが、「エンジニアの深夜対応の負担をできるだけ減らす」ことは可能なわけです。
なので各企業さんはコンテナ化やテストの自動化やCI/CDパイプラインの整備やOSSの新しいバージョンへの早期の追随という「脆弱性発見時の対応作業をできるだけ楽にするための改修作業」にちゃんとお金と時間を投資しないといかんですよね。それはコントロール可能なわけですから。
それをやろうとしない企業さんからはエンジニアはどんどん離脱した方がいいですし、そういう企業さんがサイバー攻撃で消えてくれた方が日本全体のセキュリティレベルは向上するわけなので笑、睡眠時間を削ってまで守ってあげる必要はないかなあというのが私の見解です😅






























