Opinion

はじめに: Chrome V8脆弱性の深刻度 先日、Google ChromeのJavaScriptエンジンである V8 に起因する、深刻なセキュリティホール（CVE-2024-4947）が公表され、既に悪用が確認されていることから大きな注目を集めました。 Forbesの当該記事によると、 米国国立標準技術研究所（NIST）によれば、「142.0.7444.175より前のGoogle ChromeにおけるV8の型混同により、細工されたHTMLページを通じてヒープ破損を遠隔の攻撃者に悪用される可能性があった」。この脆弱性は深刻度「高（High）」に分類されている。 とされています。 この脆弱性は、V8エンジン内部で発生する 「型混同 (Type Confusion)」 と呼ばれる処理エラーです。攻撃者は、このエラーを悪用することで、ブラウザのメモリを破壊し、最終的にはリモートで任意のコードを実行（RCE）することが可能になります。 型混同からコード実行までの流れ V8と型: V8は、JavaScriptコードを高速実行するために、データの「型」（数値、文字列など）を厳密に管理しています。 型混同の発生: 攻撃者が作成した特殊なWebページをユーザーが開くと、V8エンジンがデータの型を誤って認識します。例えば、安全なはずのデータ領域に、実行可能な悪意のあるコードが紛れ込んでいるにもかかわらず、エンジンはそれに気づきません。 ヒープ破損: 型混同を利用して、攻撃者はプログラムが使用するメモリ領域「ヒープ」を意図的に破壊（破損）します。 リモートコード実行: メモリの保護機構を突破した攻撃者は、最終的にシステムを乗っ取るための任意のコードを実行できるようになります。 Log4jの再来: なぜChromiumは危険なのか？ この種の脆弱性が特に危険視されるのは、その影響範囲が単一のアプリケーションに留まらない サプライチェーン・リスク を内包しているためです。この点で、今回の事案は、かつて世界中を震撼させた 「Log4j」 の脆弱性（Log4Shell）と極めて類似した構造を持っています。 Log4jは、多くのJavaアプリケーションで利用されるロギングライブラリです。開発者が直接Log4jを導入したつもりがなくても、利用している別のライブラリが内部的にLog4jに依存しているケースが多々ありました。その結果、一つのライブラリの脆弱性が、芋づる式に無数のシステムに影響を及ぼし、世界中のサーバーが危険に晒される事態となったのです。 Chromiumもまた、現代の 「隠れた共通コンポーネント」 となっています。 Beyond the Browser: Chromiumの広範な影響 問題は、この脆弱性がWebブラウザだけの問題ではないという点です。Chromiumは、Electron というフレームワークの中核コンポーネントとして、デスクトップアプリケーション開発に広く利用されています。 これにより、一見するとブラウザとは全く関係ないように見える多くのアプリケーションが、内部的にはChromiumを抱えています。つまり、Chromeブラウザの脆弱性は、これらのアプリケーションの脆弱性にも直結するのです。 以下は、Electron（およびChromium）を基盤とする著名なアプリケーションのほんの一例です。 コミュニケーションツール: Slack, Discord, Microsoft Teams, Skype, Signal, WhatsApp Desktop 開発者ツール: Visual Studio Code, Postman, GitHub Desktop 生産性向上ツール: Notion, Obsidian, Trello, Figma その他: Dropbox これらのアプリケーションは、意識しないうちにChromiumのレンダリングエンジンを利用しており、V8エンジンの脆弱性の影響を直接受ける可能性があります。 “Chromium is the New Generation’s Log4j” この状況は、Chromiumが 「新世代のLog4j」 であることを示唆しています。 ...

