サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
掃除・片付け
knqyf263.hatenablog.com
周りを見ていると何の苦もなく英語社会に適応しているわけですが、日々苦しんでいる人の奮闘記があっても良いのではないかと思って書きました。残念なエピソードを晒すことで実は自分もこうやって乗り切ってましたという人が現れお互いに助け合えることを期待しています。 概要 前提 バッドノウハウ 質問編 聞き取れなかった時にSorry?と聞き直さない 聞こえたところまで繰り返す 可能性のある質問全てに答える Do you mean ~ ? で可能性を潰していく うかつにYES/NOで答えない 他人に振ってみる 良い質問ですねぇを使う 何か言いそうな雰囲気を出して時間を稼ぐ 発言編 How are you?を速攻でキメる Can you hear me? Can you see my screen? に率先して答える How are you?にHow are you?で返す 発表編 話し続ける 質問が出ない
今回はソフトウェアエンジニアじゃない人や学生にも、ソフトウェアエンジニアという職業には夢があるかもしれないと思ってもらうために書いています。そのため既に詳しい方からすると回りくどい説明も多いと思いますがご容赦下さい。 基本的に記事とかには技術的なことしか書かないスタンスでやってきましたが、今回の件はさすがに誰かに伝えておくべきだろうということで長々と垂れ流しました。 概要 GW中に趣味で開発したソフトウェアを無料で公開したところAqua Securityという海外企業(アメリカとイスラエルが本社)から買収の申し出を受け、最終的に譲渡したという話です。さらに譲渡するだけでなく、Aqua Securityの社員として雇われて自分のソフトウェア開発を続けることになっています。つまり趣味でやっていたことを仕事として続けるということになります。 少なくとも自分の知る限り一個人で開発していたソフトウェ
2年前の2019年8月に以下のブログを書きました。 knqyf263.hatenablog.com 今回はその続きです。前回のブログは多くの人に読んでもらうことを意識して書きましたが、今回はそうではないです。特に得た学びを書くわけでもなく何で作り始めたのか?とかどんなことがあったのか?とか思い出話を書いているだけなので、言ってしまえば自己満足の記事です。それで構わない人や前回の記事を見てその後どうなったか気になった人だけが読んでもらえますと幸いです。 誰かのためになるわけでもない過去の出来事について語るのは老人感が強くて基本的に好きではないのですが、自分の中で一番大きかった目標を達成したので節目として書いています。 英語版の記事も会社のブログから公開しています。英語版のほうが簡潔で良い可能性もあります。日本語版は誤った解釈をされると嫌だからもう少し詳細に書こう、を繰り返していつも長くなりす
この記事は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
今回も誰も興味ないシリーズなので今まで書いてこなかったのですが、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は修正
背景 難しさ 利益相反になりがち 競合OSSの存在 コミュニティからのPull Request 競合サービスによる利用 レベニューシェアにならない 利用統計が取れない やっておくべきこと お金を払いたい機能を見極める 境界線を決める ライセンスについて考える 利用統計の取得方法について考える OSSから有償版へのスムーズな移行を考える まとめ 背景 弊社(Aqua Security)ではOSS開発をしており、そのOSSを組み込んだ有償サービスを売ることで利益を上げています。 自分はその中のOSS開発をフルタイムで担当しています。 会社は何を目的としてOSS開発をしているのか、というのは以前発表しました。 speakerdeck.com フルタイムOSS開発者をやってみての感想なども昔書いています。 knqyf263.hatenablog.com 今回はOSSをベースにしたサービス提供の難し
前から思ってたことをちょっと書かずにいられなくなったのでポエムを書きました。 背景 問題 検知している方が正しいように見えがち 条件を揃えるのが難しい 環境の再現が難しい 検知数が多い方が良さそうに見える 正解かどうかの判断が難しい カバー範囲の正確な見極めが難しい 検知されないほうが嬉しい まとめ 背景 お前誰だよってなるかもしれないので書いておくと、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
極限まで詳細を省けば何とか20分で雰囲気だけでも伝えられるんじゃないかと思って書きました。書き終えてから見返したら多分無理なので誇大広告となったことを深くお詫び申し上げます。 背景 概要 脆弱性の影響 ページキャッシュやsplice パイプ マージの可否 下準備 攻撃手順 まとめ 背景 先日Dirty PipeというLinuxカーネルの脆弱性が公表されました。 dirtypipe.cm4all.com Linuxのパイプに関する脆弱性なのですが、仕組みは意外とシンプルでぎりぎりブログでも伝わるかもしれないと思ったので自分の理解を書きました。あといつも細かく書きすぎて長くなるので、今回は雰囲気だけでも伝わるようにとにかく説明を簡略化し、ふわっとした概要だけでも理解してもらえるように頑張りました。その結果、若干正確性に欠ける部分があるかもしれませんがお許しください。細かい部分はまた別の記事でま
概要 自分の所属企業である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
最近脆弱性の話とか本業と一切関係ないことを書いていたので、今回は本業に関する話です。 前提 所感 楽しい やりがいがある 実績になる 得意な形でアウトプットできる 勉強になる 深く特定領域を学べる 得た知見を公の場で共有しにくい 広く触れない(可能性がある) なぜ会社としてOSSをやるのか?ということを真剣に考えられる 市場の熟成 有料化のしやすさ 品質の向上 カンファレンスでの発表 ファンを作る 会社の売上に貢献できる方が精神的に楽 ユーザからのフィードバックが助かる メンテナンスコストが高くなる 方針を決められなくなる 宣伝は必要 まとめ 2019/08/01にOpen Source Engineerという肩書になってから既に1年が経過しました。そういうポジションの人はまだ日本では少ないんじゃないのかなと思ったので何か参考になればと所感を書いておきます。ちなみに最初の頃Open Sou
最初に断っておくと今回は万人向けの記事ではないです。面白かったので自分が忘れないようにまとめているだけです。 本記事の位置付け はじめに 発見経緯 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を前提知識と
完全なるポエムです。自分にとって斬新な考え方だったので思わず勢いで書いていますが、知っている人からすると当たり前ですし、冷静に読み返すとだから何だよという内容に仕上がっています。読んだあとにだから何だよと言われても責任は取れません。 はじめに とある方の話 他人に任せる 記事執筆 社外発表 社内発表 マネージメント まとめ はじめに 以前、苦手分野を思い切って捨てて得意分野に集中してみるという話を書かせていただきました。 engineer-lab.findy-code.io 今回も通ずるところはあるのですが、一歩踏み込んで自分の気の進まないことはいっそ得意な誰かに任せようという話です。一歩引いた視点で見れば上のブログの話も結局誰かが自分の穴を埋めてくれているので同じに見えると思うのですが、自分の気の持ちようとしては大きく異なるので書いています。つまり、これ苦手だけど一生懸命やってるので許し
概要 要約 詳細 背景 前提 インターネット上に公開された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
最近YouTuberのリュウジの料理を毎日作っているので至高とか無限とか言いがちですが個人の感想です。万人にとって美味しい料理はないように、万人にとって至高のツールは存在しません(何の話?)。ちなみに公開してすぐバグを見つけてしまったので全然至高じゃありませんでした。 要約 概要 特徴 使い方 流れ 事前準備 インタフェースの定義 SDKの生成 プラグインの実装 ホストの実装 実行 発展 Host Functions ファイルアクセス その他 苦労した点 まとめ 要約 Goでプラグイン機構を実現するためのツールを作りました。Protocol Buffersのスキーマからコードを自動生成するので簡単にプラグイン機構を実現可能です。内部的にはWebAssembly(Wasm)を使っています。最近はWasmはブラウザ外での利活用が進んでおり、今回のツールもブラウザは一切関係ないです。Wasmはサ
DNSは趣味でやっているだけですし有識者のレビューを経ているわけでもないので誤りを含むかもしれませんが、DNS界隈には優しい人しかいないのできっと丁寧に指摘してくれるはずです。 追記:めちゃくちゃ丁寧にレビューしていただいたので修正いたしました。森下さんほどの方に細かく見ていただいて恐れ多いです...(学生時代に某幅広合宿で森下さんの発表を見てDNSセキュリティに興味を持った) 4万文字を超える大作、おつかれさまです。わかりやすく書けていると思いました。 ざっと読んで、コメントしてみました。ご参考まで。https://t.co/bVj5WeFHQr https://t.co/ku5NOx6ua8— Yasuhiro Morishita (@OrangeMorishita) 2024年2月19日 要約 背景 詳細 DNSSECとは? DNSSECの可用性 鍵タグの衝突 攻撃内容 SigJam
Trivyのv0.17.0をリリースしました。 github.com 長い道のりでしたが、ようやくこれでGoバイナリの脆弱性検知に対応できました。夜中0時ぐらいからリリース作業を初めて気付いたら朝5時でした。 概要 Go言語で書かれたプログラムをビルドすると依存しているモジュールがバイナリに含まれます。現代のソフトウェア開発において利用しているOSSのライブラリが0ということはまれなので、何かしらのOSSライブラリが作成されたバイナリに同梱されます。これらのOSSの古いバージョンには既知の脆弱性が含まれる可能性があります。これを手動で調べて追うのは手間なので最近では脆弱性スキャナを用いて検知するのが普通です。自分が開発したTrivyというOSSの脆弱性スキャナではコンテナイメージやファイルシステム上のGoバイナリに含まれるモジュールを特定し脆弱性を検知します。 Goのバイナリからどうやって
前提 Node.jsのプロトタイプ汚染について書いているのですが、プロトタイプの説明(prototype と __proto__ の関係とか)を定期的に見直さないと綺麗サッパリ忘れる程度にはNode.js触っていないので、何かおかしいところあればご指摘お願いします。 概要 Node.jsではここ数年プロトタイプ汚染攻撃が流行っています。概要は以下を見れば分かると思います。 jovi0608.hatenablog.com そもそもプロトタイプって何?という人は以下の記事が分かりやすいです。自分はお守りのように定期的に読んでます。 qiita.com 外部から送られてきたJSONなどをパースして変換し、そのオブジェクトをmergeやcloneする際に __proto__ を上書きすることで Object.prototype を汚染するというものです。このオブジェクトが書き換えられると、新しく作
脆弱性ネタは人気がないことが過去の傾向から明らかですが、自分が震えるほど感動したので忘れないためにも気合い入れて大作を書きました。 要約 背景 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サーバ正規の応答を返すより先に攻撃者が
普段あまりこういう誰の役に立つのか分からない記事は書かないのですが、解析をするまでの背景がOSSに関するとても良い話なので重い腰を上げて書きました。 概要 古のアプリケーション組み込み型のデータベースとしてBerkeley DBがあります。元々はカリフォルニア大学バークレー校によって開発され、その後Oracleによって買収されています。データ操作にSQLは使えず、アプリケーションに埋め込んで使用します。RDBまでは必要ないけどちょっとしたDBが必要みたいな時に使われているようです。機能はシンプルで組み込みのため性能も良いとのこと。詳しくは以下に書いてます。 docs.oracle.com 本記事ではそのBerkeley DBの中身がどのように実装されているのかの雰囲気を記します。Berkeley DBはBtree accessやHash access, Queue/Recno access
以前少し話題になったLaravelのデバッグモード有効時の脆弱性であるCVE-2021-3129のPoCを読んでいたのですが、思ったより難しくて何でこんなことをしているんだろうと思ったら発見者による解説ブログがありました。読んでみたらバイパスのために思ったより色々していて普通に勉強になったのでメモを残しておきます。CTFerからすると常識な内容かもしれないので、何か間違いや補足があれば指摘をお願いします。 www.ambionics.io 前提知識1 前提知識2 本題 問題点 = によるエラー 日付のデコード ログファイル内の他エントリ バイパス方法 consumedの利用 iconvの利用 パディングの利用 UTF-16のための調整 NULLバイトの回避 最終形 まとめ 前提知識1 上の脆弱性を理解するためにはいくつかの前提知識を必要とするため最初にまとめておきます。 まず、PHPでは外
良い話を含むので概要の最初だけでも読んでもらえると幸いです。この話が実用的かと言うと多分全然実用的ではないので理解しても仕方ないかなと言う気がします。 概要 ファイルフォーマット gzip 10-byteのヘッダ 拡張ヘッダ ファイル本体 フッタ(trailer) zip ローカルファイルヘッダ Data descriptor セントラルディレクトリエントリ セントラルディレクトリの終端レコード gzipからzipへの変換 gzipヘッダの処理 gzipファイル本体の処理 gzip trailerの処理 複数gzipファイルの連結 PoC まとめ 概要 先日Dirty PipeというLinuxカーネルの脆弱性が公表されました。 dirtypipe.cm4all.com この脆弱性の原理自体も面白いのですが、その前に報告者の組織で行っているGzipとZIPの処理で引っかかったのでまず先にそち
恐ろしく長い上に割と複雑なので最後まで読む人はほとんどいないと思うのですが、将来確実に忘れてしまう自分のために書いたので別に悲しくありません。 まえがき 背景 sigstoreの概要 sigstoreを構成するツール群 Cosign Rekor Fulcio 署名方法 コンテナイメージ 鍵ペアの生成 署名 検証 Blobs 鍵ペアの生成 署名 検証 署名の仕組み コンテナイメージ OCI Registryについて 署名の保存先 署名フォーマット 署名検証 検証が不十分な例 Blobs 参考 まとめ まえがき 鍵の管理不要でソフトウェア署名を可能にするKeyless Signingについて解説を書こうと思い、まず前提知識を書いていたら信じられないぐらい長くなったので前提知識だけで1つの記事になりました。 後述するsigstoreは急速に開発が進んでいるプロジェクトであり、ここで書いている記述
概要 前回Node.jsのプロトタイプ汚染を起こすためのバイパス方法について記事にしました。 knqyf263.hatenablog.com プロトタイプ汚染後に何が出来るのか、ということについては基本的にアプリケーション依存なのであまり話題になることは少ないです。 自分の知る限り一番多いのは if(user.isAdmin) { // do something } といったような重要なプロパティを書き換えることで権限昇格する例です。ただし、自分の理解では isAdmin が初期化されていないことが前提条件として必要です。 const obj1 = {}; const obj2 = JSON.parse('{"__proto__":{"isAdmin":true}}'); merge(obj1, obj2) var a = {} a.isAdmin // true var b = {isA
概要 内部挙動 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
はじめに 参考 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しよ
概要 Redisを間違ってインターネットに開放してしまっていた場合に、認証がなければ好きなRedisコマンドを実行されてしまいます。この場合に最大どの程度の被害になるのか、というのがセキュリティ界隈の人にも意外と知られていなかったので書いておきます。 Redisの実行ユーザによりますがrootなどで動いていて、他にいくつか緩い条件を満たせばOSの任意コマンドが実行可能です。 これは昔からある方法で有名なので攻撃する側からすると当然知っていて、侵入したら必ずと言っていいほど行うと思います。そのため、防御する側も知っておく必要があります。もしRedisの設定を間違ってanyから通信可能だった場合にホスト側にも侵入されたかも、というところを考慮できると良いと思って今回の記事は書いています。 自衛のためにも書いておきますが、悪用は禁止です。あくまで正しく脅威を把握するための啓蒙です。 参考 htt
少し前ですが、Kubernetesの方から以下の脆弱性が公開されました。 github.com タイトルにはCVE-2020-10749と書きましたが、複数のCNI実装が影響を受ける脆弱性でCVE-2020-10749はcontainernetworking/pluginsにアサインされたものです。他にもCalicoはCVE-2020-13597、DockerはCVE-2020-13401、などとそれぞれCVE-IDがアサインされています。 このIssueの説明を読んで、はいはいあれね完全に理解した、と思って一旦閉じました。ですが、頭で分かった気になって手を動かさないのは一番やってはいけないことと念じ続けてきたのに、しれっと同じことをやりそうになっていた事に気づきました。なので数日経ってからちゃんとPoCを書いてみました。多少知識が増えてくるとついうっかりやってしまいがちなので気をつけなけ
はじめに 前回の記事で、誤ってインターネットに開放されたRedisを操作してOSコマンド実行するまでの攻撃方法を説明しました。 knqyf263.hatenablog.com こちらの方法ではCONFIG SETを使っていたのですが、最近コンテナが利用されることが増えたために刺さりにくくなっています。また、Redisの実行ユーザの権限が強い必要があったり、ドキュメントルートのpathを予測する必要があったりといった制約もありました。そういった制約を回避する方法が発表されていたので試してみました。 さらに、前回はRedisが完全に操作できる前提を置いていましたが今回は更に難しくSSRFのみが使える状況が想定されています。SSRFについては調べたら出ると思うので割愛しますが、今回の場合は簡単に言うと「Redisは公開されていないが、公開されているWebサーバなど経由で攻撃者が内部のRedisに
今回は前回と違いライトなネタです。 概要 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
次のページ
このページを最初にブックマークしてみませんか?
『knqyf263's blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く