タグ

ブックマーク / knqyf263.hatenablog.com (31)

  • OSSをベースにしたサービス提供の難しさ - knqyf263's blog

    背景 難しさ 利益相反になりがち 競合OSSの存在 コミュニティからのPull Request 競合サービスによる利用 レベニューシェアにならない 利用統計が取れない やっておくべきこと お金を払いたい機能を見極める 境界線を決める ライセンスについて考える 利用統計の取得方法について考える OSSから有償版へのスムーズな移行を考える まとめ 背景 弊社(Aqua Security)ではOSS開発をしており、そのOSSを組み込んだ有償サービスを売ることで利益を上げています。 自分はその中のOSS開発をフルタイムで担当しています。 会社は何を目的としてOSS開発をしているのか、というのは以前発表しました。 speakerdeck.com フルタイムOSS開発者をやってみての感想なども昔書いています。 knqyf263.hatenablog.com 今回はOSSをベースにしたサービス提供の難し

    OSSをベースにしたサービス提供の難しさ - knqyf263's blog
  • 至高のGoプラグイン用ツールを作った - knqyf263's blog

    最近YouTuberのリュウジの料理を毎日作っているので至高とか無限とか言いがちですが個人の感想です。万人にとって美味しい料理はないように、万人にとって至高のツールは存在しません(何の話?)。ちなみに公開してすぐバグを見つけてしまったので全然至高じゃありませんでした。 要約 概要 特徴 使い方 流れ 事前準備 インタフェースの定義 SDKの生成 プラグインの実装 ホストの実装 実行 発展 Host Functions ファイルアクセス その他 苦労した点 まとめ 要約 Goでプラグイン機構を実現するためのツールを作りました。Protocol Buffersのスキーマからコードを自動生成するので簡単にプラグイン機構を実現可能です。内部的にはWebAssemblyWasm)を使っています。最近はWasmはブラウザ外での利活用が進んでおり、今回のツールもブラウザは一切関係ないです。Wasmはサ

    至高のGoプラグイン用ツールを作った - knqyf263's blog
  • GoのWasmランタイム上でZigで作ったWasmモジュールを動かす - knqyf263's blog

    Zigのコミッタの方から有益なフィードバックを頂いたり、Wasmランタイムのメンテナからコメントしてもらったり、Twitterでプロ開発者に助けてもらったり、と良い話が多かったのでそのへんの話も含めつつメモとして残しておきます。 最初に断っておきますがWasmにもZigにも特に詳しくないです。 概要 実装 GoWasmランタイム TinyGoのExample ランタイムの初期化 関数の実行 別の渡し方 Zigの実装 malloc free ptrToString stringToPtr 呼び出し側 サンプル まとめ 概要 自分の開発しているOSSでWebAssemblyによるプラグイン機能に対応したのですが*1、Wasmは仕様が小さく関数の引数や戻り値もi32/i64/f32/f64だけで頑張るみたいな世界なので直接ユーザに生のWasm用コードを書いてもらうのは利便性の面で厳しいです。*

    GoのWasmランタイム上でZigで作ったWasmモジュールを動かす - knqyf263's blog
  • Dirty Pipe(CVE-2022-0847)の発見経緯が面白かった - knqyf263's blog

    最初に断っておくと今回は万人向けの記事ではないです。面白かったので自分が忘れないようにまとめているだけです。 記事の位置付け はじめに 発見経緯 CRCのエラー HTTPアクセスログ 壊れたgzipのtrailerを見てみる 壊れたファイルの法則性 月次ログファイルの生成 Linuxカーネルのバグの可能性 バグ混入の歴史 ログ破損の原因 8バイトの謎 PoCの制約 まとめ 記事の位置付け Dirty Pipe(CVE-2022-0847)三部作の最後です。ダークナイト三部作で言うとダークナイト ライジングにあたります。ダーティとダークって似てませんか。 spliceを使って高速・省メモリでGzipからZIPを作る 20分で分かるDirty Pipe(CVE-2022-0847) Dirty Pipe(CVE-2022-0847)の発見経緯が面白かった(記事) 上の1, 2を前提知識と

    Dirty Pipe(CVE-2022-0847)の発見経緯が面白かった - knqyf263's blog
  • セキュリティツールの評価は難しい - knqyf263's blog

    前から思ってたことをちょっと書かずにいられなくなったのでポエムを書きました。 背景 問題 検知している方が正しいように見えがち 条件を揃えるのが難しい 環境の再現が難しい 検知数が多い方が良さそうに見える 正解かどうかの判断が難しい カバー範囲の正確な見極めが難しい 検知されないほうが嬉しい まとめ 背景 お前誰だよってなるかもしれないので書いておくと、Trivyという脆弱性スキャナーのメンテナをやっています。 github.com とある有名な方による以下のツイートがありました。 I just discovered, during @cloudflare #SecurityWeek no less, that Trivy (the vuln scanner) doesn't detect known issues in Alpine images. Including a critica

    セキュリティツールの評価は難しい - knqyf263's blog
  • 20分で分かるDirty Pipe(CVE-2022-0847) - knqyf263's blog

    極限まで詳細を省けば何とか20分で雰囲気だけでも伝えられるんじゃないかと思って書きました。書き終えてから見返したら多分無理なので誇大広告となったことを深くお詫び申し上げます。 背景 概要 脆弱性の影響 ページキャッシュやsplice パイプ マージの可否 下準備 攻撃手順 まとめ 背景 先日Dirty PipeというLinuxカーネルの脆弱性が公表されました。 dirtypipe.cm4all.com Linuxのパイプに関する脆弱性なのですが、仕組みは意外とシンプルでぎりぎりブログでも伝わるかもしれないと思ったので自分の理解を書きました。あといつも細かく書きすぎて長くなるので、今回は雰囲気だけでも伝わるようにとにかく説明を簡略化し、ふわっとした概要だけでも理解してもらえるように頑張りました。その結果、若干正確性に欠ける部分があるかもしれませんがお許しください。細かい部分はまた別の記事でま

    20分で分かるDirty Pipe(CVE-2022-0847) - knqyf263's blog
  • sigstoreによるコンテナイメージやソフトウェアの署名 - knqyf263's blog

    恐ろしく長い上に割と複雑なので最後まで読む人はほとんどいないと思うのですが、将来確実に忘れてしまう自分のために書いたので別に悲しくありません。 まえがき 背景 sigstoreの概要 sigstoreを構成するツール群 Cosign Rekor Fulcio 署名方法 コンテナイメージ 鍵ペアの生成 署名 検証 Blobs 鍵ペアの生成 署名 検証 署名の仕組み コンテナイメージ OCI Registryについて 署名の保存先 署名フォーマット 署名検証 検証が不十分な例 Blobs 参考 まとめ まえがき 鍵の管理不要でソフトウェア署名を可能にするKeyless Signingについて解説を書こうと思い、まず前提知識を書いていたら信じられないぐらい長くなったので前提知識だけで1つの記事になりました。 後述するsigstoreは急速に開発が進んでいるプロジェクトであり、ここで書いている記述

    sigstoreによるコンテナイメージやソフトウェアの署名 - knqyf263's blog
  • Docker DesktopからRancher Desktopに乗り換えてみた - knqyf263's blog

    この記事はPRを含みます。 概要 背景 移行 Docker Desktopのアンインストール Rancher Desktopのインストール Kubernetesクラスタの無効化 宣伝 まとめ 概要 Rancher Desktopがcontainerdに加えdockerにも対応したのでDocker Desktopから乗り換えてみました。簡単な用途だとdockerコマンドがそのまま使えるので特に困っていません。 背景 2021年9月にDocker Desktopが有料化されました。移行期間として2022年1月31まで引き続き無料で利用できましたが、それもついに終了しました。 www.docker.com ただし、個人利用もしくはスモールビジネス(従業員数250人未満かつ年間売上高1000万ドル未満)、教育機関、非商用のオープンソースプロジェクトでは引き続き無料で利用できるという条件でした。no

    Docker DesktopからRancher Desktopに乗り換えてみた - knqyf263's blog
  • 自分でやるべき(ように思える)ことを得意な誰かに任せるという考え方 - knqyf263's blog

    完全なるポエムです。自分にとって斬新な考え方だったので思わず勢いで書いていますが、知っている人からすると当たり前ですし、冷静に読み返すとだから何だよという内容に仕上がっています。読んだあとにだから何だよと言われても責任は取れません。 はじめに とある方の話 他人に任せる 記事執筆 社外発表 社内発表 マネージメント まとめ はじめに 以前、苦手分野を思い切って捨てて得意分野に集中してみるという話を書かせていただきました。 engineer-lab.findy-code.io 今回も通ずるところはあるのですが、一歩踏み込んで自分の気の進まないことはいっそ得意な誰かに任せようという話です。一歩引いた視点で見れば上のブログの話も結局誰かが自分の穴を埋めてくれているので同じに見えると思うのですが、自分の気の持ちようとしては大きく異なるので書いています。つまり、これ苦手だけど一生懸命やってるので許し

    自分でやるべき(ように思える)ことを得意な誰かに任せるという考え方 - knqyf263's blog
  • PHPでログファイルへの読み書きを通して任意コード実行をする方法 - knqyf263's blog

    以前少し話題になったLaravelのデバッグモード有効時の脆弱性であるCVE-2021-3129のPoCを読んでいたのですが、思ったより難しくて何でこんなことをしているんだろうと思ったら発見者による解説ブログがありました。読んでみたらバイパスのために思ったより色々していて普通に勉強になったのでメモを残しておきます。CTFerからすると常識な内容かもしれないので、何か間違いや補足があれば指摘をお願いします。 www.ambionics.io 前提知識1 前提知識2 題 問題点 = によるエラー 日付のデコード ログファイル内の他エントリ バイパス方法 consumedの利用 iconvの利用 パディングの利用 UTF-16のための調整 NULLバイトの回避 最終形 まとめ 前提知識1 上の脆弱性を理解するためにはいくつかの前提知識を必要とするため最初にまとめておきます。 まず、PHPでは外

    PHPでログファイルへの読み書きを通して任意コード実行をする方法 - knqyf263's blog
  • 英語ミーティングを乗り切るために身につけたバッドノウハウ - knqyf263's blog

    周りを見ていると何の苦もなく英語社会に適応しているわけですが、日々苦しんでいる人の奮闘記があっても良いのではないかと思って書きました。残念なエピソードを晒すことで実は自分もこうやって乗り切ってましたという人が現れお互いに助け合えることを期待しています。 概要 前提 バッドノウハウ 質問編 聞き取れなかった時にSorry?と聞き直さない 聞こえたところまで繰り返す 可能性のある質問全てに答える Do you mean ~ ? で可能性を潰していく うかつにYES/NOで答えない 他人に振ってみる 良い質問ですねぇを使う 何か言いそうな雰囲気を出して時間を稼ぐ 発言編 How are you?を速攻でキメる Can you hear me? Can you see my screen? に率先して答える How are you?にHow are you?で返す 発表編 話し続ける 質問が出ない

    英語ミーティングを乗り切るために身につけたバッドノウハウ - knqyf263's blog
  • 趣味で作ったソフトウェアが海外企業に買われ分野世界一になるまでの話 - knqyf263's blog

    2年前の2019年8月に以下のブログを書きました。 knqyf263.hatenablog.com 今回はその続きです。前回のブログは多くの人に読んでもらうことを意識して書きましたが、今回はそうではないです。特に得た学びを書くわけでもなく何で作り始めたのか?とかどんなことがあったのか?とか思い出話を書いているだけなので、言ってしまえば自己満足の記事です。それで構わない人や前回の記事を見てその後どうなったか気になった人だけが読んでもらえますと幸いです。 誰かのためになるわけでもない過去の出来事について語るのは老人感が強くて基的に好きではないのですが、自分の中で一番大きかった目標を達成したので節目として書いています。 英語版の記事も会社のブログから公開しています。英語版のほうが簡潔で良い可能性もあります。日語版は誤った解釈をされると嫌だからもう少し詳細に書こう、を繰り返していつも長くなりす

    趣味で作ったソフトウェアが海外企業に買われ分野世界一になるまでの話 - knqyf263's blog
  • Terraform, Dockerfile, KubernetesなどIaCの脆弱な設定をCI/CDで検知する - knqyf263's blog

    概要 自分の所属企業であるAqua SecurityがTFsecというOSSを買収しました。 blog.aquasec.com TFsecはどういうツールかというとTerraformの静的解析スキャナーです。Terraformの設定ファイルを渡すことでセキュリティに関する設定ミスを主に検知してくれます。 github.com そのアナウンスに伴い、TFsecは自分が開発している脆弱性スキャナーであるTrivyに統合されました。TrivyではTerraformに加えDockerfileやKubernetesなど、いわゆるInfrastructure as Code(IaC)の設定ミスを検知するマネージドポリシーも提供しています。他にもJSONやYAMLなど一般的なファイルフォーマットに対応しているため自分でポリシーを書くことでそれらの検知にも使えます。CloudFormationやAnsib

    Terraform, Dockerfile, KubernetesなどIaCの脆弱な設定をCI/CDで検知する - knqyf263's blog
  • コンテナイメージのlazy pullingをcurlで試してみる - knqyf263's blog

    はじめに 参考 Stargz 概要 詳細 HTTP Range 互換性 Stargzまとめ eStargz 概要 最適化 TOC, TOCEntry Footer Stargz Snapshotter eStargzまとめ 実験 トークン取得 インデックス取得 マニフェスト取得 Footer取得 TOC取得 ファイル取得 実験まとめ 余談 応用例 自作ライブラリ 計測 まとめ はじめに コンテナイメージのlazy pullingが各ツールで利用可能になりつつあるようです。以下は stargz-snapshotter のメンテナである @TokunagaKohei さんによるブログです。 medium.com lazy pullingが何かを簡単に説明しておくと、コンテナイメージ全体を最初にpullせずにコンテナ実行後に必要なファイルのみを遅延でpullするものです。docker runしよ

    コンテナイメージのlazy pullingをcurlで試してみる - knqyf263's blog
  • TrivyがRed Hatの認定脆弱性スキャナーになりました - knqyf263's blog

    概要 日、Red HatからRed Hat Vulnerability Scanner Certificationという脆弱性スキャナーに対する認定プログラムが発表されました。 www.redhat.com そして上の発表の中で私の所属企業であるAqua Securityも認定を受けたことが書かれています。つまり自分が業務として開発しているTrivyというOSSの脆弱性スキャナーもRed Hatの認定を受けたことになります(というか実はTrivyだけなのですが詳細は後述)。自分のブログを見る人は既に存在は知ってくれていると思いますが一応貼っておきます。 github.com 現在認定を受けているのは Aqua Security, NeuVector, Sysdigの3社だけです。NeuVectorとSysdigは商用製品で認定を受けているはずなので、3rd partyのOSSスキャナーで

    TrivyがRed Hatの認定脆弱性スキャナーになりました - knqyf263's blog
  • Goのバイナリから依存するmodule情報を取り出す方法 - knqyf263's blog

    概要 内部挙動 ELFバイナリの準備 .go.buildinfo section Goのバージョン module情報 ldflagsについて Goのソースコード .go.buildinfo マジックバイト Goのバージョン情報へのポインタ module情報へのポインタ EXEファイルの処理 余談 まとめ 概要 Goでビルドしたバイナリは色々な情報を含んでいます。例えばビルドに使用したGoのバージョンを取得できます。 $ go version ./test ./test: go1.15.2 そしてついこの間知ったのですが、 -m オプションを使うことで利用しているmoduleの情報も取得可能です。 $ go version -m /usr/local/bin/terraform /usr/local/bin/terraform: go1.14.9 path github.com/hashic

    Goのバイナリから依存するmodule情報を取り出す方法 - knqyf263's blog
  • DNSpooqの脆弱性詳細と攻撃コード解説 - knqyf263's blog

    概要 要約 詳細 背景 前提 インターネット上に公開されたdnsmasq LAN内のマシンが攻撃者の支配下にある LAN内のマシンに攻撃者管理のWebサイトを閲覧させることができる 影響 中間者攻撃 汚染拡大 DDoS/Reverse DDoS CVE-2020-25684: ポートの多重化 CVE-2020-25685: 脆弱なCRC32の利用 CVE-2020-25686: 同一ドメイン名に対する複数クエリ発行 DNSフォワーダにおけるレスポンスの未検証 組み合わせる ドメイン名の登録 ソースIPアドレスの偽装 CRC32の衝突 攻撃の流れ ブラウザからの攻撃 検証端末 攻撃の成功確率 PoC fowarder cache attacker 大量クエリの送信 偽装レスポンスの送信 高速化の話 実行 対策・緩和策 余談 まとめ 概要 先日DNSpooqという脆弱性が公開されました。 ww

    DNSpooqの脆弱性詳細と攻撃コード解説 - knqyf263's blog
  • KubernetesのLoadBalancerやClusterIPを用いた中間者攻撃(CVE-2020-8554) - knqyf263's blog

    今回は前回と違いライトなネタです。 概要 Kubernetesで新しい脆弱性(CVE-2020-8554)が公開されました。 github.com 拍子抜けするほど簡単な脆弱性なのですが、一応試しておきました。発見者の方のブログも以下にあります。 blog.champtar.fr 今回の脆弱性はServiceのtype: LoadBalancer/ClusterIPを悪用して行う中間者攻撃(MITM)なのですが、ブログの中でMITM as a Serviceと評していたのが面白かったです。KubernetesがMITMを簡単に代行してくれるという意味でas a Service感強いですし、今回悪用するリソースタイプもServiceなので二重にかかっていて好きです。 要約 前提 攻撃者が以下のいずれかの権限を持つ場合 type: ClusterIPのServiceを作成可能かつspec.ex

    KubernetesのLoadBalancerやClusterIPを用いた中間者攻撃(CVE-2020-8554) - knqyf263's blog
  • SAD DNSのICMP rate limitを用いたサイドチャネル攻撃について - knqyf263's blog

    脆弱性ネタは人気がないことが過去の傾向から明らかですが、自分が震えるほど感動したので忘れないためにも気合い入れて大作を書きました。 要約 背景 SAD DNSの解説 全体像 UDPのソースポートについて ICMP rate limit per-IP rate limit global rate limit Public-Facing Source Portのスキャン Private Source Portのスキャン 攻撃Windowの拡張 サイドチャネル攻撃でUDPソースポートを推測してみる 対策 攻撃実現性 まとめ 要約 ちゃんと理解するの結構難しいという話があったので、先に要約しておきます。雰囲気だけでも掴んでもらえると嬉しいです。 DNSキャッシュポイズニングの新しい手法としてSAD DNSが発表された キャッシュポイズニングのためには権威DNSサーバ正規の応答を返すより先に攻撃者が

    SAD DNSのICMP rate limitを用いたサイドチャネル攻撃について - knqyf263's blog
  • Semantic Versioningの闇 - knqyf263's blog

    今回も誰も興味ないシリーズなので今まで書いてこなかったのですが、Semantic Versioningに関して幻想を抱いている人がいる可能性があり、そういう方にどうしても現実を知っておいて欲しかったので書きました。3行要約(と可能なら余談)だけでも読んでいただけると幸いです。 3行要約 Semantic Versioning 2.0.0にはバージョン"比較"の定義はあるが、バージョン"制約"(>= 2.1.3みたいなやつ)の定義がない その結果、同じsemver準拠ライブラリでも制約の解釈が異なり結果が真逆になる というかそもそもsemver使ってるエコシステムが少なすぎる 背景 セキュリティアドバイザリでは特定のバージョンが脆弱であることを示すためにバージョン制約が使われることが多いです。例えば >=1.2.0 <1.2.6みたいなやつです。この場合、1.2.5は脆弱だが1.2.6は修正

    Semantic Versioningの闇 - knqyf263's blog