GIGAZINEの記事Samsungのスマホに削除不可能な情報収集アプリ「AppCloud」がプリインストールされて物議を醸すによれば、amsungが販売する中～低価格帯のスマートフォン「Galaxy A」および「Galaxy M」シリーズに、ユーザーに許可を得ず情報を収集し続けるイスラエル製のアプリ「AppCloud」が最初からインストールされているとして、主に中東・北アフリカ(MENA)地域で消費者の激しい反発を招いているとされています。 しかし、実際には、事態がもっと危険なことがわかりました。実際には、記事で触れられていない、Galaxy Sなどにも最初からインストールされている可能性があります。以下の情報は私の所有する、Galaxy S20+から確認しました。 これは、単なる迷惑アプリではありません。GIGAZINEの記事によれば、イスラエルで設立された企業のironSourceによって開発されたアプリで、ユーザーに継続的な同意を得ることなく、ユーザーの位置情報、アプリ使用パターン、端末情報等を追跡するとされています。 更に、最悪なものにしているのは、記事中にもある以下の情報です。 おまけにAppCloudはデバイスのOSに深く組み込まれているため、一般ユーザーがルート権限(管理者権限)なしでアンインストールすることはほぼ不可能です。レバノンに拠点を置くデジタル権利団体SMEXによると、アプリを無効化してもシステムアップデート後に復活するという報告もあるとのこと。 💣 事態の深刻度 I：技術的欺瞞の証拠 OS深層への組み込み: AppCloudは、デバイスの動作に必須ではないにもかかわらず、Samsung独自のカスタムOSの一部として隠蔽されていた 。 アンインストール不能: ユーザーによる通常の手段での削除が不可能であり、削除にはルートアクセスかADBコマンドが必要です。これは、データ収集の継続性を保証する意図的な設計と思われます。 👿 事態の深刻度 II：プライバシーとセキュリティへの脅威 AppCloudが収集するデータは、単なる利用統計にとどまりません。 個人プロファイルの構築: 位置情報、アプリの利用履歴、連絡先へのアクセス許可（もしあれば）などを組み合わせることで、ユーザーの趣味嗜好、行動範囲、交友関係までをも推測する詳細な個人プロファイルが作成される危険性があります。 情報の第三者提供: ironSourceのような企業は、収集したデータを広告主や他のデータブローカーに販売することで収益を上げています。ユーザーが知らないうちに、自身の個人情報がマーケティングや更なる監視の目的で取引されることになります。 セキュリティ脆弱性のリスク: このようなアプリがバックグラウンドで常に動作し、外部と通信していること自体が、セキュリティホール（脆弱性）となる可能性があります。悪意のある攻撃者がこの通信を乗っ取ったり、アプリの脆弱性を悪用したりすることで、デバイスが更なる危険に晒される恐れがあります。 👿 事態の深刻度 III 特に、大きな問題は、ironSource社は2022年にゲームエンジンとして著名なUnityと合併したためです。ironSource社のツール、プラットフォーム、技術、人材を活用し、収益化および成長をシームレスに、より簡単に行えると言っていますが、実のところ、そのデータは 欺瞞により構成されたもの であり、その影響は特定のSamsung端末に留まりません。 🕹️ Unity LevelPlay（ironSource）を通じたデータ拡散の危険性 ironSourceの中核技術であるメディエーションプラットフォーム「 LevelPlay 」（現在はUnity Adsの一部として機能）は、数百万のモバイルゲーム開発者に利用されています。 エコシステム全体への浸透 : AppCloudがOSレベルで収集した位置情報や行動データは、LevelPlayを通じてUnityエコシステム全体に組み込まれるリスクがあります。これにより、Unityで開発された 他の無数のアプリ が、ユーザーの意図しない情報収集の結果得られたデータに基づいて運営されることになります。 技術的な難読化: Unityとの合併により、ironSourceのデータ収集技術は、ゲームエンジンの内部にさらに深く統合され、ユーザーによる検知や削除が極めて困難になる可能性があります。これは、「スパイウェアの技術進化」 であり、モバイルプライバシーに対する最大の脅威の一つです。 🗣️ サポートの嘘が守ろうとした巨大な構造 キャリアサポートが提供元を「Google」だと偽って回答し、問題を矮小化しようとした行為は、この Unityという巨大なプラットフォーム と一体化した データ収集複合体 を守ろうとする意図があったと推察されます。彼らの欺瞞的な対応の背後には、特定の端末の問題を超えた、グローバルなデータ収益化の構造が存在しているのです。 ironSourceの中核技術であるメディエーションプラットフォームは「LevelPlay」という名称で提供されていますが、AppCloudのように欺瞞的な手段で集められたデータに基づいて収益を上げるシステムを「公平な場 (Level Play)」と呼ぶのは大きな欺瞞です。その実態を表すなら、 「SpyTheft（スパイ窃盗）」 と呼ぶべきでしょう。 🚨 「広告エゴシステム」が示す構造的犯罪性 広告エゴシステムの要素 事実による裏付け ユーザーの意思の完全無視 AppCloud/App Selectorは、OSの深層に隠蔽され、無効化しても復活する設計であり、ユーザーの同意を組織的に欺いた 。 全製品ラインへの恒久化 普及価格帯のA/Mシリーズから最高級Sシリーズ（S20, S25 UltraのApp Selector）まで、Samsungの全製品にデータ収集インフラを組み込んだ 。 キャリアによる悪質な流通 au版のSamsung端末だけでなく、Xiaomi端末からもAppCloudの自動起動が確認され、日本のキャリアがゲートキーパーとしての義務を決定的に放棄した 。 地政学的リスクとデータ汚染 ironSourceがUnityと合併したことで、欺瞞的に収集されたデータが、巨大なゲーム/アプリエコシステム全体に拡散し、データの信頼性を根本から損なった 。 問題の矮小化と隠蔽 auサポートが、この問題を「Googleの提供」による「年齢・性別の選択機能」という虚偽の情報で隠蔽しようとした 。 🛡️ ユーザーができる自衛策 プリインストールされたアプリを完全に削除するのは困難な場合がありますが、被害を最小限に抑えるための対策は存在します。 ...

