XZ Utilsの脆弱性 CVE-2024-3094 についてまとめてみた - piyolog
2024年3月29日、Linux向け圧縮ユーティリティとして広く利用されているXZ Utilsに深刻な脆弱性 CVE-2024-3094 が確認されたとして、研究者やベンダがセキュリティ情報を公開しました。この脆弱性は特定の条件下においてバックドアとして悪用される恐れがあるものとみられており、当該ソフトウエアのメンテナのアカウントにより実装されたソフトウエアサプライチェーン攻撃の可能性が指摘されています。ここでは関連する情報をまとめます。 脆弱性の概要 xzとは主要なLinuxディストリビューションに含まれる汎用的なデータ圧縮形式で、今回問題が確認されたのはその圧縮・解凍ユーティリティであるliblzma(API)を含むXZ Utils。CVE-2024-3094が採番されており、Red Hatによって評価されたCVSS基本値はフルスコアの10。影響を受けたライブラリをリンクしているssh
CVE-2024-3094: XZ Utilsにバックドアが仕込まれたという脆弱性の自分用メモ
手元にも来とる……XZ Utils (xz/liblzma) にバックドアが仕込まれたという脆弱性 CVE-2024-3094 が、その発生経緯と威力の面でやばそうで、かつ、自分の手元のPC (macOS) にも、脆弱性のある版が知らないうちにインストールされていたことが衝撃的なので、自分に関わる部分でのメモを残す。 nvd.nist.gov: NVD - CVE-2024-3094www.cisa.gov: Reported Supply Chain Compromise Affecting XZ Utils Data Compression Library, CVE-2024-3094 | CISAwww.tenable.com: Frequently Asked Questions About CVE-2024-3094, A Backdoor in XZ Utils - Blog
Rails 7.1: ローカル環境のsecret_key_baseの保存場所がcredentialsに変わる（翻訳）｜TechRacho by BPS株式会社
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: Rails 7.1 Store secret_key_base In Credentials For Local Environment | Saeloun Blog 原文公開日: 2023/08/11 原著者: Gowsik Vivekanandan サイト: Saeloun Blog この変更は、Railsのsecretsをcredentialsに移行する一連の取り組みの一環です。 参考: Add credentials using a generic EncryptedConfiguration class by dhh · Pull Request #30067 · rails/rails RailsのcredentialsはRails 5.2で導入されました。Rails 7.1では従来のsecretsが非推奨となり、代
CSRF 対策はいまだに Token が必須なのか?
CSRF 対策は One Time Token を form なりに付与して、サーバ側でチェックすれば良い。 それをデフォルトでサポートしてるフレームワークなどもあるし、なくてもライブラリでいくらでも対応できる。 どうせ完全にステートレスなサービスはなかなかないので、サーバ側に redis や memcache を用意するのも別に大変じゃない。 なので、 CSRF 対策として Token を付与するのは、最も安全で推奨できる方式ではある。 っていうのを踏まえた上で、もう SameSite=Lax デフォルトだけど、今でも Token 必須なの？みたいなのがたびたび話に出るので、いい加減まとめる。 前提 この話は、スコープがどこなのかによって話が多少変わるので、そこを絞る。 今回は Passive ではなく Active に対策していく場合を考えるので、前提をこうする。 SameSite=l
ログイン - Google アカウント
ログインお客様の Google アカウントを使用 メールアドレスまたは電話番号 メールアドレスを忘れた場合 ご自分のパソコンでない場合は、シークレット ブラウジング ウィンドウを使用してログインしてください。 ゲストモードの使い方の詳細 次へアカウントを作成
コード スキャンについて - GitHub Docs
code scanning を使用して、GitHub 上のプロジェクトのコードからセキュリティの脆弱性とエラーを見つけることができます。 Code scanning は、GitHub.com のすべてのパブリック リポジトリに使用できます。 Code scanning は、GitHub Enterprise Cloud を使用していて GitHub Advanced Security のライセンスを持つ Organization によって所有されるプライベート リポジトリでも使用できます。 詳しくは、「GitHub Advanced Security について」を参照してください。 code scanning について Code scanning は、GitHub リポジトリ内のコードを分析して、セキュリティの脆弱性とコーディング エラーを見つけることができる機能です。 分析によって特定さ
Ruby 3.0 がセキュリティメンテナンスフェーズになったのでいくつか補足, snap と all-ruby を更新した - HsbtDiary(2023-03-31)
■ Ruby 3.0 がセキュリティメンテナンスフェーズになったのでいくつか補足 Ruby 3.0 がセキュリティメンテナンスフェーズになったことに合わせて、いくつかサプライチェーン周りで考えておく必要がある事項があるので共有しときます。 Ruby 3.0 は OpenSSL 3.0 対応しないことになった Bug #18658: Need openssl 3 support for Ubuntu 22.04 (Ruby 2.7.x and 3.0.x) - Ruby master - Ruby Issue Tracking System に書いたように、Ruby 3.0 には OpenSSL 3.0 に対応した openssl gem はバックポートされないことになりました。つまり、OpenSSL 3.x しか提供されない Ubuntu 22.04 では Ruby 3.0 はビルドできな
We updated our RSA SSH host key
SecurityWe updated our RSA SSH host keyAt approximately 05:00 UTC on March 24, out of an abundance of caution, we replaced our RSA SSH host key used to secure Git operations for GitHub.com. At approximately 05:00 UTC on March 24, out of an abundance of caution, we replaced our RSA SSH host key used to secure Git operations for GitHub.com. We did this to protect our users from any chance of an adve
3日間で徳丸試験で9割取った方法 | 働くひとと組織の健康を創る iCARE
こんにちは、iCAREサーバーサイドエンジニアの寺井(@krpk1900_dev)です。 今後iCAREではより信頼性の高い開発を進めていくために、デザイナーとQAEを含む開発部全員でウェブ・セキュリティ基礎試験（通称：徳丸試験）の受験を推進していく方針が決定しました。 これはあくまで個人的な推測ですが、おそらく下期終わり（2023年7月末）のタイミングで部署全体の合格者数の振り返りを行うために、7月あたりまでに勉強を進めて受験していくことになると思っています。 この記事を書いた理由 徳丸試験は過去問や問題集の情報がほとんどないため、どのように勉強したら良いのか分からずに不安な人もいるのではないかなと思いました。 実はこちらで書いた通り私は2023年3月末をもってiCAREを退職することを決めて今日が最終出社日だったため、急いで徳丸試験を受験してきて、これから徳丸基礎試験を受験するiCAR
1Passwordを使って、ローカルにファイル(~/.configや.env)として置かれてる生のパスワードなどを削除した
1Passwordを使って、ローカルにファイル(~/.configや.env)として置かれてる生のパスワードなどを削除した 最近、コミットはされないがローカルのディレクトリに置かれている.envのようなファイルから生のパスワードやAPI Tokenを削除しました。 これは、ローカルでマルウェアを実行した場合に、ローカルに置かれている生のパスワードやAPI Tokenを盗まれる可能性があるためです。 最近は、npm install時のpostinstallでのデータを盗むようなマルウェアを仕込んだりするソフトウェアサプライチェーン攻撃が多様化しています。 Compromised PyTorch-nightly dependency chain between December 25th and December 30th, 2022. | PyTorch What’s Really Goin
Active Record と暗号化 - Railsガイド
このガイドでは、Active Recordを用いてデータベースの情報を暗号化する方法について説明します。 このガイドの内容: Active Recordでデータベース暗号化をセットアップする方法 暗号化されていないデータを移行する方法 複数の暗号化スキームを共存させる方法 APIの利用法 このライブラリの利用法および拡張方法 Active Recordはアプリケーションレベルの暗号化をサポートします。これは、暗号化する属性を宣言し、必要に応じて暗号化と復号をシームレスに行うしくみです。暗号化の層は、データベース層とアプリケーション層の間に置かれます。アプリケーションがアクセスするのは暗号化されていないデータですが、データベースには暗号化されたデータが保存されます。 1 データをアプリケーションレベルで暗号化する理由 Active Record暗号化は、アプリケーション内の機密情報を保護する
Rails 7のActive Record暗号化機能（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Active Record Encryption-- hint.io 原文公開日: 2021/07/06 原著者: Jason Dinsmore サイト: hint.io 日本語タイトルは内容に即したものにしました。 Rails 7のActive Recordに、実にクールな新機能が導入されることになりました。モデル内で使える強力なencrpyts宣言によって呼び出される、アプリケーションレベルの暗号化機能です。この新機能は、アプリケーションコードとデータベースの間に暗号化の層を提供します。要するに、ActiveRecord::Encryptionを用いたデータがActive Recordオブジェクトに読み込まれると平文になり、データベースに置かれると暗号化されます。 本記事では、この新機能の使い方の概要を説明し、いくつかの優秀な
Ruby cgi gemのHTTPヘッダインジェクション脆弱性CVE-2021-33621の概要と発見の経緯
この記事はRuby Advent Calendar 2022の第20日の記事です。前日の記事は@ydahさんによる「RuboCopのバージョンを最新に保つ技術」でした。 2022年11月22日に、Ruby cgi gemのHTTPヘッダインジェクション脆弱性CVE-2021-33621が発表がされました。 CVE-2021-33621: HTTP response splitting in CGI RubyのCGIライブラリにHTTPレスポンス分割脆弱性があり、秘密情報が漏洩する - HackerOne CGI::Cookieクラスにおけるセキュリティ上好ましくない仕様および実装 - HackerOne 私はHackerOneを通じてこの脆弱性を報告しました。この記事では、当該脆弱性の概要と発見の経緯などについて報告します。 概要 脆弱性発見の経緯 影響を受けるアプリケーション 影響 対策
RailsのCSRF保護を詳しく調べてみた（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: A Deep Dive into CSRF Protection in Rails 公開日: 2017/07/31 著者: Alex Taylor サイト: Ruby Inside 2017/10/23: 初版公開 2021/11/26: 更新 現在Railsを使っていればCSRF保護を使うことがあるでしょう。この機能はRailsのほぼ初期から存在し、即座に導入して開発を楽にできるRailsの機能のひとつです。 CSRF（Cross-Site Request Forgery）を簡単に説明すると、悪意のあるユーザーがサーバーへのリクエストを捏造して正当なものに見せかけ、認証済みユーザーを装うという攻撃手法です。Railsでは、一意のトークンを生成して送信のたびに真正性を確認することでこの種の攻撃から保護します。 最近私がUnboun
Railsセキュリティ修正7.0.3.1、6.1.6.1、6.0.5.1、5.2.8.1がリリースされました｜TechRacho by BPS株式会社
Ruby on Rails 7.0.3.1、6.1.6.1、6.0.5.1、5.2.8.1がリリースされました。 Happy Tuesday everyone! A set of releases has occurred! These releases address an important security issue, so please check it out! More information is here: https://t.co/EpxnsTJ3xt — Ruby on Rails (@rails) July 12, 2022 リリース情報: Ruby on Rails — Rails Versions 7.0.3.1, 6.1.6.1, 6.0.5.1, and 5.2.8.1 have been released! 以下はGItHubのリリースタグ↓です。今回はR
ランサムウェアがCEOを脅迫――経営層も巻き込んだリアルな「訓練」をfreeeが実施できた理由
ビジネスを支えるITインフラとしてクラウドの導入や活用が一般的になる中、企業には、オンプレミス時代とは異なるリスク管理が求められている。業務やサービスを支えるインフラが、クラウド上にあることを前提に、新たなセキュリティポリシーやBCP（事業継続計画）を策定する企業も多い。 しかし、実際に何らかの問題が発生した際、組織や個人がそれに適切に対処する行動を取れるかどうかは、文書化された「ポリシー」や「計画」とは別の問題だ。大規模災害の発生を想定し、非常時のアクションについて身をもって学ぶ「BCP訓練」が必要とされているのと同様、巧妙で悪質なサイバー攻撃に直面した際、組織が適切に対処できるように備える上で「インシデント対応訓練」の実施は有用な取り組みといえる。 クラウド会計サービスを提供するfreeeでは、2021年10月に「標的型攻撃によりセキュリティが突破され、ランサムウェアでCEO（最高経営
「すべてはお客様のために」 - Classiがセキュリティ対策状況を公表し続けたシンプルな理由 [事故対応アワード受賞]
インタビュー 「すべてはお客様のために」 - Classiがセキュリティ対策状況を公表し続けたシンプルな理由 [事故対応アワード受賞] 「子どもの無限の可能性を解き放ち、学びの形を進化させる」というミッションのもと、学校向けのSaaSビジネスを手掛けるClassi。ベネッセホールディングスとソフトバンクのジョイントベンチャーとして2014年に設立され、高校向けのサービスは現在、高校生の3人に1人が利用するまでに拡大している。 学校現場のさまざまなシーンで活用される教育プラットフォームを目指すなか、2020年4月、Classiは不正アクセスによりサービス停止を余儀なくされた。これを重く受け止めた同社は、迅速な初動対応を進めただけでなく、事故後も継続的かつ全社的なセキュリティ対策を実施。これらの取り組みの具体的な内容を、約1年後となる2021年5月に公表した。 事故発生後に対策方針を打ち出す企
![「すべてはお客様のために」 - Classiがセキュリティ対策状況を公表し続けたシンプルな理由 [事故対応アワード受賞]](https://cdn-ak-scissors.b.st-hatena.com/image/square/1356f0ee0acd8b880da97a23d1e66a6335a6193f/height=288;version=1;width=512/https%3A%2F%2Fnews.mynavi.jp%2Ftechplus%2Farticle%2F20220707-2387963%2Findex_images%2Findex.jpg)
Content Security Policy のレポートを収集するためにやったこと - Classi開発者ブログ
はじめに こんにちは、開発本部所属エンジニアの id:kiryuanzu です。 現在、Classi ではサービスのセキュリティリスクをできる限りなくすために Content Security Policy を導入して脆弱性を検知する仕組みの導入を進めています。 本記事ではこの仕組みを導入する上でどのような手順が必要であり、どのような箇所で苦戦するポイントがあったかについて紹介していきます。 筆者は今まで CSP対応に携わったことがなかったのですが、導入段階の時点で想定していたよりも様々な知識が必要なことがわかり、記事にしたいと思いました。 もし数ヶ月前の自分と同じように初めてCSP対応に関わる人の一助となれば幸いです。 Content Security Policy (通称: CSP) って何? Content Security Policy とは、HTTPヘッダの種類の1つであり、クロ
一般ユーザに払い出すと危険なサブドメインやメールアドレス - ASnoKaze blog
ユーザに対して、そのユーザ名のサブドメインやメールアドレスを払い出すWebサービスがあります。 しかし、特定のサブドメインやメールアドレスは特別な用途で使われているものもあります。そのようなサブドメインやメールアドレスを一般ユーザに払い出してしまうと危険です。 現在、IETFでは仕様上利用用途が決められている、それらのラベルをとりまとめる「Dangerous Labels in DNS and E-mail」というdraftが提出されています。 今回はそれを眺めていきます。 （あくまでIETFの取り組みであり、仕様上定義されているものをとりまとめています。クラウドサービスや特定ベンダーで特別利用しているものは現在含まれていません。） サブドメイン ここでとりあげるサブドメインは、利用用途が決まってるため一般ユーザに払い出すべきではありません。(例: mta-sts.example.com)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - Bad Todo 非常に多種の脆弱性を含む診断実習やられアプリ
