Security – ページ 3

自転車用リアチャイルドシートリコール問題

2011-03-022021-11-16 清水文行

鉄製「自転車用リヤチャイルドシート」無償交換のお知らせを何気に見てから街を歩いていると、あることあること、そこらじゅうにあります。いや、まじで。それもそのはず〈ニュースリリース〉「鉄製自転車用後席幼児座席(リヤチャイルドシート）」無償交換のお知らせ　〜リコール対象の拡大〜にあるだけで別ブランドもあわせて569,523台。自転車に人がいて止まっていたら、買ったチャリンコ屋で確認した方が良いかもと声をかけるようにしていますが、ぜんぜん知らなかったという人が結構多い感じです。検索してみると、安全には代えられないものの交換品が色も選べないという不満が多いようです。というわけで少しでも多くの人が知る助けになればとJFYIでした。

PivotXを利用されている方は最新版にアップデートするべし (was: PivotXを利用されている方は2.2.5以降へアップデートするべし CVE-2011-1035)

2011-02-152021-11-16 清水文行

2011/10/8追記: WordPress TimThumb RFI Vulnerability used as Botnet Recruitment Vectorにあるようなurlがquery string上で目立つTimThumbを狙ったアクセスを頻繁に観測していますが、PivotXも2.3.0のリリースノートでさりげなく書いてあるように本体がTimThumbを搭載しています。常にリリース状況を確認して最新にされることをお勧めします。なおこの問題に脆弱なPivotXのfingerprintingも、多くのケースでそうであるようにヘッダも含めてバージョン表示を消したところで即時に可能です。

2011/2/19追記: CVE-2011-1035, Vulnerability Note VU#175068

2011/2/14: PivotX 2.2.4がリリースされても告知が無く、SourceForgeにもリリースのアーカイブファイルがアップロードされないのでどうなっているのか見てたところ、フォーラムで開発チームからいくつか発言が出てきました。

2.2.4は緊急セキュリティ修正、そしてまもなく2.2.4での修正による悪影響を修正した2.2.5が~~出てくるそうです~~2011/2/17早朝に2.2.5リリースされました。SourceForgeにも置かれています。実際に攻撃があったことが複数報告されています。開発チームは詳細の公開を望んでいないようですが、結構誰でもすぐにわかってしまうかも…というかそもそも攻撃が現在進行形であるようなので可及的速やかに~~2.2.4、そしてリリースされ次第~~2.2.5以降にアップデートする必要があることになります。 http://pivotx.net/ の下の方にある最新情報を軒並み注意しておくとよろしいかと思います。アップデートだけではなく images/ と pivotx/templates/ を含むすべてのフォルダにmalwareが置かれていないことも要確認です。必要の無いファイルがある場合はダッシュボードに注意をうながすメッセージが出るようですが、出ないからと安心してしまわないようにしたいものです。全員のユーザ名が予測困難なものであることの確認とパスワードの変更を検討された方がよろしいかもしれません。

直接この問題とは関係無く、admin,system,pivotxなどの容易なユーザ名や、簡単にblogエントリから推測できるようなユーザ名は使用しないことを周知するとよろしいです。またCSRFはかわせないですがscript kiddieによる外部からのpivotx/index.phpへの直接攻撃には、例えばApache HTTPDで10.1.2.128/25,192.168.0.0/16からしかログインできないようにして良い状況でサーバ設定ファイルが変更できるのであれば

<locationMatch "^/*yourblogdir/+pivotx(?:/+(?:index(?:..*)?)?)?$">
   Order Deny,Allow
   Deny from all
   Allow from 10.1.2.128/25
   Allow from 192.168.0.0/16
</locationMatch>
とか
<locationMatch "^/*yourblogdir/+pivotx(?:/+(?:index(?:..*)?)?)?$">
   <RequireAny>
     Require ip 10.1.2.128/25
     Require ip 192.168.0.0/16
   </RequireAny>
</locationMatch>

Order Deny,Allow

Deny from all

Allow from 10.1.2.128/25

Allow from 192.168.0.0/16

</locationMatch>

とか

Require ip 10.1.2.128/25

Require ip 192.168.0.0/16

</RequireAny>

</locationMatch>

さらに403では無くてリダイレクトさせるには追加で

RewriteEngine On
RewriteCond %{REMOTE_ADDR}  !^10.1.2.(?:12[89]|1[3-9][0-9]|2[0-5][0-9])$
RewriteCond %{REMOTE_ADDR}  !^192.168.
RewriteRule ^/*(yourbogdir)/+pivotx(?:/+(?:index(?:..*)?)?)?$    /$1/? [R=301,L]

RewriteEngine On

RewriteCond %{REMOTE_ADDR} !^10.1.2.(?:12[89]|1[3-9][0-9]|2[0-5][0-9])$

RewriteCond %{REMOTE_ADDR} !^192.168.

RewriteRule ^/*(yourbogdir)/+pivotx(?:/+(?:index(?:..*)?)?)?$ /$1/? [R=301,L]

.htaccessしか使えない場合はyourblogdir/pivotx/.htaccessファイルを作成して

RewriteEngine On
RewriteCond %{REMOTE_ADDR}  !^10.1.2.(?:12[89]|1[3-9][0-9]|2[0-5][0-9])$
RewriteCond %{REMOTE_ADDR}  !^192.168.
RewriteRule ^(?:index(?:..*)?)?$ - [F,L]

RewriteEngine On

RewriteCond %{REMOTE_ADDR} !^10.1.2.(?:12[89]|1[3-9][0-9]|2[0-5][0-9])$

RewriteCond %{REMOTE_ADDR} !^192.168.

RewriteRule ^(?:index(?:..*)?)?$ - [F,L]

(yourblogdirはそれぞれの環境に合わせて)程度の制限をしておいても良いかもしれません。くどいようですがCSRFはこれでは防げません。pivotx/index.phpを利用した直接攻撃だけに対する限定的な緩和策で、基本は常に最新版へのアップデートです。

なおこの問題に脆弱なPivotXのfingerprintingは、多くのケースでそうであるようにヘッダも含めてバージョン表示を消そうとも即時に可能です。

2011/2/22:

netname: VODAFONE-TURKEY-3G-46-106
descr:   Vodafone Turkey 3G IP Pool
country: TR

netname: VODAFONE-TURKEY-3G-46-106

descr: Vodafone Turkey 3G IP Pool

country: TR

から、google.com.tr の検索語 “inurl:jp pivotx” のSERPがReferer:の攻撃を観測しましたよ。

2011/2/17早朝:2.2.5がリリースされてSourceForgeにも置かれました。

2011/2/16朝:pivotx.netさきほど復活しました。

2011/2/15現在:pivotx.netがある共有サーバがダウンしてSourceForgeでも2.2.4以降のリリースとしてのアーカイブは入手方法がありませんが、SVNにコミットされたリリース前版は入手可能です:

http://sourceforge.net/projects/pivot-weblog/develop
http://web.archive.org/web/20160416045740/http://book.pivotx.net/page/1-2 trunk は現在2.3pre-alphaだそうなので、2.2系利用中の方は2.2.xのbranchが良いかと思います。SVN無しでもSorceForgeのレポジトリからのtar機能も一応使えます。リリース前なのでバージョン表記の変更が入ってませんが、 svn co した場合は pivotx/lib.php の $Rev$ が 3505 以降になっているはずです。なおリリースのアーカイブに含まれるextentionsは別途取得となります。gettextの.poファイルはPixotXの実行時に必要ありません。
- svn co https://pivot-weblog.svn.sourceforge.net/svnroot/pivot-weblog/branches/2.2.x 2.2.x
- http://pivot-weblog.svn.sourceforge.net/viewvc/pivot-weblog/branches/2.2.x/

浮動少数問題 Java版 CVE-2010-4476

2011-02-112021-11-16 清水文行

NIST: Vulnerability Summary for CVE-2010-4476 2011/2/18に update 24 関連CVE(結構たくさん)summaryが有効になりました。
Security Alert For CVE-2010-4476 Released
Oracle Security Alert for CVE-2010-4476
CVE-2010-4476(description入りました)

どっかで見たことのある数字のような気がしますが(表記されている1個の値だけではなく範囲になります。DoS仕掛けてくれちゃってる人検出用シグナチャを作る方はこちらやそこから参照されているOpenJDKのBTSですがこちらを。少数をパースする場面って何気に多いですね)。さっそくfp87な機械のEclipseにコピペして自動的に文法チェックされた日にはそのままEclipseハングするので半べそです。2011/2/15に(日本では15日深夜にJava SE 6 Update 24登場しました)6u24が出るまではJava SE Floating Point Updater Toolでしのぎましょうということなので管理者権限でunzipしたjarを実行したら、一生懸命ランタイムライブラリをばらかしてからアーカイブし直してるようでした。インストール先の空き容量がぎりぎりな人はちょっと注意かも。

DNSSEC始めました

2011-01-272022-09-27 清水文行

祝ルートからJPへのチェイン。弊社が利用しているドメイン(co.jp jp ch me es be dk com net org…)もすべてDNSSECおよびDANE/TLSA対応完了。DNSSECが有効でTLSA RR,CAA RRにも対応したセカンダリDNSサーバ,DANE,TLSA,DMARC,DKIM,SPFに関するご相談は弊社へどうぞ。と宣伝をしたところで以下は設定を確認するためのリンク集と自分で確認する手順。

続きを読む →

【ランチタイムラーニング】初めてのWindowsガジェット – お昼を食べながらガジェットを作ってみよう – Windows 7 デスクトップおよびVista サイドバー

2010-12-292021-11-16 清水咲里

「ガジェット」という言葉を聞くと、昔のアニメ、Inspector Gadgetの決め台詞、”Go-Go-Gadget!”と叫びたくなります。この台詞と共に、体のあちこちからわらわらとガジェットが出てくる様は、さながら洋風ドラえもんといったところです。

GUIを伴うアプリケーション作成は数年前まではちょっと敷居が高いものでしたが、現在ではエディターと初歩的なHTMLやJavaScriptの知識があれば、便利な「ガジェット」がいとも簡単に作れるようになりました。しかも作ったガジェットを世界中の人たちと共有できる環境があるので、その便利さや自分の作品を公開し使ってもらえる楽しさから、文字通り老若男女が挑戦しています。

最初の一歩はお昼を食べながら踏み出せるくらいの手軽さです。明日のお昼にでも、ちょっと作ってみませんか？

注: 脆弱なガジェットをインストールした場合に遠隔からコードを実行させることができてしまうプラットフォームである(KB2719662)との理由でWindows 8以降での機能実装の打ち切り、およびガジェットを無効にするように薦めています(理由は不明ですがガジェットを無効にするためのお手軽Fix it 50906の提供が中断か終了したようなので、無効にする場合は上記記事の中のSuggested Actionsの抜粋 Windows サイドバーガジェットの悪用から Windows Vista および Windows 7 コンピューターを保護する方法を参照してください)。ガジェットはお手軽ですが、動作させることはexeを動作させているのと同じ危険性を持つので、由来のわからないものや、由来がわかっていても脆弱かもしれないという意識が必要です。またローカルファイルにアクセスする権限やコードの実行権限があるので、脆弱なものを作ったりインストールしたりしたら大変なことに、しかも管理者権限でログインしていたらOSまるごと乗っ取られるかもしれませんよ、ということになります。以上、当たり前な話であるわけですが、テキストエディタだけでお気楽に作れる分余計に注意が必要、ということでしょうか。メールに添付されたzipの内のjsファイルを実行してしまってファイルを軒並み暗号化されて、復号のためにはbitcoin払えと表示されて涙、と似たようなものです(こちらはOSによる注意のダイアログが出る分少しましかも知れないですが、見慣れていて結局そのままOK押してしまうかも)。

何を作るか

Windows サイドバーガジェット開発者ガイドには、”Hello, World!”と出てくるガジェットの作り方が掲載されています。”Hello, World!”はチュートリアルの王道ではありますが、もう少し実用性のあるガジェットを作ったほうがより楽しく作れるでしょう。

例えばタイマーなどは便利な上に簡単です。最近、仕事を効率よく進めるコツとして「ライフハック」という言葉が使われていますが、いくつかのライフハックの中で1日の時間を分割して効率良く作業を進める方法を取り上げています。ただ、時間を気にしながら作業をしても集中できないので、タイマーがあると便利です。それにタイマーはエンジニアの友であるカップ麺を作る時にも重宝します。

そこで今回は簡単なタイマーを自作します。この簡単なタイマーを改造していけば、自分好みのタイマーを作ることができます。

材料を準備しましょう

【材料】

お気に入りのエディタ (Windowsのメモ帳(notepad.exe)で十分)
ブラウザ

以上です。そうです、今この記事をご覧になっているのであれば標準的にコンピュータに入っているもので作れてしまうのです。それがガジェット作りの手軽さなのです。

もちろんJavaScriptやHTMLのリファレンスが手元にあると便利ではありますので、お好みでご利用ください。

さっそくガジェットを作りましょう

手順と成果物の概要

ではさっそくガジェットを作りましょう。その手順は以下の通りです。

%LOCALAPPDATA%\Microsoft\Windows Sidebar\Gadgetsにフォルダーを作る→「○○.gadget」フォルダー
JavaScriptを含んだHTMLを記述する→「○○.html」ファイル
マニフェストを記述する→「gadget.xml」ファイル

以上、簡潔な3ステップです。

ステップ1: 作業フォルダの作成

%LOCALAPPDATA%\Microsoft\Windows Sidebar\Gadgets (C:\Users\<ユーザー名>\AppData\Local\Microsoft\Windows Sidebar\Gadgets)に「Timer.gadget」フォルダー(以降、作業フォルダーと呼びます)を作成します。

mkdir "%LOCALAPPDATA%\Microsoft\Windows Sidebar\Gadgets\Timer.gadget"

1	mkdir "%LOCALAPPDATA%\Microsoft\Windows Sidebar\Gadgets\Timer.gadget"

ステップ2: JavaScriptを含んだHTMLを記述する

作業フォルダーに、新しく「Timer.html」というファイルを作成して、次のように記述し保存します。(このHTMLファイルの内容の詳しい解説は、『ソースコード解説』に記述しましたので、必要に応じて参照してください。)

<html>
<head>
<title></title>
<style type="text/css">
body {
  margin: 0;
  width:130px;
  height:100px;
  font-family:Georgia, "Times New Roman", Times, serif;
  font-weight:bold;
}
#gadgetContent {
  margin-top:20px;
  width:130px;
  vertical-align:middle;
  text-align:center;
  overflow:hidden;
}
#nowTime {
  text-align:left;
  font-size:x-large;
}
#setTime {
  text-align:right;
}
</style>
<script type="text/jscript" language="jscript">
var startTime;
var secTimerId;
var timerId;
 
function init() {
//  var oBackground = document.getElementById("imgBackground");
//  oBackground.src = "url(images/background.png)";
}
 
function startTimer() {
  startTime = new Date();
  doTimer();
}

function doSecTimer() {
  var diffSec = Math.floor(((new Date()).getTime() - startTime.getTime())/1000);
  var nextTime;
  var iMin=Math.floor(diffSec/60);
  var iSec=diffSec%60;
  var strMin=("0" + iMin);
  strMin = strMin.substr(strMin.length - 2, 2);
  var strSec=("0" + iSec);
  strSec=strSec.substr(strSec.length - 2, 2);
 
  document.getElementById('nowTime').innerHTML=strMin + ":" + strSec;

  nextTime = (startTime + 1000 * (1 + diffSec)) - (new Date()).getTime();
  if (0 < nextTime) {
    secTimerId=setTimeout("doSecTimer()", nextTime);
  } else {
    secTimerId=setTimeout("doSecTimer()", 100);
  }
}
 
function doTimer() {
  var time = Math.abs(document.getElementById('setTime').value * 60 * 1000);
  doSecTimer();
  timerId=setTimeout("finish()", time - ((new Date()).getTime() - startTime.getTime()));
}
 
function finish() {
  clearTimeout(secTimerId);
  clearTimeout(timerId);
}	
</script>
</head>
 
<body onload="init()">
<g:background id="imgBackground">
  <span id="gadgetContent">
    <span id="nowTime">00:00</span><br />
    <input  id="setTime" type="text" size="5" id="time" value="55" /> min <br />
    <input type="button" value="Start" onclick="startTimer()" />
    <input type="button" value="Stop" onclick="finish()" />
  </span>
</g:background>
</body>
</html>

<html>

<head>

body {

margin: 0;

width:130px;

height:100px;

font-family:Georgia, "Times New Roman", Times, serif;

font-weight:bold;

}

#gadgetContent {

margin-top:20px;

width:130px;

vertical-align:middle;

text-align:center;

overflow:hidden;

}

#nowTime {

text-align:left;

font-size:x-large;

}

#setTime {

text-align:right;

}

</style>

var startTime;

var secTimerId;

var timerId;

function init() {

// var oBackground = document.getElementById("imgBackground");

// oBackground.src = "url(images/background.png)";

}

function startTimer() {

startTime = new Date();

doTimer();

}

function doSecTimer() {

var diffSec = Math.floor(((new Date()).getTime() - startTime.getTime())/1000);

var nextTime;

var iMin=Math.floor(diffSec/60);

var iSec=diffSec%60;

var strMin=("0" + iMin);

strMin = strMin.substr(strMin.length - 2, 2);

var strSec=("0" + iSec);

strSec=strSec.substr(strSec.length - 2, 2);

document.getElementById('nowTime').innerHTML=strMin + ":" + strSec;

nextTime = (startTime + 1000 * (1 + diffSec)) - (new Date()).getTime();

if (0 < nextTime) {

secTimerId=setTimeout("doSecTimer()", nextTime);

} else {

secTimerId=setTimeout("doSecTimer()", 100);

}

function doTimer() {

var time = Math.abs(document.getElementById('setTime').value * 60 * 1000);

doSecTimer();

timerId=setTimeout("finish()", time - ((new Date()).getTime() - startTime.getTime()));

}

function finish() {

clearTimeout(secTimerId);

clearTimeout(timerId);

}

</script>

</head>

<g:background id="imgBackground">

</span>

</g:background>

</body>

</html>

ステップ3: マニフェストを記述する

作業フォルダーに新しく「gadget.xml」というファイルを作成します。

作成したファイルに次のように記述し保存します。Shift_JISの代わりにUTF-8で保存できるエディタの場合はencoding=”…”の部分は不要です。

<?xml version="1.0" encoding="Shift_JIS" ?>
<gadget>
  <name>Simple Timer</name>
  <version>1.0.0.0</version>
  <author name="【あなたの名前】">
    <info url="" />
  </author>
  <copyright>【あなたのコピーライト】</copyright>
  <description>A simple timer</description>
  <hosts>
    <host name="sidebar">
      <base type="HTML" apiVersion="1.0.0" src="Timer.html" />
      <permissions>Full</permissions>
      <platform minPlatformVersion="1.0" />
    </host>
  </hosts>
</gadget>

<?xml version="1.0" encoding="Shift_JIS" ?>

<name>Simple Timer</name>

</author>

<copyright>【あなたのコピーライト】</copyright>

<description>A simple timer</description>

<hosts>

</host>

</hosts>

</gadget>

ガジェットを動かしましょう

Windows Vistaの場合

サイドバーを右クリックで「ガジェットを追加」を選びます。

Windows 7の場合

Windows 7の場合はデスクトップの右クリックで「ガジェット」を選びます。

するとガジェットのリストに、「Simple Timer」が出てくるので、それを選びます。

パッケージを作る場合

作成した「Timer.html」「gadget.xml」の2つのファイルをzipにまとめます。zipにフォルダ名が保存されないように(zipファイルをダブルクリックした際に、フォルダではなくて2つのファイルが見える状態)、作成してください。そしてできあがったzipファイルを、「Timer.gadget」という名前に変更します。出来上がった「Timer.gadget」ファイルをダブルクリックしてインストールできるパッケージができます。

さあ、いかがですか？ちょっと見た目が悪いタイマーっぽいものが出てきましたね？

そして自分好みのタイマーに

今回作成したタイマーは、ガジェットの作り方の基本だけなので装飾していません。自分好みの背景画像や、色、フォント、さらにアニメーションを加えて、自分好みのタイマーに育ててみましょう。それがアプリケーション作りの醍醐味のひとつです。

また、このタイマーには指定時間が経過したことを通知するアラーム機能がありません。簡単なアラーム機能に関しては、上記のHTMLファイルを解説した「『初めてのWindowsサイドバーガジェット』ソースコード解説」という記事に記述しましたので、必要に応じて追記してみてください。

そうしているうちにガジェットのJavaScriptは原型を留めないほど変わるでしょう。その頃にはタイマーに限らず、自分の好きなガジェットが作れるようになっているはずです。楽しいガジェットを作って、世界に向けて発信しましょう！

参照資料

HTTPS Everywhere – 自分で任意に指定したサイトで自動的にhttpsになるようにする – Force-TLSをやめたときの覚え書き

2010-10-152021-11-16 清水文行

自動的にhttpsにするといえば、HSTSをFirefoxも4にて実装、とかのサーバ側で何かしないといけない仕組みの話題ばかりで、ブラウザ側に能動的に設定するための情報が探しにくくなったようです(Firesheepのおかげでまたそうでもなくなったようですが…)。かくて、自分で登録したサイトでhttpsを強制するFirefoxプラグイン Force-TLS

と、PC引っ越し用に覚え書きしましたが、あろうことか引っ越し先PCではサイトが追加できなかった(すごいところに設定ファイルがあったりするのだろうか)ので、問題の検証もせずにさくっと方針転換でhttps://addons.mozilla.org/firefox/tag/httpsを眺めてHTTPS Everyehereを試しました。https://www.eff.org/https-everywhere/rulesetsに従って簡単な正規表現を含むシンプルなXMLを作成。(2010/11/25追記: 自動更新版だと0.9.0よりtargetで1次フィルタするようになりました。targetが無いと気づかないうちにルール全体が無視されているので注意です。要エラーコンソールでの確認)

<ruleset name="HOGE">
  <target host="example.com" />     (自動更新版だと0.9.0より必要)
  <target host="www.example.com" /> (自動更新版だと0.9.0より必要)
  <rule from="^http://(?:www\.)?(example\.com/)" to="https://www.$1" />
</ruleset>

<target host="example.com" /> (自動更新版だと0.9.0より必要)

<target host="www.example.com" /> (自動更新版だと0.9.0より必要)

</ruleset>

書かれている場所に保管してFirefox再起動。さくっと動作。設定ダイアログにも指定したものたちがちゃんと登場。ファイル作る手間があるけどルールが汎用的に作れるのでこっちの方が便利かも。

2010/11/25追記: 一部であらかじめ登録されたサイトにしか使えないと受け取れる説明がされているようですが、HTTPS Everywhereは説明や上記のとおり、自分の好きなサイトを指定できます。

2010/11/25追記: 同じく一部で家庭用の無線LANでは不要と受け取れる記述もありますが、家庭用無線LANでも暗号化無しであったり弱い暗号でtap可能であれば同じこと(パスワード漏れ & セッションハイジャックされる可能性のある状態)です。モニタポートのある有線LANのスイッチングハブや、買うのが難しいでしょうがリピータハブにアクセス可能である状況もまた同じことです。Firesheepを相手に対策するのではなく、平文パスワードと、そしてセッションハイジャック対策としてクッキーを秘匿するためにHTTPSを使用すると考えなければいけないです。URLがhttps://で始まっていても、secure無しcookieで内容にHTTPが混在していたりJavaScriptでHTTPでアクセスしにいってしまっては元も子もないじゃん、というサイトもあり、今に始まった問題では全然ないですが、script kiddieでもFiresheepで簡単にセッションハイジャックできるようになったという状況のおかげでそのようなサイトが改善されるチャンスでもあります。

HSTSはSSL/TLSが有効なコンテキストにて、Apache HTTPDならば一番簡単な使い方で

Header set "Strict-Transport-Security" "max-age=ブラウザがこのことを覚えていて良い最大秒数"

1	Header set "Strict-Transport-Security" "max-age=ブラウザがこのことを覚えていて良い最大秒数"

とするだけです。

LibClamAV Error: cli_dbgets: Line too long for provided buffer – bytecode.cvd: version: 71

2010-09-282016-08-31 清水文行

bytecode.cvd: version: 71, sigs: 10, f-level: 53, builder: edwin で LibClamAV Error: cli_dbgets: Line too long for provided buffer が出るようになったようです(–bytecode=noでは起きません)。手元ではFreeBSD 8.1と7.1のClamAV 0.96.2で確認されていますが、0.96.3でも他のOSでも起きているようです。bytecode.cvdが修正されるまでエラー通知をどうにかしないと…といってるうちに修正されました。bytecode.cld: version: 72, sigs: 10, f-level: 53, builder: edwin で修正済みです。ありがたやありがたや。

ある日ソフトエラーを目の当たりにする

2010-09-072021-11-16 清水文行

アプリケーションの計算結果のテストのためにDBで大量の検索、挿入、更新、そして照合用も含めてファイルも大量に新規作成、削除、読み込みを何日も連続で繰り返さなければならないことがあります。連続で読み続けたり書き出し続けたりするのでディスクキャッシュを数百メガバイトに設定したところで効く由もなく、連続稼動用を謳っているハードディスクを3,4台のストライピングで使用しても負荷が激しすぎで3,4週間程度でお亡くなりになるのでどんだけひどい仕打ちをしてるんだろうと思ってしまいます。古いflash SSDだったら即死するかもしれません。ハードディスク交換していてはエコじゃないので使用量を減らすとすると、DBのデータを最初にRAMディスクにコピーし、一時ファイルもRAMディスク上というのが良さげですが、いっそOSごとDRAMのRAMディスクにして物理ディスクレスにしてしまおう、ということで1年ほど前にRAMディスク化しました。

マニュアルとOEM元Q&Aは良い(しかしどちらも日本語訳はすごすぎ)のですが、なぜかそれらと輸入代理店のFAQがいい感じに違っている某商品、DDR2メモリを積めるものです。1年たった今になって、実はunbuffered ECC対応、さらにunbuffered non-ECCでもジャンパーを刺せば容量の1/9使ってをECCエミュレーションをしてくれる(ハミング符号だとすると比率から64ビットバス+8冗長ビットのエミュレーションですね)という結構優秀な機能を持っていることがわかりました(輸入代理店はECC非サポートと明記している)。コストパフォーマンスからはunbuffered non-ECCのメモリを使ってECCエミュレーションするのが一番良さそうです。

しかしインストール時はそんなことには気づいてなかったのでnon-ECCメモリでECCエミュレーションも使わずに1年近くたった先日、その日はきました。演算結果の検証エラー。

正解	検証対象
.19;5	.1995

正解は数値であるはずだったので、すぐに正解の方がおかしいことに気づくことができるのが不幸中の幸いです。別途ハードディスク上に圧縮して保管されている検証用データと比較すると、検証対象の値で正しいことがわかりました。面白いのでこのファイルの文字セットUS-ASCIIでのコードポイントを調べてみます。

	9	;
hex	3 9	3 b
bin	0011 1001	0011 1011

その他の1GB程度の正解ファイルの検証、さらにOSとports部分はTripwireしているので検証したところ違いは検出されず()、RAMディスク起動時のデータも同様、そしてその後このようなエラーも起きずにいるのでソフトエラーということで間違いないようです。ビット反転によく見える形で遭遇してしまいました。機材近辺でのノイズであればエラーが頻発してもおかしくないような気がするので日常の宇宙線か、太陽フレアか、などと空のかなたに思いをはせていたところ、こんな記事がありました。

Google: Computer memory flakier than expected　(邦訳 – なぜか思い入れがえらく強いタイトルになってます…)

周辺の状況などもあるでしょうから場所、そして何の作業をしているところか、などの条件をどうしているのかちょっとわかりませんが、温度なんかどーっちゅうこともない、ハードエラーの方がソフトエラーよりcommonである(ECC前提での話?)、など面白いです。温度が経年変化に与える影響なんかも調べられてるんでしょうか。時間ができたら元の論文読むべしです。

さらに温度といえばグーグルの最新のデータセンターは非常識なほど進化しているだそうで、自宅サーバなんて昔から室温50度超えになっちゃうようなところで並んで動いていたわけで進化なのかどうかは置いておくとして、かつて大学のコンピュータがある場所では壁一面にウルトラマンに出てくるような巨大なテープが回ってる箱が並んでいてエアコンがガンガンに効いている、なんてのはいったい何の話?ってなもんですね。

何よりも実感したのは、サーバだけじゃなくてテスト機にもECC使わないとだめじゃん、ということです。考えれば当たり前な話ですが、それを言い始めるとnon-ECCで良い仕事ってあるんだろうか…

追記: bitsquatting面白い!

ClamAV 0.96.2 on FreeBSD 7.1

2010-09-062021-11-16 清水文行

ClamAV 0.96.2のソケットがFreeBSD 7.1でchokeする問題

ありがたいことに既にports tree更新されてる(PORTREVISION=2なので0.96.2_2以降)ので、

portsnap fetch
portsnap update

1 2	portsnap fetch portsnap update

したら

portupgrade 'clam*'

1	portupgrade 'clam*'

とか

portmaster 'clam*'

1	portmaster 'clam*'

で解決ですね。ありがたやありがたや。

定例外Windows Update KB2286198

2010-08-032016-08-26 清水文行

毎月第2火曜日の次の日ではないですが、各所から通知が飛んできている通り半月前の脆弱性に対する定例外の重要なWindows Updateが出ています。手動の方はご注意を。

server does not support RFC 5746, see CVE-2009-3555 (was: potentially vulnerable to CVE-2009-3555) Apache HTTPD + OpenSSLでRFC5746リネゴシエーション対応

2010-06-172021-11-16 清水文行

CVE-2011-0411 Plaintext command injection in STARTTLSはこちら

Bug 549641の変更をここのタイトルにも入れてみました(2010/9/14) 。元々「潜在的に脆弱」という微妙なメッセージから書き起こしたエントリなので、文章のつながりが悪くなったかもしれません。

CVE-2009-3555はDescriptionによればSSL3.0(とおそらくそれより前)とTLSプロトコルにおいて、”renegotioation”でMITM攻撃者がデータを挿入可能である、というものになり、去年の11月に業界(?)を震撼(?)させたものです。

この問題を解決するべくIETFのTLSな方たちは世のため他人のため、ものすごい勢いで”secure renegotiation”(安全な再ネゴシエーション)を定義して本年2月までにRFC5746にしてくれました。

表題のメッセージはFirefoxがhttps://なサイトにアクセスした場合や、ThunderbirdがSSL,TLSでPOP3, IMAP4, SMTPアクセスした場合などなどでエラーコンソールにログされるものですが、mozilla wiki Security:Renegotiationを超訳すると、「まだ問題があるwebサーバだらけで、今よく見えるように警告してしまうとそれを無視しましょうとのたまう人が出てきて、ユーザは似たような警告も含めて無視する習慣が付いてしまうだけで世の中が幸せにならない。だから潜在的に問題のあるサーバはそっとエラーコンソールにログするだけ」とのことです。実際にはRFC5746を実装していないwebサーバとのTLS/SSL使用時に表示されるので、webサーバ側にrenegotiationを全て無効にする形でのパッチが適用されている場合、webサーバとしてはCVE-2009-3555に対して脆弱でなくでもそれを通信中のフラグ(RFC5746対応している場合にはServerHelloのextentionのrenegotiation_infoが付いてくる)では検知できないのでFirefoxのエラーコンソールに表題のメッセージがログされます。

表題のメッセージを消す==webサーバをRFC5746のsecure renegotiationに対応させるためにすることをざっくり書くと、OpenSSLとApache HTTPD(mod_ssl)2.2系列の場合、

対象のwebサーバにhttps://で接続してFirefoxのエラーコンソールに表題のログが表示されることを確認。
先にOpenSSLを0.9.8m以降にアップデート。(2014/4/8現在1.0.1g以降をお勧め)
次にApache HTTPD 2.2系列の場合2.2.15以降(2010/9/14現在2.2.16以降をお勧め)にアップデートかリビルド。
再度https://で接続してFirefoxのエラーコンソールに表題のログが表示されなくなったことを確認。

となります。(悲しいことにrenegotiationしないと続行できない状況の場合、~~いまだRFC5746非対応であるIE~~(←末尾に追記)RFC5746非対応ブラウザなどで問題になり、わざわざmod_sslにSSLInsecureRenegotiationディレクティブを使用して古いrenegotiationを有効にせざるをえなくて困っているサーバ管理者の方も多いです)

その他にもご自分のwebサーバがインターネット上にあればQualys SSL LabsのSSL Server Testにて、SSL,TLS全般の確認ができます(表示されているように、別のURLで流れさるまでの何時間かURLと結果がさらされます(その後指定すればさらされないようになりました)。さらに上位と下位は別枠で表示してくれます)。結果のMiscellaneousのRenegotiationの項に、安全なのか古いリネゴが使えてしまう状態か、などが表示されます。

クライアントのRFC5746対応も必要ですが、表題のログがエラーコンソールに出ている時点で当然古いrenegotiationを問題視しているwebブラウザを使用していることになるのでここでは考えないことにします。webブラウザのRFC5746対応はmozilla wiki Security:Renegotiationに書かれているように~~https://ssltls.de/~~で確認できます(←末尾にちょっと追記)。有るべき姿はwebブラウザ、webサーバに限らず、「SSL,TLSを用いた全てのクライアントとサーバがRFC5746に対応していること」になります。

ではwebサーバとしてはCVE-2009-3555に対して脆弱でなくてもログされる場合(薦められた状態ではないですが)はというと…

例えばOpenSSLのChangeLogを見ると、

2009/11/5 Changes between 0.9.8k and 0.9.8l
   すべての renegotiation を無効にしてやったぜ。

1 2	2009/11/5 Changes between 0.9.8k and 0.9.8l すべての renegotiation を無効にしてやったぜ。

2010/2/25 Changes between 0.9.8l and 0.9.8m
   RFC5746実装。

1 2	2010/2/25 Changes between 0.9.8l and 0.9.8m RFC5746実装。

となっていて、またFreeBSD Security Advisoriesの2009/12/3 FreeBSD-SA-09:15.sslでは

  よく注意: このアップデートで、renegotiationは全部拒否しちゃうようになるからね

1	よく注意: このアップデートで、renegotiationは全部拒否しちゃうようになるからね

となっています。ソースレポジトリを見ると2010/6/15現在-CURRENTとRELENG_8(-STABLE), RELENG_8_1がOpenSSL 0.9.8nであり、他は OpenSSL 0.9.8eとかkとか + SA-09:15 ということになるようです。

さらにApache HTTPD 2.2.15のChangeLogでは、

  OpenSSL 0.9.8lより前とコンパイルした場合はクライアントがinitiateしたrenegotiationを拒否。
  OpenSSL 0.9.8m以降とコンパイルした場合は包括的修正が適用される

1 2	OpenSSL 0.9.8lより前とコンパイルした場合はクライアントがinitiateしたrenegotiationを拒否。 OpenSSL 0.9.8m以降とコンパイルした場合は包括的修正が適用される

となっているので、Apache HTTPD(mod_ssl) 2.2.15以降の2.2系列をOpenSSL 0.9.8m以降のライブラリでコンパイル、リンクすることでRFC5746のsecure renegotiation対応になります。

Apache HTTPDにSSLInsecureRenegotiation指定をしない前提でまとめていくと2010/6/15現在

FreeBSD 8.1(現在ベータ1,7月リリース予定)のOpenSSLは0.9.8nなのでRFC5746対応。したがってCVE-2009-3555に対しては脆弱ではない。

FreeBSD 8.0, 7.3, 7.1各セキュリティブランチを最新の状態にしている人のOpenSSLは0.9.8? + SA-09:15なのでRFC5746は対応していないが、renegotiationを全部無効にすることでCVE-2009-3555に対しては脆弱ではない。

OpenSSL 0.9.8l
あるいはFreeBSD 8.0, 7.3, 7.1各セキュリティブランチのOpenSSL(0.9.8? + SA-09:15)
+ Apache HTTPD(mod_ssl) 2.2系列全部
の場合は

表題のエラーコンソールログは表示される(RFC5746非対応)
CVE-2009-3555についてwebサーバは脆弱ではない(ただしrenegotiationがすべて無効)

OpenSSL 0.9.8m以降(2010/6/15現在OpenSSL 1.0.0a以降をお勧めします)
+ Apache HTTPD(mod_ssl) 2.2.15以降の2.2系列
の場合は

表題のエラーコンソールログは表示されない(RFC5746対応)
CVE-2009-3555についてwebサーバは脆弱ではない(RFC5746対応)

要注意なのは、Apache HTTPD 2.2.15にしただけで安心してしまう次のパターンでしょうか。現実的にMITM攻撃が成立するかは考えずにChangeLogからだけ言うとするとCVE-2009-3555に対してwebサーバは脆弱です。
OpenSSL 0.9.8k以下(FreeBSDの場合は0.9.8k以下かつSA-09:15のアップデートがされていない場合)
+ Apache HTTPD 2.2.15以降の2.2系列、
あるいは2.2.14 + http://www.apache.org/dist/httpd/patches/apply_to_2.2.14/CVE-2009-3555-2.2.patch
の場合は、

表題のエラーコンソールログは当然表示される(RFC5746非対応)
CVE-2009-3555に対しては * 脆弱である *
(クライアントがinitiateした場合のrenegotiationを拒否しているだけ)

まずサーバ側の古いrenegotiationの実装が一掃され(同時にメジャーwebブラウザが全部RFC5746対応するという壁も大きいようで)、そしてRFC5746実装が使用され、renegotiationの一部や全部を無効にしただけのパッチがおおよそ一掃されて、それからようやく表題のエラーコンソールのログが派手な警告なりエラーなりに格上げされることになると思われますが、まだまだかかりそうですね…
例:https://bugzilla.mozilla.org/show_bug.cgi?id=555952

FreeBSD 8.0, 7.3, 7.1 + Apache HTTPD(mod_ssl)で表題のエラーコンソールログが出なくなるようにする、つまりRFC5746対応にするには、2010/6/15現在SA-09:15ではOpenSSLのrenegotiationを全部無効にしているためApache HTTPD(mod_ssl)を2.2.15にするだけでは不十分であり、こどもの日にportsがOpenSSL 0.9.8mに対応された(2010/6/15現在1.0.0a対応)ので、これを使うのが早そうです。

# portsnap fetch
# portsnap update
# portinstall security/openssl
# env WITH_OPENSSL_PORT=yes portupgrade -f www/apache22
# ldd /usr/local/libexec/apache22/mod_ssl.so
/usr/local/libexec/apache22/mod_ssl.so:
        libssl.so.7 => /usr/local/lib/libssl.so.7
        libcrypto.so.7 => /usr/local/lib/libcrypto.so.7
        ...

# portsnap fetch

# portsnap update

# portinstall security/openssl

# env WITH_OPENSSL_PORT=yes portupgrade -f www/apache22

# ldd /usr/local/libexec/apache22/mod_ssl.so

/usr/local/libexec/apache22/mod_ssl.so:

libssl.so.7 => /usr/local/lib/libssl.so.7

libcrypto.so.7 => /usr/local/lib/libcrypto.so.7

...

最後の表示では、特に/usr/lib/や/lib/ではなくて、/usr/local/lib/libssl.so.*, /usr/local/lib/libcrypto.so.*であることを確認する必要があります。

あらかじめFirefoxでhttps://接続してエラーコンソールに表題のものがログされていることを確認した後、アップデート作業後にログされなくなればRFC5746対応完了です。

Windows関連ちょっとだけ追記(2010/9/14)。 2010年8月の月例(日本だと8/11あたり)のアップデート群に含まれていたKB980436: MS10-049: Vulnerabilities in SChannel could allow remote code executionによってWindowsのTLS/SSLスタックがRFC5746対応されましたが、それが使われるWindows XPのIEで https://ssltls.de/ のペンギンさんが表示されないのを確認しようとしてたこともあって時間がとれずに一月経ってしまいました。どうやらmod_nssを使った環境を作らないとちゃんと確認できなそうなので、先ほどざっと確認した現象だけ列挙しておきます。

Opera,Firefoxは結構前からペンギンさんが表示される。
KB980436が適用されたWindows Vistaではペンギンさんは表示される。
KB980436が適用されていてもWindows XP, 2003ではIEのバージョンによらず、ClientHelloのextentionでもSCSVでもペンギンさんは表示されない。
Windows XP(IE)のClientHelloのextentionにはtype 0xFF01(renegotiation_info)しかないが、Vista(IE)やOperaはそれに加えてserver_nameやstatus_requestなどがある。
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL にUseScsvForTlsという名前のDWORD値を作成して1をセットすると、Windows XP(IE)ではClientHelloのextentionが無くなる。Firefoxはserver_nameやstatus_requestなどがある。どちらもrenegotiatoin_infoは無く、cipher suiteに0x00FFが追加されている(SCSV)。

次はmod_nss環境を作成してnssのデバッグログを吐かせるところからになりますが、誰かとっくのとうに解決していたら教えてくださいませ。

なおWindows(IE,IISなど)で古いリネゴを拒否する方法はKB980436に書かれています。レジストリをいじって

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"AllowInsecureRenegoClients"=dword:00000000

1 2	[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "AllowInsecureRenegoClients"=dword:00000000

で再起動すればサーバ(IISなど)が、そして

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"AllowInsecureRenegoServers"=dword:00000000

1 2	[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "AllowInsecureRenegoServers"=dword:00000000

で再起動すればクライアント(IEなど)が古いリネゴを拒否するようになります(いろいろ使えなくなるものが出るようなので、まだ不便かもしれません)。

その他の参考リンク

あ、その金庫、横に鍵が張り付けてありますが中身大丈夫ですか?

2010-04-102021-11-16 清水文行

「動けばよいってもんじゃない」ですが、ショッピングカートはその最たるものの一つです。かつてネット通販が出始めの頃、いろいろなケースに出会いました…

最も多かった問題が、返信メールに記載されたURLをクリックするとログインもしていない(そういう通販サイトにはcookieとかセッションとかいう概念が存在しません)のに住所から注文内容から確認できるものです。メールにURLを記載しなければ良いという話でもなく、注文するときはそのようなシステムと知らないわけで、注文終わってからあーやばい通販だったかと学習することになります。今では使う通販も決まってきて新しいシステムの通販に手を出すことはほとんどないのでそういう思いをすることもまずないですが、いまだに某大手ISPのアンケートシステムでも使われてました。海外のTシャツ屋、今は無くなってしまった書店、今もある比較的大手の通販、などなど何度か出会いました。「該当URLが404を返すようにして、あと恐ろしいのでカードの情報も削除しておいてね」とお願いすると、そのすべてから「URLにランダムな文字列が入っているので大丈夫!」(鍵が貼り付けてある金庫なので当然大丈夫じゃないです。念のため)「SSLだからデータは安全!」(通信路の暗号化であり、しかもメールで送られてきてしまったURLは暗号化されていないうえに両端ではデータは復号化された状態なので全然大丈夫じゃないです…)と笑い話にもならない自信満々のお返事を頂戴したものです。

このたび「noindex,nofollow,noarchiveと書いてあるし、user agentでロボットはじいているから大丈夫!」という説も増えたようですが、何にせよ鍵が横に貼り付けてある金庫を、メールで送ったりブラウザから送信させておいて、その金庫の中身が大丈夫だと言ってしまうのはこれまた…

今時ですとブラウザに各種ツールバーをインストールされている方も昔よりも格段に多いでしょうから、tappingやらbrute forceされるまでもなく、そして自らが認識しているかどうかにかかわらず閲覧しているURLが他ホストに自動的に送られている場合も、セキュリティのためなどと称して多数あることでしょう。また別の側面では「ランダムな文字列」が実は順番の数字のBASE64エンコードだったりソルト無しハッシュ値のような、なんちゃってランダムだったときにもノーガード公開状態となります。

このようなシステムを作ってしまう人がここ十数年絶えることなく出続けてきたわけですから、webアプリ作成者の常識に期待することをあきらめるとすると今回のような深刻な犠牲者を増やさないためにはどうすればよいでしょうか。セキュリティソフトと呼ばれるものの中には生のまま特定の情報が送受信される場合に通信を遮断する機能を持つものがありますが、メールで送られてくるURLの場合のように他人のシステムから送られてきてしまう場合、そしてそのページに問題がある場合にはいかんともしようがありません。良さそうなのは、ショッピングカートに限らず鍵付き金庫をばら撒くようなシステム採用サイトのレピュテーションサービスでしょうか。コミュニティーベースでしか成立しそうにないですが、消費者保護とサービス提供者の常識確保のために政府にやっていただければ良いですね。そしてやはり経営者さん、特に消費者の不利益に直結するサイトを運営されている経営者の方たちも「動けばいいってもんじゃない」を考えていただけるとありがたいです。

と今回の某通販での大惨事の記事を見て思ったことでした。

文書に記述する際の説明用/例示用のドメイン名、IPアドレス、MACアドレス RFC6890,RFC5737,RFC3849,RFC2606,RFC6761,RFC7042 IANAなどなど

2010-02-162021-11-25 清水文行

説明書などでドメイン名を例示するときに、 hoge とか foo とか bar とか chome などにを適当なTLDをつなげたり、最近ではTLDとして使ってしまうと自分のドメインでない場合や、自分のドメインでも更新しなかった場合などに問題になる可能性があります。IPアドレスもしかりです。そのままコピペされたり検索エンジンにインデックスされて他人に迷惑をかけないためにも、文書に記述するときに使ってよいドメイン名、IPアドレス、MACアドレス(EUI-48)が決まっています。

RFC6890によって RFC5735 はobsoleteにされました。(RFC5735によって RFC3330 はobsoleteにされました。参考: IPv4枯渇)

2016-06-28 MACアドレス関連追記
2013-10-11 RFC6890関連追記(Documentation用IPアドレスの変更はありません)
2011-02-10 .lg.jp関連追記
2011-01-26 .テストなどTLD関連追記
2010-03-17 .jp関連追記

192.0.2.0/24	192.0.2.0 – 192.0.2.255	TEST-NET-1 (TEST-NET)	RFC6890 RFC5737(RFC5735 RFC3330)
198.51.100.0/24	198.51.100.0 – 198.51.100.255	TEST-NET-2	RFC6890 RFC5737(RFC5735 RFC3330)
203.0.113.0/24	203.0.113.0 – 203.0.113.255	TEST-NET-3	RFC6890 RFC5737(RFC5735)
2001:db8::/32	2001:db8::0 – 2001:db8:ffff:ffff:ffff:ffff:ffff:ffff	Documentation Prefix	RFC6890 RFC3849(RFC5156)
00-00-5E-00-53-	00-00-5E-00-53-00 – 00-00-5E-00-53-FF	EUI-48 (MAC addresses) Documentation Values	RFC7042 2.1.2 (2.1.1)
00-00-5E-EF-10-00-00- 他	00-00-5E-EF-10-00-00-00 – 00-00-5E-EF-10-00-00-FF	EUI-64 (unmodified 64-bit MAC addresses) Documentation Values	RFC7042 2.2.3
.test	recommended for use in testing	TLDs for Testing, & Documentation Examples	RFC2606 RFC6761
.测试(.XN–0ZWM56D) .परीक्षा(.XN–11B5BS3A9AJ6G) .испытание(.XN–80AKHBYKNJ4F) .테스트(.XN–9T4B11YI5A) .測試(.XN–G6W251D) .பரிட்சை(.XN–HLCJ6AYA9ESC7A) .δοκιμή(.XN–JXALPDLP) .テスト(.XN–ZCKZAH) .טעסט (.XN–DEBA0AD) .آزمایشی (.XN–HGBK6AJ7F53BBA) .إختبار (.XN–KGBECHTV)	e.g. ほげ.テスト (xn--18j4d.xn--zckzah)	Reserved for testing internationalised domain names	Root Zone Database
.example	recommended for use in documentation or as examples e.g. hoge.example	TLDs for Testing, & Documentation Examples	RFC2606 RFC6761
.invalid	intended for use in online construction of domain names that are sure to be invalid	TLDs for Testing, & Documentation Examples	RFC2606 RFC6761
.localhost	having an A record(DNS) pointing to the loop back IP address and is reserved for such use	TLDs for Testing, & Documentation Examples	RFC2606 RFC6761
example.com	e.g. hoge.example.com, example.com	Reserved Example Second Level Domain Names	RFC2606 RFC6761
example.net	e.g. hoge.example.net, example.net	Reserved Example Second Level Domain Names	RFC2606 RFC6761
example.org	e.g. hoge.example.org, example.org	Reserved Example Second Level Domain Names	RFC2606 RFC6761
example.jp example0.jp example1.jp … example9.jp ドメイン名例.jp (xn--eckwd4c7cu47r2wf.jp)	e.g. hoge.example.jp, example7.jp, ほげ.ドメイン名例.jp (xn--18j4d.xn--eckwd4c7cu47r2wf.jp)		汎用 JP ドメイン名における予約ドメイン名の3 JPRS FAQ
example.<属性ラベル>.jp example0.<属性ラベル>.jp … example9.<属性ラベル>.jp example.<市区町村ラベル>.<都道府県ラベル>.jp … example.<都道府県属性ラベル>.<都道府県ラベル>.jp … example.<市区町村属性ラベル>.<市区町村ラベル>.<都道府県ラベル>.jp … など詳細は右記技術細則にて	e.g. hoge.example3.ed.jp, example7.city.shibuya.tokyo.jp		属性型（組織種別型）・地域型JPドメイン名登録等に関する技術細則の4.4 JPRS FAQ
example.lg.jp example0.lg.jp … example9.lg.jp	e.g. city.example8.lg.jp		LG ドメイン名登録等に関する技術細則の3.4 JPRS FAQ

日経など:中国製「雷ガード」、発煙・発火12件　輸入元、無償交換へ

2010-01-222021-11-16 清水文行

Googleで検索:中国製「雷ガード」、発煙・発火12件　輸入元、無償交換へ
ノア「雷保護装置（雷ガード）」（1999年4月以降に販売） – 交換
サンワサプライ株式会社「雷ガード」無償交換のお知らせ: TAP-SP1（NE-222）,TAP-SP102（NE-222）,TAP-SP4（NE-888）,TAP-SP103（NE-888)
経済産業省:製品品安全ガイド

リコール情報を見てからぼちぼち探していましたが、昔気休め用に使ったのがいくつか有りました。もう使っていないので、新しいのをもらうよりも捨てる方がまだ地球に優しいでしょうか。

しかしPDFでお知らせするところが多いです。そんなアプリがあるんだとか、今そのバージョン使ってちゃだめじゃん、とかプロパティが面白いっちゃ面白いんですが。

本当は怖いtar

2010-01-212016-08-26 清水文行

などと刺激的なタイトルをつけてしまいましたが、「ディレクトリトラバーサル」とか「GNU tarのsuper userでの展開時のumask」とかを思い起こす方が多いと思います。主に展開時に大きな問題になるそれらも重要なことなのはもちろんですが、基本も忘れずにしていないと作成時でも泣きをみるかもしれません。設定ファイルのバックアップを取ろうとしたとします。

% su
# cd /
# rm /somewhere/hoge.tar
# tar cvf /somewhere/hoge.tar etc usr/local/etc

% su

# cd /

# rm /somewhere/hoge.tar

# tar cvf /somewhere/hoge.tar etc usr/local/etc

深く考えずにやってしまいそうですが… umaskの確認をお忘れなく。/somewhere/が論理的に他人に読めず物理的にも安全な場所であれば完璧です。単純にsudoを設定すれば防げるという話でもなく、.profileや.cshrcでumaskを厳しく設定していても、普段自分だけがユーザの機械での作業をメインにされている方は他人の機械で作業しているときは忘れてしまうかもしれません。

% su
# umask 077
# cd /
# rm /somewhere/hoge.tar
# tar cvf /somewhere/hoge.tar etc usr/local/etc

% su

# umask 077

# cd /

# rm /somewhere/hoge.tar

# tar cvf /somewhere/hoge.tar etc usr/local/etc

のようにする癖が付いていれば、せっかく読めなくなっているファイル(例:/etc/master.passwdやら/etc/shadowやら)を他のユーザが読めてしまう危険が激減します。既存のファイルに追記する場合はモードの確認も必要です。

% su
# umask 077
# cd /
# chmod go= /somewhere/hoge.tar
# tar rvf /somewhere/hoge.tar etc usr/local/etc

% su

# umask 077

# cd /

# chmod go= /somewhere/hoge.tar

# tar rvf /somewhere/hoge.tar etc usr/local/etc

cpio, dd, zip, 普通にcp などなどなど、そしてWindowsも含めて暗号化ファイルシステム上のファイルをzipしたりコピーするときなどなどなど、コピー元が安全にしてあってもコピー先で読めてしまってはいけません。プログラミングでは一時ファイルを作成する際とかも関連事項です。当たり前すぎ?こりゃまた失礼いたしました。

kana.me 要

カテゴリー: Security

自転車用リアチャイルドシートリコール問題

PivotXを利用されている方は最新版にアップデートするべし (was: PivotXを利用されている方は2.2.5以降へアップデートするべし CVE-2011-1035)

浮動少数問題 Java版 CVE-2010-4476

DNSSEC始めました

【ランチタイムラーニング】初めてのWindowsガジェット – お昼を食べながらガジェットを作ってみよう – Windows 7 デスクトップおよびVista サイドバー

何を作るか

材料を準備しましょう

【材料】

さっそくガジェットを作りましょう

手順と成果物の概要

ステップ1: 作業フォルダの作成

ステップ2: JavaScriptを含んだHTMLを記述する

ステップ3: マニフェストを記述する

ガジェットを動かしましょう

Windows Vistaの場合

Windows 7の場合

パッケージを作る場合

そして自分好みのタイマーに

参照資料

HTTPS Everywhere – 自分で任意に指定したサイトで自動的にhttpsになるようにする – Force-TLSをやめたときの覚え書き

LibClamAV Error: cli_dbgets: Line too long for provided buffer – bytecode.cvd: version: 71

ある日ソフトエラーを目の当たりにする

ClamAV 0.96.2 on FreeBSD 7.1

定例外Windows Update KB2286198

server does not support RFC 5746, see CVE-2009-3555 (was: potentially vulnerable to CVE-2009-3555) Apache HTTPD + OpenSSLでRFC5746リネゴシエーション対応

あ、その金庫、横に鍵が張り付けてありますが中身大丈夫ですか?

文書に記述する際の説明用/例示用のドメイン名、IPアドレス、MACアドレス RFC6890,RFC5737,RFC3849,RFC2606,RFC6761,RFC7042 IANAなどなど

日経など:中国製「雷ガード」、発煙・発火12件　輸入元、無償交換へ

本当は怖いtar