WIRED誌が報じた「AIデータセンター投資が生む、米国経済の新たなひずみ」という記事は、現代のゴールドラッシュとも言えるAIブームの影の部分に光を当てています。しかし、この問題を真に理解するためには、映画『マネー・ショート』で知られる投資家マイケル・バーリー氏の警告を読み解く必要があります。 バーリー氏の主張が正しければ、ハイパースケーラー各社は、将来的に巨額のネガティブ要因を財務諸表内に抱え込んでいることになります。これは、会計上の処理が 「技術的な現実」 と乖離した結果生じる、避けられない 「時限爆弾」 とも言えるものです。 💣 会計上の「時限爆弾」：減損損失のメカニズム なぜ、巨額の投資が将来の損失に変わりうるのでしょうか。その鍵は 「減価償却」 と 「技術の陳腐化」 のズレにあります。 現在、多くのハイパースケーラーは、AIの学習や推論に使われるGPUサーバーの耐用年数を 「6年」 として設定し、その期間で費用を分割計上（減価償却）しています。しかし、AIチップの性能は2年未満で倍増するのが現実です。 このギャップが、将来の 「減損損失」 という形で爆発するリスクを内包しています。 graph TD subgraph 会計上の世界 A[GPUサーバーを120億円で取得] --> B{耐用年数を6年に設定}; B --> C[毎年20億円ずつ費用計上]; C --> D[3年後の帳簿価額: 60億円]; end subgraph 技術的な現実 E[2年後に次世代GPUが登場] --> F[旧世代GPUの性能が相対的に低下]; F --> G[市場価値と収益性が急落]; G --> H[3年後の経済的価値: 10億円]; end subgraph 減損損失の発生 D & H --> I{帳簿価額 > 経済的価値}; I --> J[差額の50億円を「特別損失」として一括計上]; end style A fill:#f9f,stroke:#333,stroke-width:2px style J fill:#ff9999,stroke:#333,stroke-width:4px GPU資産は巨額であるため、この減損損失は単なる費用ではなく、 巨額の「特別損失」 として損益計算書に計上されます。その結果、その期の利益（EPS）は大きく押し下げられ、株価に深刻な影響を与える可能性があります。 バーリー氏の主張は、この 「会計上の先送り」 が、AIブームのピークが過ぎ去った後、業界全体で一斉に発現するというシステミックなリスクを指摘しているのです。 ...

