新しめのSELinuxの情報源があまりない気がします。和書のSELinux書籍もすっか り古くなってしまいました。 なんとかせねばと思っていたのですが、その一環として、 日経Linuxに連載した、「新SELinux入門」全１２回が、ITProより公開されてい ます。 http://itpro.nikkeibp.co.jp/article/COLUMN/20070827/280411/ 比較的新しいSELinuxがベースなので、CentOS5やらRedhatEL5やらの SELinuxに使えると思います。 LWN.netより。オーストラリアのLinux conferenceで、セキュリティの話があっ たらしい。 http://lwn.net/Articles/266358/ SELinuxについても、例として挙げられていた。 A system running SELinux may, in
![2008-02-11 - himainuの日記 [SELinux] 攻撃コードの検証 (CVE-2008-0600)](https://cdn-ak-scissors.b.st-hatena.com/image/square/a3f936d071e853f5cfdaade115e7f794c6edc26e/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fproxy.goincop1.workers.dev%3A443%2Fhttps%2Fcdn.blog.st-hatena.com%2Fimages%2Ftheme%2Fog-image-1500.png)
Kyocera Company Background. Kyocera Corporation is a joint stock corporation that was incorporated under the laws of Japan in 1959 with the name Kyoto Ceramic Kabushiki Kaisha. Its name was changed to Kyocera Kabushiki Kaisha or Kyocera Corporation in 1982. Kyocera is engaged in numerous high-tech fields; from fine ceramic components to electronics devices, equipment, services and networks. Fine
I will be as brief as possible. Here is the deal: attackers are able to launch Cross-site scripting attacks from any origin (kind of like universal XSS) or escalate their privileges to chrome (not trivial) by tricking the victim into performing an action, such as clicking on a link. The issue was found and tested on the latest Firefox 2.0.0.8 release. The vulnerability was discovered within the wa
2007/08/10: 少年(???)は荒野を目指す part 2 $Id: index.html,v 1.17 2007/08/15 00:48:35 itojun Exp $ 写真なし。 人生でこんな文章を2度も書くとは思ってもみませんでした。 1度目はこちらね。 私こと萩野itojun純一郎は、 より広く皆様のために貢献するためにいろいろと頑張ることとなりました。 長い説明は抜きにしてじゃあ今後どうするのという件でしたら、 こちらまたは こちら あたりを御覧頂ければと思います。 どんなのでも構いません。 御連絡は歓迎です。 お待ちしてます。 こんな文章2度も書いて大丈夫なんですか そんな無謀なことして平気なのかお前 など、いろんな御心配はあるかと思います。 理由はまあいろいろあるんですが、せっかくなので、 とりあえずなんとなく述べてみよう、と思います (このへん1度目からもってきてそ
とりあえず、以前の記事を紹介しておいたほうがいいかな。 Perl の Taint mode は話をややこしくする。。。? 勘違いしてたかも＜Taint mode 長くなってしまったので、記事内の目次を入れておきます。 議題 試行 Taint モジュール 汚染された値の洗浄 逆転の発想 あなたの意図することを言おう、自分が言っていることの意味を理解しよう 議題 で、今回のテーマは主に以下の 2つ。 Taint mode を XSS とかの予防に利用することはできないのか? ブラックリストだからダメで、ホワイトリストならば良い、ってのは正しいのか? 1. については、最初の記事で TB 飛ばした dankogai 氏の記事にそんなことが書いてあったから。 もちろんTaint Modeは銀の弾丸ではない。たとえばXSSなどに対しては効果は薄い。しかしそれを言えばuse strict;も銀の弾丸で
スラッシュドット ジャパン | サーバのバージョンは隠すのが常識? これはー。 隠すことによるセキュリティの向上は望めないことを自覚したうえでやってね という話に尽きる気がする。 こういったサーバ情報をわざわざ表示する必要はありません。 というのはその通りなんだけど、タイトルの「5分でできるセキュリティ向上」には役に立っていないことは触れなくていいんだろか。 さらに言うと個人的にはこの手の話は バージョン情報を隠す/隠さない最新のバージョンを使う/使わない以外に、 バージョンはそのままでパッチを当てるという選択肢が存在していることがもっと広く知られてほしいという気がするかなぁ。意外にね「あー Apache のそのバージョンには脆弱性が云々…」てなことを「得意げに」言う人ほどその情報だけを鵜呑みにしてて、いや、パッチ当たってるんですけど、と軽く反論してみても全然聞いてなかったりするんですよね
_ Webアプリケーション脆弱性対策としての入力値検証について Webアプリケーションのセキュリティ対策としての「入力値検証」について色々言われている。セキュアコーディングの基本は入力値検証だといわれたり、さほど重要でないと言われたりしている。本当のところはどうなのだろうか。以下、バイナリデータを扱う場合の多いミドルウェア(Webサーバーなど)と対比しながら、この問題を掘り下げたい。 バイナリデータの場合(≒ミドルウェアの場合) バイナリデータでは、入力検証が重要である。少し前にmod_imagefightを取り上げた(画像版サニタイズ言うな(2))ので、ビットマップ画像を例に説明しよう。 その際に使用したBMP形式の説明を再掲する。 0000:MARK(2) ='BM' 0002:ファイルサイズ(4) * 0006:予約1(2) =0 0008:予約2(2) =0 000A:ビットマップ
2007-05-22 基本的に言語は道具なんだから、長所と短所を理解して適材適所で使えばいいと思ってる。 だから、好む好まないに関わらず、道具はそこにあるんだからと書いた。 でも、ここだけは指摘しておきたい。 cloned.log - PHPは一発屋としては最高で、リクエストされたファイル名とファイル内容を保存する例が示されている。 <?php file_put_contents($_REQUEST['name'], $_REQUEST['value']); 明らかにこれは良くない。例えば以下のように書けば分かると思う。 <?php file_put_contents("/var/www/index.html", "This page was cracked"); 例を書かれた方も以下のように書いているので、危険性は認識しているんだと思う。 「リクエストの値をチェックしろよ」とかはもっとも
■ PlaceEngineのプライバシー懸念を考える PlaceEngineが研究実験の段階を越えて商用サービスとして提供開始されているということで、「みんなの地図2」を購入した。使用してみて、想像以上に実用になるものであることを知った。東京の都心で試したところ、たいていの場所でかなりの精度で場所を特定してくれる。 「みんなの地図2」に付属のPlaceEngineクライアントは、ローカル（UMDもしくはメモリスティック）に保存されたデータに基づいて位置を計算するようになっているが、Windows用のPlaceEngineクライアントは、インターネット経由でサーバに位置の計算を問い合わせるようになっている*1。そのため、ノートPCでもネットがつながってさえいれば、GPSがなくても位置を調べることができ、それはとても興味深い機能であり、今後の応用が楽しみなシステムだと感じた。*2 しかし、この
世の中には大きく分けて3つのサイトの形態がある。そしてセキュリティについて考える時、このサイトの形態が問題になることがある。 3つのサイト形態とはざっと以下の通りだ。 市役所型 一極集中型の巨大サイトで多数のユーザーを抱えるサービス。Yahoo!, Mixiなど。 自動販売機型 1つのプロダクトを多数のユーザーが共有している状態。Movable Type、WordPressなど。 一戸建て型 独立したサイトで、普及しているプロダクトのコピーでもなく、ユーザーを多数抱えている訳でもないもの。 厳密には「村役場型」などもあるがここでは取り上げない。以下、この3つの形態の問題点、脆弱性との関わりなどを考察していく。 各形態の問題点 市役所型サイトは常に攻撃の危険に晒されているといって良いだろう。多数のユーザを抱えているゆえ、穴が開いた時の被害が大きいからだ。同一人物によってアカウ
Summary mod_security is a web application firewall often used in combination with PHP. It is usually used to block attacks based on patterns defined by regular expressions. Therefore it tries to parse the incoming HTTP request into what it believes to be parameters for the web application and logs or disallows requests matching the defined patterns. When it parses POST requests with the applicatio
「フレッシュリーダーの脆弱性に関連してSage++のこと」よりもこちらのほうが興味深い。 JPCERT/CC 開発者ベンダ登録リストは、「会社の登記簿謄本」や「会社概要」が必要と書かれているので、企業を対象とした枠組みであり個人は対象外だと私も思っていた。 「45日」は事実上死んでいる(と思われる)ルールなので、修正されていない脆弱性は45日を過ぎてもJVNにて公開されることはありません(たぶん)。 Sage 1.4の脆弱性については IPA 経由での届出はなされてないんですかね。 記事中で挙げられている、スクリプトを含む RSS Feed 以外にも、テスト用の RSS Feed (を束ねた opml)としては、Feed Secuirty Suite があります。 あと、製品開発者ベンダ登録リストに登録しておくと、「ブラウザの『仕様』なのでWebアプリ側で頑張って対策してね」みたいな情報を
![[重要] Sage++ (Higmmer's Edition)の脆弱性情報に関して、お詫びと釈明 (ひぐまのひまグ) - 葉っぱ日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/108f0d5d7eabc12d3aeb87b57f9b7c828fcd801c/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fproxy.goincop1.workers.dev%3A443%2Fhttps%2Fogimage.blog.st-hatena.com%2F13208692334729887943%2F17680117126985331593%2F1551408560)
当ひまグで昨年10月5日頃より公開していたFirefoxの拡張機能Sageの私製改造版「Sage++ (Higmmer's Edition)」(現在公開自粛中。以下、Sage++と称す)に関連し、去る2007年1月18日に以下のエントリを公表致しました。 フレッシュリーダーの脆弱性に関連してSage++のこと 上記エントリについて、様々な方よりご批判、お叱りの声を頂いております。つきましては、ユーザーの方々、第一発見者及びJPCERT/CCの関係者の方々、並びに多くの皆様にご心配ご迷惑をおかけしていることに対して深くお詫び申し上げます。誠に申し訳ありません。 何を申し上げても見苦しい言い訳との謗りは免れないものと存じますが、この際、今後の対応方針及び上記エントリの公表に至った経緯、並びにSage/Sage++の危険性に関して説明させて頂きたく存じます。 1. 今後の対応方針について 今回の
_ [etc] JVN#82258242:ショッピングバスケットプロにおける OS コマンドインジェクションの脆弱性 昨年の7月27日に修正されていた問題が、JVNに挙がった。 これは、2006年7月26日に開発者に直接連絡、27日に修正され、開発者の承諾も得て31日にIPAに届け出たもの。しかし「開発者にて修正版が公開されている」ことから、不受理になった。その後 IPA や JPCERT/CC で様々な検討や調整をしたんだと思うけど、広く周知するためということでようやくJVNで公開になった。 ５年前に一度ネットサーフレスキューさんに脆弱性の連絡をした際、素早く対応して頂いた経験があったので、この件を見つけた時どちらに先に連絡するか迷ったけど、先に開発者に連絡することにした。すぐに対策版が公開されたものの、JVNをうまく利用できず公開されるのが半年後になってしまい、よかったのか悪かったのか
のだったら、IzyNews - Security-check for RSS-Readersをsubscribeしてみるのはどうですか。 まとめはFeed Injection in Web 2.0 (PDF 278KB)で。 フレッシュリーダーの脆弱性に関連してSage++のこと 本来なら早急に脆弱性の内容を確認して対策バージョンをリリースすべきだとは思うんですが、JPCERT/CCから脆弱性情報の詳細を入手するには開発者ベンダ登録リストというものに住所・氏名・電話番号等の個人情報を登録する必要があるらしく、残念ながら当方では緊急度・影響度が不明な脆弱性情報を入手することの必要性と、そのために自分自身の個人情報を晒すというリスクの度合いを比較検討した結果、これ以上の情報入手を断念しました。従いまして指摘を受けた脆弱性(具体的内容は不明)は現時点でも対策されていません 誤解があるようで。 脆
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
