Help us understand the problem. What is going on with this article? TL;DR AWSの二段階認証（Multi-Factor Authentication）を利用しているとき、認証端末を無くすとAWSのサポートが必要になる 電話番号での認証ができない場合には本人確認書類を提出して二段階認証を解除する必要がある 本人確認書類には公証人のサインが必要で、アメリカ大使館でサインをしてもらうことができる AWSアカウントにはMFAを設定しよう、というプラクティス AWSを利用しているアカウントが不正利用され、高額な請求を受けてしまうケースが話題となり、個人であってもルートアカウントでMFAを設定することが当たり前な世の中になりました。 初心者がAWSでミスって不正利用されて$6,000請求、泣きそうになったお話。 - Qiita
glibcのgethostbyname系関数に脆弱性の原因となるバグが発見されCVE-2015-0235(GHOST)と命名されたようです。放置した場合は相当多くのアプリケーションがこの脆弱性の影響を受けることが予想されます。 glibcは libcのGNUバージョンです。libcはアプリケーションではなく、事実上全てのアプリケーションが利用しているライブラリです。OSの中ではカーネルに次いで重要な部分と言えます。Linuxシステムでは(ことサーバー用途においては)例外なく glibcが使われています。 この glibcに含まれる gethostbyname系関数の実装に 2000年頃から存在したバグが今になって発見され、CVE-2015-0235 通称 GHOSTと命名されました。ネットワークで何らかの通信を行うアプリケーションは必ず※この関数を使用します。 ※追記: 名前解決をサポート
Follow @Openwall on Twitter for new release announcements and other news [<prev] [next>] [thread-next>] [day] [month] [year] [list] Message-ID: <20150127162936.GB18888@localhost.localdomain> Date: Tue, 27 Jan 2015 08:29:36 -0800 From: Qualys Security Advisory <qsa@...lys.com> To: oss-security@...ts.openwall.com Subject: Qualys Security Advisory CVE-2015-0235 - GHOST: glibc gethostbyname buffer ove
対象 サーバ側およびクライアント側で使用している「OpenSSL」のバージョンが以下の組み合わせの場合に、本脆弱性の影響を受けることが確認されています。 サーバ側: OpenSSL 1.0.1 系列のうち 1.0.1g およびそれ以前 クライアント側: OpenSSL 1.0.1 系列のうち 1.0.1g およびそれ以前 OpenSSL 1.0.0 系列のうち 1.0.0l およびそれ以前 OpenSSL 0.9.8 系列のうち 0.9.8y およびそれ以前 開発者が提供する情報をもとに最新版へアップデートしてください。 Q&A 通信経路上の攻撃者とは？ 本脆弱性を悪用するためには、クライアントとサーバの間に入って通信を中継する必要があります。このようなシナリオでの攻撃を一般に中間者攻撃といい、このときの攻撃者を本稿では通信経路上の攻撃者と呼んでいます。一般に、通信経路上の攻撃者となること
lepidum社の菊池氏がOpenSSLの実装に脆弱性があることを発見しました。この脆弱性はChangeCipherSpecメッセージの処理に欠陥があるもので、悪用された場合に暗号通信の情報が漏えいする可能性があると同社公開情報では説明されています。 尚、6月6日にレピダム社がクライアントの偽装を行う攻撃が行われる恐れについて危険がないことが確認されたとして訂正を行いました。それに伴い以下の内容も修正を加えています。(修正前の記事は魚拓を参照してください。) lepidum社 公開情報 当社で発見し報告をしたOpenSSLの脆弱性（CVE-2014-0224 ）が公開されました。早急な更新が望まれる内容だと考えています。 #ccsinjection #OpenSSL 概要はこちらのページをご参照下さい。http://t.co/bhY7GpLZ2j— lepidum (@lepidum) 2
昨日、Ruby on Railsの重要なセキュリティアップデートである、Rails 4.0.2と3.2.16がリリースされました。 このリリースには、5件(3.2.16には4件)のセキュリティFIXが含まれています。 重要度の高いものがあるため、早急なアップデートをしましょう。 CVE-2013-6416 simple_formatヘルパーのXSS脆弱性に関する修正です。 ※4.0.2のみ。3.2系では元から発生しないため、3.2.16には含まれません。 simple_formatはhtml_optionsとしてHashを渡せますが、デフォルトで、このclass指定がHTMLエスケープされていませんでした。 class指定をユーザ入力による場合、容易にXSSが成立してしまいます。 simple_format "hello\nworld", class: '"><script>alert(1
寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP（アクセスポイント）があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します（Secure属性使うと盗聴は防げますが、改変は防げません）。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe
シンボリックリンク攻撃を防ぐための Apache HTTPD モジュールの解説はこちら: Apache HTTPD: mod_allowfileowner https://fumiyas.github.io/apache/mod-allowfileowner.html 背景 ロリポップの共有 Web サービス下のサイト改ざん事件で、 攻撃手法の一つとして 「他ユーザー所有のファイルへのシンボリックリンクを自分のコンテンツディレクトリ下に作り、Apache HTTPD 経由でアクセスする」手順が利用されたらしい。 参考: http://blog.tokumaru.org/2013/09/symlink-attack.html 当社サービス「ロリポップ！レンタルサーバー」ユーザーサイトへの第三者による大規模攻撃について http://lolipop.jp/info/news/4149/#090
最近Perl人口が増えつつある気がするのでここでおさらい。myとは一体なにをするものか。まずは下記スクリプトの実行結果を予測してみて、実際の結果と比べてもらいたい。 #!/usr/bin/perl $foo = 111; print "$main::foo / $foo\n-----------\n"; { local $foo = 222; print "$main::foo / $foo\n-----------\n"; my $foo = 333; print "$main::foo / $foo\n-----------\n"; package Bar; $Bar::foo = 444; print "$main::foo / $foo\n-----------\n"; } { package Baz; local $foo = 555; print
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