2025年10月30日、「世界初！暗号領域の情報が読み取れるSuicaビューア公開」という衝撃的な発表がX（旧Twitter）で大きな注目を集めました。しかし、このニュースに触れた多くのセキュリティ専門家は、その内容以前に、発表を行った企業の姿勢に強い懸念を抱いたのではないでしょうか。 問題となっているのは、アンノウン・テクノロジーズ株式会社です。同社は過去にもFeliCaの脆弱性を発見し、7月に関係機関へ報告したものの、修正が完了する前の8月に共同通信の取材に応じて未公開の脆弱性情報を公表し、物議を醸しました。これを受けて9月には経済産業省が、情報処理推進機構（IPA）と連携し、脆弱性情報の取り扱いに関する注意喚起を改めて行う事態にまで発展しています。 脆弱性を発見された方は、受付機関であるIPAへの届出を行っていただき、正当な理由がない限り脆弱性関連情報を第三者に開示せず、正当な理由により開示が必要である場合も事前にIPAに相談いただくようお願いいたします。 今回の発表は、こうした経緯を無視するどころか、さらに問題を深刻化させるものです。本稿では、なぜこの企業の行動が「ブラックハット的」と批判されるのか、その論点を整理し、セキュリティ企業に求められるべき倫理とは何かを考察します。 論点1: 無視された「責任ある開示」の原則 セキュリティの世界には、**「責任ある開示（Coordinated Vulnerability Disclosure, CVD）」**という、発見した脆弱性を扱うための世界共通の倫理規範が存在します。これは、脆弱性の発見者、製品開発者（ベンダー）、そして調整機関（日本ではIPA）が連携し、修正パッチが一般に提供されるタイミングで情報を公開するという、社会全体の安全性を最大化するための協調的なプロセスです。 アンノウン・テクノロジーズ社の行動は、この大原則を完全に踏みにじるものです。修正前に情報を公開することは、悪意ある第三者に攻撃のヒントを与えることに他ならず、ユーザーを無用な危険に晒す行為です。経済産業省が指摘する「正当な理由」とは、既に大規模な攻撃が発生しており、注意喚起が急務であるといった「今そこにある危機」に限定されるべきです。それ以外の理由でExploit（攻撃コード）に類する情報を公開することは、無責任の誹りを免れません。 実際、CEOがビューアに書き込み機能を付けていない、理由として「絶対残高を書き換える奴が出るので禁止してある」としていますが、経験上、読み込み系の機能があれば、ある程度、そこから、書き込みの機能を類推するのは可能です。つまり、コードの悪用可能性は十分認識しているはずです。そのような、状態で責任を負えるでしょうか？ ステップ 善意の技術者（正規のCVDプロトコル） アンノウン・テクノロジーズの行動（逸脱パターン） ① 発見・報告 脆弱性関連情報を発見後、まず中立機関であるIPAに届出し、情報を秘匿する。 脆弱性関連情報を発見後、IPAに届け出た後、あるいは前に情報を保持する。 ② 調整・通知 IPAはJPCERT/CCに通知。JPCERT/CCは秘密裏に製品開発者（ベンダー）を特定し、対策を依頼する。 このプロセスを尊重せず、秘密裏に行われている調整の途中で動く。 ③ 修正期間 製品開発者が対策パッチを作成する間、発見者は情報を第三者に漏らさない（非開示義務）。 この修正期間中に、一般メディア（共同通信）やSNS（X）へ情報を開示・宣言する。 ④ 公表 修正パッチが利用可能になったことを確認した上で、発見者・調整機関・ベンダーが同時に情報を公表する。 修正が完了する前に情報を公表し、社会的な混乱とベンダーの緊急対応を誘発する。 ⑤ 目的 社会全体のリスクを最小化し、ユーザーの安全を最優先する。 技術的なアテンション（注目）とビジネス上の宣伝効果を最優先する（と見なされる）。 論点2: 社会インフラを揺るがす無責任な行為 FeliCaは単なるICカード技術ではありません。日本の交通や決済を支える 極めて重要な社会インフラ の一部です。その根幹技術の信頼性を一方的に毀損する行為は、技術的な興味やビジネス上の利益をはるかに超えた、重大な社会的責任を伴います。 今回の件で、ソニーや関連事業者は、本来不要であったはずの緊急対応や調査に多大なリソースを割かざるを得なくなりました。こうしたコストは、巡り巡ってサービス利用料や製品価格に転嫁され、最終的には社会全体が負担することになります。技術的な脆弱性以上に、セキュリティコミュニティの信頼関係を破壊し、社会に無用な混乱とコストをもたらした「迷惑」は計り知れません。 論点3: 信頼を損なうFUDマーケティング 「世界初！」「衝撃的な発表」といった扇情的な言葉は、冷静かつ客観的であるべきセキュリティの報告には不要なものです。むしろ、こうした表現は、顧客の不安や恐怖を煽り、自社のサービスを売り込む FUD（Fear, Uncertainty, and Doubt）マーケティング の典型的な手法と見られても仕方ありません。CEOがXで「世界初！」と宣言した行為そのものがどう見てもアテンション中毒です。 真に顧客の安全を考えるプロフェッショナルは、いたずらに恐怖を煽るのではなく、静かにリスクを分析し、着実な対策を提示することで信頼を得ます。すべての行動が 「アテンション（注目）を獲得し、それをセールスに繋げる」 という短絡的な目的に集約されているように見える姿勢は、長期的な信頼関係を基礎とするセキュリティビジネスの倫理観とは相容れないものです。 論点4: 信頼性の根幹を揺るがす経営実態 さらに、同社の信頼性に疑問符を付けるのが、その経営実態です。 衝撃の事実①：資本金1万円 サイバーセキュリティは、顧客の事業継続に直結する極めて重要な領域です。その責任を担う企業が、事業継続性や万が一の際の補償能力を全く感じさせない資本金額であることは、事業へのコミットメントを疑わざるを得ません。 衝撃の事実②：バーチャルオフィス 登記上の住所である「東京都千代田区九段南」は、調査の結果、**コワーキングスペースの住所貸し（バーチャルオフィス）**であることが確認されています。物理的な拠点の有無が問題なのではありません。高度な機密情報を扱うセキュリティ企業が、その実態を曖昧にしかねないサービスを利用しているという事実が、顧客の信頼を損なうのです。 これらは、高度な専門企業を装う 「見栄（外見）」と「実態（資金力と責任感）」 の深刻な乖離を示しており、組織としての信頼性を根底から揺るがすものです。 結論: 我々は何を基準に専門家を選ぶべきか アンノウン・テクノロジーズ社の一連の行動は、IT業界に身を置く者として、レッドラインを越えています。これは、技術力さえあれば何をしても許されるという、危険な前例になりかねません。 企業や個人がセキュリティの専門家やパートナーを選ぶ際には、その技術力だけでなく、高い倫理観、社会に対する責任感、そしてそれを裏付ける安定した経営基盤 を持っているかどうかを、これまで以上に厳しく見極める必要があります。今回の事例は、その重要性を改めて我々に突きつける、重い教訓と言えるでしょう。

