CERT Coordination Center (CERT/CC, Carnegie Mellon University)は4月10日(米国時間)、「VU#123335 - Multiple programming languages fail to escape arguments properly in Microsoft Windows」において、Windows上で動作する複数のプログラミング言語から引数を適切にエスケープしない脆弱性を発見したと報じた。この脆弱性はアプリケーションのコマンドインジェクションにつながるとして注意を呼びかけている。 VU#123335 - Multiple programming languages fail to escape arguments properly in Microsoft Windows 脆弱性の詳細 多くのプログラミング言語にはオ
This blogpost describes a DoS vulnerability in Haskell's aeson package. We have followed appropriate procedure for responsible disclosure but the problem was not fixed, so now we are releasing this to the public in the hope that it may still be fixed afterall. Disclaimer: This story is the result of a team effort at FP Complete in 2018. I have received explicit written permission to post it here.
For security reasons, the typical boot process of HTTPS servers is as follows: Executed by a root. Reading a TLS private key and open a listen socket on TCP port 443. Switching the root user to nobody (or something). Since accept() can create connected sockets bound to TCP port 443 even with non-root privilege, servers can accept connections. Let's consider the case of QUIC servers which uses UDP.
IIJ-II 技術研究所 技術開発室の山本です。現在技術開発室は、私を含めた4人で構成されており、主にプログラミング言語Haskellを使って開発を進めています。今回の話題である TLS(Transport Layer Security) 1.3 もHaskellで実装しました。 4年の歳月をかけて議論されてきたTLS 1.3ですが、この8月にめでたく仕様がRFC 8446となりました。貢献者リストに私の名前が載っていることを聞きつけた広報から、ブログ記事の執筆依頼がありましたので、TLS 1.3の標準化や実装の話について書いてみます。 なぜTLS 1.3を標準化する必要があったのか理由を知りたい方は、「TLSの動向」という記事や「TLS 1.3」というスライドを読んで下さい。 インターネットで使われているプロトコルは、IETFという団体で仕様が議論されて策定されます。IETFには、誰でも
Basic HTTP auth with Scottyを読んで、Data.SecureMemというモジュールを使うと、タイミング攻撃を防止（軽減？）できることを知りました。 その後SecureMemについて調査してみたのですが、あまり情報がなく、唯一参考になりそうなのがData.SecureMemのドキュメントの次の記述でした。 SecureMem is a memory chunk which have the properties of: ● Being scrubbed after its goes out of scope. ● A Show instance that doesn't actually show any content ● A Eq instance that is constant time そこで質問なのですが、これら３つの性質が一般的にはどのようなセキュリテ
Sourcecode and Mailing List The Tamarin prover is open-source software. Its code and issue tracker are available at https://github.com/tamarin-prover/tamarin-prover. Note that the issue tracker is only intended for tool issues, i.e., reporting potential bugs, and not for asking questions. Tamarin's low-volume mailing list/forum for announcements, asking questions, and discussion is https://groups.
HashMap・HashSetの利用時は注意！Posted by Yuji Yamamoto(@igrep) on January 21, 2018Tags: Security あらゆるソフトウェアに脆弱性は存在し得ます。 Haskellは高度な型システムを駆使することで、脆弱性を根本的に回避したプログラムを作ることを可能にします（脆弱性を防ぐためだけのものではないですが、興味のある人はSafe Haskellについても調べてみるといいでしょう）。 しかし、だからといって、型を設計する段階で脆弱性を回避できるよう気をつけなければいけないことには変わりませんし、GHCが生成した実行ファイル、使用するライブラリーに絶対に脆弱性がないとは言えません。 現状、Haskellはほかの著名なプログラミング言語ほど使用されていないためか、あまり脆弱性が報告されることはありません（libcなど、ほかの言語
以前、僕が実装している web サーバ Mighty が、Haskell で書いているにも関わらず、セグメンテーションフォールトを起こしていた。調べたところ hashable ライブラリがリンクする C の DJBX33X が、SipHash に変わったことが原因だった。このときから SipHash が気になっていたし、以前社内で説明した "Efficient Denial of Service Attacks" との関係も知りたかったので、少し調べてみた。この記事は、その覚え書き。 Hash-flooding DoS の歴史 1998 年に Alexander Peslyak 氏が Phrack Magazine で、Hash-flooding DoS を受けたことを報告している。ハッシュは、N 個の要素を挿入するのに通常 O(N) かかるが、ハッシュ値がすべて衝突する最悪の場合では O
以下を理解しようとしたときのメモ： Efficient Denial of Service Attacks on Web Application Platforms slides n.runs-SA-2011.004 - web programming languages and platforms - DoS through hash table 概要 外部からのデータに対して、効率の悪いアルゴリズムで処理するとセキュリティホールになるという一般的な問題の一例。N要素のハッシュテーブルの作成は、平均でO(N)だが、最悪で O(N^2) となる。 いろんな言語で、DJB のハッシュが利用されている。 DJBX33A Equivalent string で衝突をたくさん作れる。理解は容易。 DJBX33X 中間一致(Meet-in-the-middle)攻撃で衝突をたくさん発見できる。この理
これは、http2 Advent Calendar 2016の1日目の記事です。 現在、IETF で TLS 1.3 の標準化が大詰めを迎えています。僕も TLS 1.3 の標準化に参加しており、仕様の分かりにくい部分を直したり、TLS 1.3 を Haskell で実装したりしています。この開発日記のシリーズでは、TLS 1.3の仕組みを説明していこうと思います。 そもそも、なぜ TLS 1.3 が必要なのかは、TLSの動向をお読み下さい。なお、次のTLSのバージョンを何にするかは、現在もめていて、1.3ではなくなる可能性もあることに注意して下さい。 現在の実装 現在利用できる TLS 1.3 の実装の一覧は、Implementationsにまとまっています。僕がクライアントとしてよく使っているのは、Firefox Nightly、Chrome Canary、および picotls です
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
