タグ

セキュリティと脆弱性に関するkoroharoのブックマーク (5)

  • CVE-2015-7547 glibc における getaddrinfo の脆弱性について – IIJ Security Diary

    この脆弱性は2016年2月17日に対策済みバージョンと共に公開されました。内容としては getaddrinfo の呼び出しにおいてスタックバッファオーバーフローが発生する物です。公開時点で以下の通り、PoC を含めた技術的な詳細が公開されています。記事では、脆弱性が発生するまでの処理と、回避策について解説したいと思います。 CVE-2015-7547 — glibc getaddrinfo() stack-based buffer overflow Google Online Security Blog: CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow 脆弱性に至るまで 今回の脆弱性は getaddrinfo の呼び出しに起因しています。脆弱性のある箇所までの関数呼び出しは以下の様になっています。 getaddri

    CVE-2015-7547 glibc における getaddrinfo の脆弱性について – IIJ Security Diary
  • OpenSSLの脆弱性(CVE-2015-1793)によるAltチェーン証明書偽造の仕組み - ぼちぼち日記

    TL;DR やっぱり書いていたら長文になってしまいました。あまりちゃんと推敲する気力がないので、変な文章になっているかもしれません。ご了承いただける方のみお読みください。 1. はじめに 昨晩未明にOpenSSL-1.0.2d, 1.0.1pがリリースされました。事前に予告されていた通り深刻度高の脆弱性CVE-2015-1793が修正されています。Advisoryを見ると、この脆弱性がiojs/Nodeに影響があるということが判明したので直ちにiojs/Nodeのアップデートを行い、今朝未明に無事脆弱性対応版をリリースしました。 今回が初めてではありませんが、深夜に日欧米のエンジニアgithub上で互いに連携しながら速やかにセキュリティ対策のリリース作業を行うことは何回やってもなかなかしびれる経験です。時差もありなかなか体力的には辛いものがありますが、世界の超一流のエンジニアと共同でリア

    OpenSSLの脆弱性(CVE-2015-1793)によるAltチェーン証明書偽造の仕組み - ぼちぼち日記
  • glibcのgethostbyname関数に存在するCVE-2015-0235(GHOST)脆弱性について - ブログ - ワルブリックス株式会社

    glibcのgethostbyname系関数に脆弱性の原因となるバグが発見されCVE-2015-0235(GHOST)と命名されたようです。放置した場合は相当多くのアプリケーションがこの脆弱性の影響を受けることが予想されます。 glibcは libcのGNUバージョンです。libcはアプリケーションではなく、事実上全てのアプリケーションが利用しているライブラリです。OSの中ではカーネルに次いで重要な部分と言えます。Linuxシステムでは(ことサーバー用途においては)例外なく glibcが使われています。 この glibcに含まれる gethostbyname系関数の実装に 2000年頃から存在したバグが今になって発見され、CVE-2015-0235 通称 GHOSTと命名されました。ネットワークで何らかの通信を行うアプリケーションは必ず※この関数を使用します。 ※追記: 名前解決をサポート

    glibcのgethostbyname関数に存在するCVE-2015-0235(GHOST)脆弱性について - ブログ - ワルブリックス株式会社
  • 勝手に査読:Webアプリにおける11の脆弱性の常識と対策

    「Webアプリにおける11の脆弱性の常識と対策」という記事を久しぶりに読みました。出た当事も思いましたが、基的な誤りが多く、読者が誤解しそうです。このため、編集部から頼まれたわけではありませんが、「勝手に査読」してみようと思います。 細かい点に突っ込んでいくとキリがないので、大きな問題のみ指摘したいと思います。 ※2013年2月25日追記 このエントリに対して、編集部が元記事を修正くださいました。徳丸も修正に協力いたしましたが、十分正確な内容ではないことをお含みおきください。 ※追記終わり 同記事の想定読者は誰か査読にあたり、この記事の想定読者を明確にしておいた方がよいですね。記事の冒頭には、連載の説明があります。 連載は、JSP/サーブレット+StrutsのWebアプリケーション開発を通じて、Java言語以外(PHPASP.NETRuby on Railsなど)の開発にも通用する

    勝手に査読:Webアプリにおける11の脆弱性の常識と対策
    koroharo
    koroharo 2013/02/20
    『全面的に書きなおすか、ボツにするしかないと考えます。』えー(´Д` ) / 元記事の著者は息をしているのだろうか。
  • 難読化していないAndroidアプリケーションは脆弱性か

    このエントリでは、Androidアプリケーションにおいて、難読化が施されていない場合、脆弱性にあたるかについて議論します。 はじめに Androidアプリケーションは主にJava言語で記述され、DEX形式のファイルにコンパイルされたコードを、DalvikというJava互換VM上で実行します。DEXおよびAPKファイルの仕様は公開されており、DEXにはクラスやメソッド等のシンボル名も含まれているため、リバースエンジニアリングが容易であると言われています。このため、Android SDKには標準でProGuardという難読化ツールが添付されています。 それでは、難読化の目的はそもそも何で、難読化でその目的は達成されるのでしょうか。 難読化の目的 Webアプリケーションの場合は、重要なロジックは主にサーバー側に存在するため、ソースコードを外部から取得することはできません。これに対して、スマートフ

    koroharo
    koroharo 2012/02/20
    リバースされるとやばいコードを見極める必要があるってことがそもそも認識されてないと思うんだよな。闇雲に難読化って言ってる人が多いんじゃないか。
  • 1