はじめに 2025/10/20のAWSの大規模障害から、2日目の朝が過ぎ、色々と見えてきました。ITmediaの記事によれば、原因や経緯は以下のように説明されています。 AWSによれば、今回の障害は「リージョンのDynamoDBサービス（注：AWSのデータベースサービス）エンドポイントのDNS解決の問題」が原因だったという。同社は20日午後6時ごろに問題を解決したものの、今度はDynamoDBに依存するEC2インスタンスの起動システムに問題が発生。対応するうちにトラフィックを分散する「Network Load Balancer」にも問題が生じ、再びDynamoDBなど複数サービスに影響したため、EC2インスタンスの起動など一部サービスの操作を一時的に抑制して復旧に当たったとしている。 DNSのSPoF化 とはいえ、この事実はかなりな、ナンセンスさを内包しています。本来、DNSは冗長な権威サーバー群によって提供され、キャッシュも活用されるため、単一のサーバーやソフトウェアがダウンしてもシステム全体は生き残るように設計されています。しかし、AWSの報告は、DynamoDBというクリティカルな内部サービスのDNS解決が、特定の脆弱なコンポーネントに集中し、それが停止することで、誰も住所を見つけられない状態、すなわち　「内部の単一障害点（SPOF）」　になっていたことを示しています。 認証基盤への影響の軽視 DynamoDBの停止は、IAMなど認証基盤の裏側にも影響しました。この認証基盤がDNSに依存していた、あるいはDNSが停止した時のフェイルオーバー（切り替え）の仕組みが不十分だったこともナンセンスです。 AWSは、 「誰がアクセスしているか」 という最も重要な制御システムを、DNSという単一障害のリスクから十分に隔離できていなかったことになります。 復旧時の二次災害（NLBの問題） さらにナンセンスなのは、DNS問題を解決した後、今度はNLB（Network Load Balancer）の設計が、回復したDynamoDBへのリトライ・ストームに耐えきれず、再びサービスに影響を与えた点です。 これは、AWSのエンジニアが 「自社のトラフィック分散機構が、自社のサービスから発生する負荷（リトライ）で崩壊する」 という最悪のシナリオを十分に想定できていなかったことを示唆しています。 秘伝のたれ：文書化されない知識の蔓延 今回のAWS大規模障害、特に 「内部DNSの設計ミス」と「DynamoDBとNLBの連鎖崩壊」という「話にならなすぎる」原因は、巨大なクラウドインフラ内部に「文書化されていない秘伝のたれ（Undocumented Tribal Knowledge）」 が横行していることの、動かぬ証拠です。「秘伝のたれ」とは、特定のエンジニアやチームだけが知っている、システムの機能に不可欠だが公式には文書化されていない知識、調整、あるいは非標準的な設定を指します。 実際に、The Registerの記事に目を覆いたくなるような記述があります。 “It’s always DNS” is a long-standing sysadmin saw, and with good reason: a disproportionate number of outages are at their heart DNS issues. And so today, as AWS is still repairing its downed cloud as this article goes to press, it becomes clear that the culprit is once again DNS. But if you or I know this, AWS certainly does. ...