こんにちは、Ruby コミッタの柴田です。最近は暖かくなり、ガーデニングで栽培しているバラや藤の新芽や花芽が出てくる時期になってきたので、しっかり花を咲かせるように薬剤や肥料の準備をしなければ〜と必要なものの買い物計画を立てている真っ最中です。 今回はサプライチェーンセキュリティの対策として他のエコシステムで導入が進んでいる「Cooldown(クールダウン)」機能を紹介し、私がメンテナンスしている RubyGems と Bundler でも導入するべきか検討した背景と、今後の方向性についてお話しします。 Cooldown とは何か Cooldown とは、パッケージの新しいバージョンがリリースされてから一定期間が経過するまで、そのバージョンへの更新を行わないようにする仕組みです。 この機能の主な目的はサプライチェーン攻撃の緩和です。悪意のあるコードが含まれたパッケージがリリースされた場合、
Rubyのuri gemのセキュリティ修正がリリースされました。 CVE-2023-28755: ReDoS vulnerability in URI https://t.co/QhBr4EL9OE — Ruby Programming Language (@rubylangorg) March 28, 2023 お知らせ: CVE-2023-28755: ReDoS vulnerability in URI 詳しくは上記の公式情報をご覧ください。 公式で推奨されている対応方法は、uri gemを0.12.1にアップデートすることです。Ruby 3.2で使っているuri gemも更新対象です。 リリース: Release v0.12.1 · ruby/uri -- 推奨バージョン コミット差分: Comparing v0.12.0...v0.12.1 · ruby/uri なお、Ruby
この記事は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を通じてこの脆弱性を報告しました。この記事では、当該脆弱性の概要と発見の経緯などについて報告します。 概要 脆弱性発見の経緯 影響を受けるアプリケーション 影響 対策
この記事はRuby Advent Calendar 2019 - Qiitaの24日目です。 去年(RubyやRubyのOSSの脆弱性を見つけた話 - ooooooo_qの日記)と同様にRuby関連で今年見つけた脆弱性の話です。 Ruby CVE-2019-16255: Shell#[]およびShell#testのコード挿入脆弱性 hackerone.com 脆弱性なのか判断に迷うもの。 引数が.sendにそのまま渡されるので値によってはコードが実行できるものでした。 .sendを使って実際に攻撃できるパターンが有るのか、Rubyのコードの中を調べて見つけた覚えがあります。 CVE-2019-15845: File.fnmatch の NUL 文字挿入脆弱性 hackerone.com またNul文字。さすがにRubyではもうNul文字の問題はないのではないでしょうか。多分。 Pathna
Cheat sheet: TensorFlow, an open source software library for machine learning Read now Maintainers of the RubyGems package repository have yanked 18 malicious versions of 11 Ruby libraries that contained a backdoor mechanism and were caught inserting code that launched hidden cryptocurrency mining operations inside other people's Ruby projects. The malicious code was first discovered yesterday ins
RubyのBCryptはバイナリセーフなのか 徳丸先生が注意喚起としてあげられていたこちらの記事に関して “bcryptの72文字制限をSHA-512ハッシュで回避する方式の注意点 | 徳丸浩の日記” https://t.co/AA1yFVd0TH — 徳丸 浩 (@ockeghem) 2019年2月24日 記事ではPHPの例が上がっていましたが、Rubyではどのような影響があるのかが気になります。 BCryptは非常にメジャーなアルゴリズムで、例えば Devise や Sorcery などの定番の認証gemを使う場合、デフォルトでBCryptを利用する設定になっています。Railsアプリを開発されている方なら、ほとんどの方が使っているのではないでしょうか。 詳しくは徳丸ブログを見ていただくとして、以下ではbcrypt-rubyについて、同じ現象が起こるのかどうか簡単に調査しています。 T
こんにちは。Rubyコミッターのusaです。 なんかRuby の 最新 リリースと一緒に、脆弱性 情報 が いっぱい 公開 されましたね。うわー、なんかよくわかんないけど、やばそうですね!正味のところ、こいつら結局どれくらい危なそうなのか、それらの脆弱性の記事を書いた人がたまたまピクシブにいましたので、率直に本音を語っていこうと思います。 CVE-2017-17742: WEBrick における HTTP レスポンス偽装の脆弱性について うまく利用するのは難しいとは思いますが、使いようによっては利用者(WEBrickで作って公開したサイトを訪問した人)をひどいめにあわせることができるかもしれない脆弱性です。 でも、WEBrickで作ったサイトをプロダクションで公開してる人なんているわけないよねははは。 CVE-2018-8777: WEBrick における巨大リクエストにともなう DoS
Posted by usa on 17 Feb 2018 Ruby の標準添付ライブラリである RubyGems に、複数の脆弱性が発見されました。 RubyGems の公式ブログにて報告されています。 詳細 以下の脆弱性が報告されています。 Prevent path traversal when writing to a symlinked basedir outside of the root. Fix possible Unsafe Object Deserialization Vulnerability in gem owner. Strictly interpret octal fields in tar headers. Raise a security error when there are duplicate files in a package. Enforce URL
HashDoS脆弱性との戦い! Rubyコミッター・卜部昌平が明かすプログラム堅牢化のノウハウ 過去、HashDosの影響を受けたRuby。言語開発者はいかにしてこうした問題に対応してきたのでしょうか。コミッターである卜部氏の貴重な記録を公開します。 2011年の末頃、HashDoSという脆弱性が公表され、Rubyもこの影響を受けた。本稿の筆者である卜部昌平(うらべ・しょうへい/@shyouhei/以下、卜部)は、報告当初からRuby側のチームメンバーとしてプログラム本体の修正を担当した。以下はその記録である。言語開発者たちが普段どのようなことを考え、どういった技術を用いて開発やバグフィックスを行っているのか。その概要を知ってもらえれば幸いだ。 オブジェクト指向スクリプト言語 Ruby HashDoSの概要 なぜ約6年後の今、修正内容を公開するに至ったか? 前史:すでに内包されていたリスク
_ ファイルオープンの罠 僕が書いたNet::FTPのコードに脆弱性報告があり、修正版がリリースされた。関係者のみなさん、ありがとうございました。 CVE-2017-17405: Net::FTP におけるコマンドインジェクションの脆弱性について 問題があったのは以下のようなコードだった。 def getbinaryfile(remotefile, localfile = File.basename(remotefile), blocksize = DEFAULT_BLOCKSIZE, &block) # :yield: data f = nil result = nil if localfile if @resume rest_offset = File.size?(localfile) f = open(localfile, "a") else rest_offset = nil f
こんにちは、技術部の遠藤(@mametter)です。フルタイム Ruby コミッタとして、クックパッドにあたらしく入社しました。よろしくお願いします。 最近、Ruby や RubyGems の脆弱性を発見して、その結果セキュリティリリースにつながるということを経験しました。どういう動機でどのように脆弱性を発見したか、どのように通報したか、などについてまとめてみます。Ruby の脆弱性を見つけたけどどうしよう、という人の参考になれば幸いです。 HackerOne について HackerOne という脆弱性情報の通報と公開のためのプラットフォームをご存知でしょうか。 OSS にとって脆弱性情報の管理は面倒なものです。脆弱性の通報を秘密裏に受け付け、関係者だけで議論しなければなりません。そのため、通常のバグトラッカとは別のコミュニケーションチャンネルを用意する必要があります。 そこで Hacke
Posted by usa on 29 Aug 2017 Ruby の標準添付ライブラリである RubyGems に、複数の脆弱性が発見されました。 RubyGems の公式ブログにて報告されています。 詳細 以下の脆弱性が報告されています。 a DNS request hijacking vulnerability. (CVE-2017-0902) an ANSI escape sequence vulnerability. (CVE-2017-0899) a DoS vulnerability in the query command. (CVE-2017-0900) a vulnerability in the gem installer that allowed a malicious gem to overwrite arbitrary files. (CVE-2017-0901
Posted by usa on 29 Aug 2017 There are multiple vulnerabilities in RubyGems bundled by Ruby. It is reported at the official blog of RubyGems. Details The following vulnerabilities have been reported. a DNS request hijacking vulnerability. (CVE-2017-0902) an ANSI escape sequence vulnerability. (CVE-2017-0899) a DoS vulnerability in the query command. (CVE-2017-0900) a vulnerability in the gem insta
こんにちは、金子です。 普段はRailsを書いたりしています。 今回は2016/4/6に発表された、RubyGems.orgの脆弱性についてまとめました。 脆弱性について RubyGems.org gem replacement vulnerability and mitigation をざっと読んでみると、 特定の状況で、RubyGems.orgにupdateされているファイルの内容が不正に書き換えられる可能性があった 特定の状況とは、2014-6-11から2016-4-2までの間に登録されたgemのうち、'blank-blank'のように名前に'-' (dash)が入っているもの ただし2015-2-8以降に登録されたgemはRubyGems.orgがsha256 checksumを計算しており、それと実際のファイルの突合をして、書き換えられていないことを確認ずみ つまり、2014-6
はじめに この記事は2016年4月6日に公開された RubyGems.org gem replacement vulnerability and mitigation の日本語訳です。 内容を見る限り、この脆弱性が実際に悪用された可能性は低そうですが、念のためgemの開発者やgemの利用者は一読しておくことをお勧めします。 翻訳の方針について 筆者はgem開発やセキュリティ問題にそこまで詳しくないため、一部翻訳に怪しいところがあるかもしれません。 また、翻訳は日本語としての読みやすさを重視してところどころ意訳しています。 もし完全に間違った訳になっていたり、意訳しすぎて原文のニュアンスが変わってしまったりしているところがあれば、コメントや編集リクエスト等でやさしく指摘してやってください。 (翻訳)RubyGems.orgでgemが置き換えられる脆弱性とその緩和策について 原文: RubyG
ご存知の方には何を今更感があるかとは思いますが、パッとググった限り誰も書かれていなかったので、 Object#sendやそれとよく似たObject#public_sendの使い方は注意して使わなければ結構危ないセキュリティホールを作ってしまうよ、 というお話をしたいと思います。 TL;DR Object#sendはevalやsystemの次ぐらいに危険です。ユーザーの入力など、外部から入力された値をObject#sendやpublic_sendメソッドにそのまま渡すのはやめましょう。 これらのメソッドに渡す文字列は、(特殊なメタプログラミング用のライブラリを作る場合などを除いて)必ずどこかにハードコードした、信頼できるメソッドの名前のみにしてください。 危険なケース 例えばあからさまな例ですが、次のようなRailsのコントローラーのアクションがあったとしましょう。 みなさんはこれに近いよう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く