は、およそ２歳になる大人の三毛猫なのだが、最近しばしば、水呑場で、左掌を水皿に浸して、水を「王家」という言葉を繰り返し使わせているのは、この言葉の信者であると目される、時代考証の先生であろう。
それに、その時代考証の先生曰く「歴史に暗い」とされる脚本家を人選した時点で、こういう作品になるのは自然な流れなのだろうし、ＮＨＫの今回の大河ドラマを決めた人の意図はそこにあるように思える。
Wikipediaによれば、龍馬伝と平清盛で共通しているスタッフは、演出の渡辺一貴という人だけのようである。
しかし、両者に共通するこの空気感は、演出担当者一人の仕業ではあるまい。
ちなみに、平清盛の制作統括は、同Wikipediaによると、磯智明氏と落合将氏となっているが、磯智明氏の関った作品をざっと検索したところ、次の様になった。
こうしてみると、磯智明氏は、例の「暗い画面」を比較的好んで使うような印象である。
筆者としては、「暗い画面」はせいぜいが「カーネーション」程度迄が許容範囲で、「龍馬伝」や「平清盛」の様に汚されると、受け容れがたい。
ＮＨＫは自社制作のドラマでは、薄汚れた感じの登場人物として我が国の歴史上の人物を表現すると同時に、某国ドラマは明るく清潔感の漂う画面のドラマを選んで放送している様である。
史実は逆であるのに。
今後の興味は、今年の大河ドラマの視聴率推移である。
これが、龍馬伝と同様の推移となるのかどうか、それによって、視聴者大多数の印象がどうだったかが測れるように思える。
（１月11日追記）
関東地区の視聴率は17.3％で、初回としては３番目に悪いものだったようだ。
「王家」の表現については議論が再燃しているが、違和感を訴える書き込みに対して、頑強に擁護する書き込みが見受けられる。工作員だろう。
比較的冷静かつ理論的な議論がなされているのは、２ch大河ドラマ板の「平清盛 考証スレ」だと思う。
898+4 ：日曜8時の名無しさん [↓] ：2012/01/10(火) 16:04:02.52 ID:bXX957l1 (2/2)
>>895
以前の考証スレとか、いくつかの論文も読んでみたけど、
「王家」の定義と、使われるようになった流れはこんな認識でいい？30年くらい前に、黒田俊雄という学者が「権門体制論」という学説を唱えた。
これは中世期の日本は、貴族から武士へ政権が移ったという単純な図式ではなく、
複数の大きな力を持った門閥が複雑に絡み合い、一つの国家を形成していたという見方。
そしてその門閥（権門勢家）を「王家」「摂関家」「武家」「寺家・社家」と定義した。
「家」は権力・経済の一まとまりの単位で、血縁関係のある家族という狭い範囲だけを
表すものではない。「王家」は治天の君が家長として天皇位や財産の継承権を握っていた院政期
の天皇の家を呼ぶのに限定された用語で、中世以外の時代の天皇の家を
王家とは呼ばない。使っているのは一部の中世史学分野の学者のみ。「天皇の家」という概念自体が最近のものなので、適切な言葉は史料にみつけるのは
難しい。
（皇室・天皇家は史料に例がなく、朝家では政治に携わる一部の貴族をも含んでしまう。
王家は用例はあるが、仏法に対して世俗を支配する「王」の意味としての性格が強く、
相応しいとは言えない。皇家ではなく王家を選んだのは単に黒田の好み。
これまで大した批判は行われていないが、「院宮家」を使うのがふさわしいと
いう学者もいる）910+1 ：日曜8時の名無しさん [↓] ：2012/01/10(火) 18:38:58.34 ID:1f1R3bWw (3/3)
あの時代に”天皇の家”なんて概念がまず無いしな。
勝手に創作した学者がいるんだろう。
914 ：日曜8時の名無しさん [↓] ：2012/01/10(火) 19:13:43.72 ID:sTjuW7lL (18/21)
>>910
いや後世の人間が便宜上使う用語だから、それは別に問題ない。問題なのは、そんな用語をドラマ内の人間がガシガシ使っちゃってることで。
918+1 ：日曜8時の名無しさん [↓] ：2012/01/10(火) 20:14:16.88 ID:X7cTj0iB (14/19)
「王家」については>>898のまとめでほぼ尽きていると思われ。
で、同時代で使われていない言葉でもドラマで使うことができるかどうかというのを検討してみると１ その言葉をドラマの中で使う必要性があるか
２ その言葉が視聴者にちゃんと通じるか
の２点について考えなければならないと思う。
919 ：日曜8時の名無しさん [↓] ：2012/01/10(火) 20:16:20.09 ID:sTjuW7lL (20/21)
いや898のまとめもそんなに正確というわけではないから、
本来は各人が調べた方がいいよ。
例の歴史評論を１冊読むだけでも相当わかる。
920+1 ：日曜8時の名無しさん [] ：2012/01/10(火) 20:17:40.02 ID:Sk0diQdJ (1/2)
>>898 アホか。
現代の学者が言い出したことやない。コッチに、上手く、まとまってる。
まず『平安遺文』3837号文書の「治承二年六月紀伊国大伝法院衆徒解案」に、
「夫王家之為王家、在仏法之擁護、仏法之為仏法、任王家之帰依」
とあります。治承二年は1178年で以仁王の挙兵(治承四年)の直前ですね。簡単に訳すと、
「王家(現在でいう皇族)」が王家であるのは仏法の擁護があるからだ。仏法が仏法であるのは王家が帰依しているからだ」
ということになります。次は『花園天皇宸記』の元弘元年(1331)別記10月1日条から。『花園天皇宸記』は花園天皇自筆の日記であり・・・・・
皇室を王家としたことについて
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1271855592
921 ：日曜8時の名無しさん [↓] ：2012/01/10(火) 20:20:39.43 ID:HVzkKGaL
少なくとも王家という呼び方は現代の日本人の感覚にそぐわない 以上
922+1 ：日曜8時の名無しさん [↓] ：2012/01/10(火) 20:23:35.54 ID:X7cTj0iB (15/19)
>>918
Ａ まず「幕府」について検討すると１ ドラマの中で鎌倉・室町・江戸の各武家政権を指し示す用語を使う必要性は極めて高い。
２ 「幕府」ということばは日本人は誰でも知っている。ので「幕府」はたとえ後世の言葉だろうとドラマで使っていい。むしろ使うべき言葉。
Ｂ 「得宗」（「北条時宗」でセリフで頻出）
１ 主人公である時宗らの地位を表す言葉だから必要性は高い。
２ 小学校や中学校の教科書には出てこないが、高校の日本史教科書には出てくる。ので、実際オンエア中は違和感ありまくりだったけど使っていい言葉だと思う。
Ｃ 「国人一揆」（「毛利元就」で使われなかった）
１ 毛利元就の成功物語なら国人一揆に触れる必要性は高い。
２ 「国人一揆」は高校の教科書にしか出てこない。さらに致命的なのは現代人にとって「一揆」といえば
「百姓一揆」のことであり「支配階級の同盟」というニュアンスを伝えることが難しい。だから「毛利元就」のセリフ中では「国人一揆」にあたる概念はすべて「国人衆の盟約」に置き換えられていた。
このＮＨＫと西舘の判断は極めて正しいと思う。Ｄ 「王家」
１ 第1回を見る限り「王家」はすべて「朝廷」に置き換えた方がよく「政治機構や貴族たちと区別された天皇家」という概念を用いる必要性が全く感じられない。
２ 「王家」という言葉は学術用語にすぎず一般に定着していてない。だから「王家」はアウト。
923 ：日曜8時の名無しさん [↓] ：2012/01/10(火) 20:25:42.17 ID:X7cTj0iB (16/19)
>>920
だからその「王家」って「寺社勢力に対する世俗権力」という意味で
「政治機構や貴族たちと区別された天皇家」という意味じゃない。
924 ：日曜8時の名無しさん [↓] ：2012/01/10(火) 20:43:15.38 ID:X7cTj0iB (17/19)
>>922 Ｅ 「惣無事令」（「独眼竜政宗」のセリフで頻出）
１ 伊達政宗と豊臣政権との関係を物語るためには必須といってよい。
２ 現在は高校教科書にも「惣無事令」が出ているが、オンエア当時はまだ新奇な学術用語であった。これは２の要件が微妙だったけど、内容は権力闘争に関わることだから劇中で説明すれば視聴者に通じたので
これは使って正しかったと思う。
時代考証者の一人である本郷氏自身が、ドラマで描いた時代当時には皇統に「家」の概念は無かったとしているのだから、当時の一般的な用語として「王家」は有り得ない。
学術用語として使っている歴史学者が一部に居るということなので、現代用語としては存在するとしていいだろう。そうすると、上記引用の様に、その現代語をドラマ中で使うことが適切なのかということになる。
簡単にいってしまえば、天皇を「日王（＝日本の王）」として辱める呼び方をする国が近隣にあるのだから、それを連想させる言葉をドラマ中で用いるのは不適切だと思う。
昨年８月の時点で一度騒ぎになっているのにも関らず、ＮＨＫはこの度「王家」の使用を強行したわけで、ドラマ制作の最高責任者である制作統括に、どうしても使いたい事情があったと考えざるを得ない。
他にも、歴史的に有り得ない事（例えば死罪を命じるとか。当時の最高刑は流罪）は多々有るのに、なぜか、「王家」だけは史実云々と説明しているところに、このドラマの怪しさを感じる。妙な思想を感じさせるドラマは楽しめない。
出演された役者の方々の演技は概ね良い印象だったので、別のところで嫌気がさしてしまう状況は、まことに残念である。
サモア 日付変更最も早い国に12月31日 5時36分 NHKこれによって、サモアは、地球上で最も早く日付の変る国になった。 今日のＮＨＫ・ＢＳニュースによれば、この措置は、サモアがオーストラリアとの経済的結びつきを重視したことによるという。今日から、サモアとオーストラリアは同じく「国際日付線の西側の国」になったのである。
世界で日付が変わるのが最も遅い国、南太平洋の島国サモアが３１日、標準時を日付変更線の東側から西側に移行させ、日付が変わるのが世界で最も早い国となりました。
サモアは、主要な貿易相手国のオーストラリアやニュージーランドより１日近く時間が遅く、商取引に影響が出ていたことから時差を縮めて経済活動をより円滑に進めようと、日付変更線の西側の標準時に移行しました。サモアは、２９日の深夜に日付が変わる際、時計の針を２４時間進め、３０日を丸一日飛ばして世界で最も早く３１日の大みそかを迎えました。日付変更線の東西どちらの標準時を採用するかは、日付け変更線の周辺にある各国の判断に委ねられています。サモアのツイラエパ首相は「多くのビジネスマンから時間帯の変更は、経済活動にとって非常に有益だという意見が出ている」と述べ、その効果に自信を示しました。また多くの市民からも歓迎する声が上がっています。一方で、「世界で日付が変わるのが最も遅い国」をアピールしてきた観光業界の一部の業者は今後の観光への影響を懸念しています。
社会的な事柄を振り返れば、今年はこんなことが心に残った（順不同）。
- 東日本大震災
- 東京電力福島第一原発事故
- サッカー女子ワールドカップ優勝
- フジテレビ韓流偏向放送反対運動（花王製品不買運動含む）
- オリンパス粉飾決算疑惑
- 通販おせち騒動
- 大韓民国口蹄疫禍
- ＴＰＰ加盟問題
- ユッケ食中毒・レバ刺食中毒
- 中東諸国民主化の波
- 金正日総書記死去
1.の震災については言うまでもない。
2.の原発事故は、1.の震災に起因しているとはいえ、その後の人的対応の
東京電力経営層を政府が制御できていないという印象もさることながら、原子力災害において、人命・住民の健康を最優先していないのではないかと思わせるほどの、政府対応の遅さだった。いや、この災害は、未だ終息していないと考えるのが適切だろうから、収束したと言いたい政府の姿勢は、それ自体、まずいことだろう。
自民党主体から民主党主体に政権交代して約２年、様々な考えはあるだろうが、筆者は、政権交代したことは良かったと思っている。
昨年の宮崎口蹄疫禍における対応や、今年の震災・原発事故対応を見て、民主党が政権を担うに値しない政党だというのは確認できた今、次の衆議院議員総選挙で、民主党中心の政権を望むことは無いと思う。
政権というのは、不適格だと思ったら、下野させれば良いのである。何度でも政権交代させれば良いのである。それが民主主義の根本だ。
望ましい政党を政権につかせることが大切なのではない。不適格な政権をその座から引き摺り下ろすことが選挙の役割だと、筆者は思う。
だから、次の政権が自民党でもみんなの党でも、現与党でなければ良い。
そしてまた、次の政権がまずいものであったなら、再び下野してもらえば良い。野党の時には、みんな調子のいい事を言うものだ。発言だけで、その議員が本物の政治家であるかは判断できない。
挙げた事柄の中では唯一の明るい話題が、3.サッカー女子のワールドカップ優勝である。
これはもう、素直に、喜んでいる。ぜひとも、来年のロンドン・オリンピックでも活躍して貰いたいものだ。
願わくば、ボンバーヘッド荒川選手の雄姿も再び拝みたいものである。
筆者としては、社会的意識、いや、一般市民意識の変化ということで、大きな出来事だったと考えているのが、項目4.で挙げた、一般市民による、８月のフジテレビ偏向放送反対デモである。
これまでのデモは、労働組合や政治団体など、いわばプロが主導したものばかりだった。
しかし、今年８月のフジテレビデモ以降、本当の意味での市民の意思による行動が目に付くようになった。
これはインターネットの普及が背景にあることは間違いない。
そして、既存のマスコミ、特にテレビキー局による放送が、いかに、「一部の意思」に沿ったものであるか、つまり、特定の方向への偏向に満ちた存在であるかが、広く確信されることになった。
後の時代に、必ずや、今年が市民意識の分岐点だったといわれることだろうと思う。
そして、明日から始まる「来年」だが、民主党政権が続くだろうから、景気の回復は無いだろう。
景気が回復するためには、雇用が広がり、庶民の所得が増えなければならない。
しかし、自民党小泉政権以降、自由化の旗印の下、規制緩和が進められた結果、競争が激化して、それは賃金の引き下げに及び、更には、消費の縮小を招くという悪循環に陥ってしまっている。
この悪循環を停めるには、雇用の拡大と賃金の押上げが必要で、少なくとも、小泉政権より前の状況まで戻るように、派遣の禁止を行うことが重要なのだが、民主党野田政権は先送りしてしまった。高額所得者の累進課税強化も先送りとなった。何もかもが先送りでは、変り様が無い。
たとえ政治が稚拙だとしても、筆者はわが国の庶民の強さ、逞しさを信じている。
きっと来年も、昨年の「はやぶさ」、今年の「なでしこ」の様な、爽快な出来事があるに違いない。
それを楽しみに、新しい年を迎えることにしよう。
は、およそ２歳になる大人の三毛猫なのだが、最近しばしば、水呑場で、左掌を水皿に浸して、水を日本サッカー協会とアディダスジャパンは２６日、さいたまスーパーアリーナで日本代表の新ユニホームを発表した。「結束式」と題された発表会には、日本代表の香川真司、長谷部誠、内田篤人、吉田麻也ら１０人、なでしこジャパンの鮫島彩、安藤梢ら５人、フットサル日本代表の北原亘ら３人が参加した。新ユニホームは「結束」をコンセプトに、従来からのイメージチェンジを図った。最大の特徴は、真ん中にあしらわれた赤いライン。これは「結束の一本線」と呼ばれ、大震災から復興に立ち向かう日本が一致団結、結束することを象徴している。また、日本代表ユニホームのメーンカラーである青は、従来よりも濃いディープブルーとなった。なお、結束の一本線は日本代表が赤、なでしこジャパンはピンク、フットサル日本代表は蛍光イエローとなっている。
新ユニホームを着用して登壇した長谷部は「チームひとつとなって、団結してという意味を持ったユニホームなので、２０１４年ワールドカップ・ブラジル大会へ団結していけるように、みんなでひとつになっていきたいと思います」と話した。
新ユニホームは２０１２年からの着用予定となっている。
ま、これを発表するようなJFAでは、そんな「反省」はしないだろうに４千点
で、うちのサイトでgoogleクローラが最も熱心に拾って行く「今日は何の日？」も去る12月21日(水)に出力キャラクタセットをEUC-JPからUTF8に切り替えた。
昨日ふと見ると、明治５年以前の出来事では和暦の年月日を表示しているのだが、その「xx月」の部分が消えていた。
どうも、PerlでUTF-8を使う際の作法を守らず、ソースコードをUTF-8に変換して、HTMLのMETAタグのキャラクタセット指定をutf-8に変更、 use utf8 行とデータベースから受けた変数に対するutf8::decode行を追加しただけの手抜き対応をしたのが
Perlのutf8フラグを意識して、一通り、utf8::encode(utf8フラグOff)、utf8::decode(utf8フラグOn)、no utf8 行で体裁を整えたのだが、状況は改善しなかった。
仕方が無いので、テストプログラムを組んで試してみた処、次の様な結果になった。ソースコードはUTF-8で記述している。
ソースコード
#!/usr/bin/perl
use utf8;
my($string) = '12';
binmode STDOUT => ":utf8";
if($string eq '1u'){
print "閏1月\n";
}else{
print "$string月\n";
}
print length($string), "\n";
実行結果
2
ソースコード
#!/usr/bin/perl
use utf8;
my($string) = '12';
binmode STDOUT => ":utf8";
if($string eq '1u'){
print "閏1月\n";
}else{
print "$string"; # ←Latin-1の文字列が入る変数直後でprint文を分離
print "月\n";
}
print length($string), "\n";
実行結果
12月
2
以上の結果で推測されるのは、Latin-1（UTF-8でもあるハズ）の“12”と、UTF-8の“月”が、誤った１文字として処理されてしまっているようだ、ということである。
正直な感想として、この様なものに起因する「文字化け」は、原因に
先の記事にもあったが、正に
スクリプト内に8bitのバイト列がある(たとえば、文字列リテラルに、Latin-1がある)なら、 "use utf8" は、不幸をもたらすでしょう。バイト列は、ほとんどの場合、適切なUTF-8ではないからです。を地で行っている感じである。
こんな訳で、
UTF-8は文書の記述に便利な反面、プログラムを組む際には注意が必要だと、改めて感じた次第である。
同様の不具合を回避する方法として、もっとスマートなものは無いだろうかと考えてみたのだが、 print 文は no utf8 を宣言したスコープ内で実行するしかない様な気がする。折角UTF-8でソースを書いて、UTF-8で入出力しようとしても、プログラム中で出力部分は no utf8 では、ちょっと残念な感じが否めない。
なんとかならないものだろうか。
]]>対象は FreeBSD 7.x, 8.x, 9.0 系です。
なお、此度５件の勧告が纏って出ましたが、発表がなるべく週末に掛からないように、コミュニティのセキュリティチームはがんばるそうです。→ Merry Christmas from the FreeBSD Security Team
（続きに周知メールを転載）
]]>Content-Type:
text/plain; charset=ISO-2022-JP
=============================================================================
FreeBSD-SA-11:10.pam Security Advisory
The FreeBSD Project
Topic: pam_start() does not validate service names
Category: contrib
Module: pam
Announced: 2011-12-23
Credits: Matthias Drochner
Affects: All supported versions of FreeBSD.
Corrected: 2011-12-13 13:03:11 UTC (RELENG_7, 7.4-STABLE)
2011-12-23 15:00:37 UTC (RELENG_7_4, 7.4-RELEASE-p5)
2011-12-23 15:00:37 UTC (RELENG_7_3, 7.3-RELEASE-p9)
2011-12-13 13:02:52 UTC (RELENG_8, 8.2-STABLE)
2011-12-23 15:00:37 UTC (RELENG_8_2, 8.2-RELEASE-p5)
2011-12-23 15:00:37 UTC (RELENG_8_1, 8.1-RELEASE-p7)
2011-12-13 12:59:39 UTC (RELENG_9, 9.0-STABLE)
2011-12-13 13:02:31 UTC (RELENG_9_0, 9.0-RELEASE)
CVE Name: CVE-2011-4122
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:http://security.FreeBSD.org/>.
I. Background
The PAM (Pluggable Authentication Modules) library provides a flexible
framework for user authentication and session setup / teardown. It is
used not only in the base system, but also by a large number of
third-party applications.
Various authentication methods (UNIX, LDAP, Kerberos etc.) are
implemented in modules which are loaded and executed according to
predefined, named policies. These policies are defined in
/etc/pam.conf, /etc/pam.d/<policy name>, /usr/local/etc/pam.conf or
/usr/local/etc/pam.d/<policy name>.
The PAM API is a de facto industry standard which has been implemented
by several parties. FreeBSD uses the OpenPAM implementation.
II. Problem Description
Some third-party applications, including KDE's kcheckpass command,
allow the user to specify the name of the policy on the command line.
Since OpenPAM treats the policy name as a path relative to /etc/pam.d
or /usr/local/etc/pam.d, users who are permitted to run such an
application can craft their own policies and cause the application
to load and execute their own modules.
III. Impact
If an application that runs with root privileges allows the user to
specify the name of the PAM policy to load, users who are permitted to
run that application will be able to execute arbitrary code with root
privileges.
There are no vulnerable applications in the base system.
IV. Workaround
No workaround is available, but systems without untrusted users are
not vulnerable.
Inspect any third-party setuid / setgid binaries which use the PAM
library and ascertain whether they allow the user to specify the
policy name, then either change the binary's permissions to prevent
its use or remove it altogether.
The following command will output a non-zero number if a dynamically
linked binary uses libpam:
# ldd /usr/local/bin/suspicious_binary | grep -c libpam
The following command will output a non-zero number if a statically
linked binary uses libpam:
# grep -acF "/etc/pam.d/" /usr/local/bin/suspicious_binary
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to 7-STABLE or 8-STABLE, or to
the RELENG_8_2, RELENG_8_1, RELENG_7_4, or RELENG_7_3 security
branch dated after the correction date.
2) To update your vulnerable system via a source code patch:
The following patches have been verified to apply to FreeBSD 7.4, 7.3,
8.2 and 8.1 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch http://security.FreeBSD.org/patches/SA-11:10/pam.patch
# fetch http://security.FreeBSD.org/patches/SA-11:10/pam.patch.asc
b) Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/lib/libpam
# make obj && make depend && make && make install
NOTE: On the amd64 platform, the above procedure will not update the
lib32 (i386 compatibility) libraries. On amd64 systems where the i386
compatibility libraries are used, the operating system should instead
be recompiled as described in
<URL:http://www.FreeBSD.org/handbook/makeworld.html>
3) To update your vulnerable system via a binary patch:
Systems running 7.4-RELEASE, 7.3-RELEASE, 8.2-RELEASE, or 8.1-RELEASE on
the i386 or amd64 platforms can be updated via the freebsd-update(8)
utility:
# freebsd-update fetch
# freebsd-update install
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
CVS:
Branch Revision
Path
-------------------------------------------------------------------------
RELENG_7
src/contrib/openpam/lib/openpam_configure.c 1.1.1.7.20.2
RELENG_7_4
src/UPDATING 1.507.2.36.2.7
src/sys/conf/newvers.sh 1.72.2.18.2.10
src/contrib/openpam/lib/openpam_configure.c 1.1.1.7.20.1.8.1
RELENG_7_3
src/UPDATING 1.507.2.34.2.11
src/sys/conf/newvers.sh 1.72.2.16.2.13
src/contrib/openpam/lib/openpam_configure.c 1.1.1.7.20.1.6.1
RELENG_8
src/contrib/openpam/lib/openpam_configure.c 1.1.1.8.2.1
RELENG_8_2
src/UPDATING 1.632.2.19.2.7
src/sys/conf/newvers.sh 1.83.2.12.2.10
src/contrib/openpam/lib/openpam_configure.c 1.1.1.8.8.1
RELENG_8_1
src/UPDATING 1.632.2.14.2.10
src/sys/conf/newvers.sh 1.83.2.10.2.11
src/contrib/openpam/lib/openpam_configure.c 1.1.1.8.6.1
RELENG_9
src/contrib/openpam/lib/openpam_configure.c 1.1.1.8.10.1
RELENG_9_0
src/contrib/openpam/lib/openpam_configure.c 1.1.1.8.12.1
-------------------------------------------------------------------------
Subversion:
Branch/path Revision
-------------------------------------------------------------------------
stable/7/ r228467
releng/7.4/ r228843
releng/7.3/ r228843
stable/8/ r228466
releng/8.2/ r228843
releng/8.1/ r228843
stable/9/ r228464
releng/9.0/ r228465
-------------------------------------------------------------------------
VII. References
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4122
The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-SA-11:10.pam.asc
対象は FreeBSD 7.x, 8.x, 9.0 系です。
（続きに周知メールを転載）
]]>Content-Type:
text/plain; charset=ISO-2022-JP
=============================================================================
FreeBSD-SA-11:09.pam_ssh Security Advisory
The FreeBSD Project
Topic: pam_ssh improperly grants access when user account has
unencrypted SSH private keys
Category: contrib
Module: pam
Announced: 2011-12-23
Credits: Guy Helmer, Dag-Erling Smorgrav
Affects: All supported versions of FreeBSD.
Corrected: 2011-12-11 20:40:23 UTC (RELENG_7, 7.4-STABLE)
2011-12-23 15:00:37 UTC (RELENG_7_4, 7.4-RELEASE-p5)
2011-12-23 15:00:37 UTC (RELENG_7_3, 7.3-RELEASE-p9)
2011-12-11 20:38:36 UTC (RELENG_8, 8.2-STABLE)
2011-12-23 15:00:37 UTC (RELENG_8_2, 8.2-RELEASE-p5)
2011-12-23 15:00:37 UTC (RELENG_8_1, 8.1-RELEASE-p7)
2011-12-11 16:57:27 UTC (RELENG_9, 9.0-STABLE)
2011-12-11 17:32:37 UTC (RELENG_9_0, 9.0-RELEASE)
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:http://security.FreeBSD.org/>.
I. Background
The PAM (Pluggable Authentication Modules) library provides a flexible
framework for user authentication and session setup / teardown. It is
used not only in the base system, but also by a large number of
third-party applications.
Various authentication methods (UNIX, LDAP, Kerberos etc.) are
implemented in modules which are loaded and executed according to
predefined, named policies. These policies are defined in
/etc/pam.conf, /etc/pam.d/, /usr/local/etc/pam.conf or
/usr/local/etc/pam.d/.
The base system includes a module named pam_ssh which, if enabled,
allows users to authenticate themselves by typing in the passphrase of
one of the SSH private keys which are stored in encrypted form in the
their .ssh directory. Authentication is considered successful if at
least one of these keys could be decrypted using the provided
passphrase.
By default, the pam_ssh module rejects SSH private keys with no
passphrase. A "nullok" option exists to allow these keys.
II. Problem Description
The OpenSSL library call used to decrypt private keys ignores the
passphrase argument if the key is not encrypted. Because the pam_ssh
module only checks whether the passphrase provided by the user is
null, users with unencrypted SSH private keys may successfully
authenticate themselves by providing a dummy passphrase.
III. Impact
If the pam_ssh module is enabled, attackers may be able to gain access
to user accounts which have unencrypted SSH private keys.
IV. Workaround
No workaround is available, but systems that do not have the pam_ssh module
enabled are not vulnerable. The pam_ssh module is not enabled in any
of the default policies provided in the base system.
The system administrator can use the following procedure to inspect all
PAM policy files to determine whether the pam_ssh module is enabled.
If the following command produces any output, the system may be
vulnerable:
# egrep -r '^[^#].*\<pam_ssh\>' /etc/pam.* /usr/local/etc/pam.*
The following command will disable the pam_ssh module in all PAM
policies present in the system:
# sed -i '' -e '/^[^#].*pam_ssh/s/^/#/' /etc/pam.conf /etc/pam.d/* \
/usr/local/etc/pam.conf /usr/local/etc/pam.d/*
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to 7-STABLE or 8-STABLE, or to
the RELENG_8_2, RELENG_8_1, RELENG_7_4, or RELENG_7_3 security
branch dated after the correction date.
2) To update your vulnerable system via a source code patch:
The following patches have been verified to apply to FreeBSD 7.4, 7.3,
8.2 and 8.1 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch http://security.FreeBSD.org/patches/SA-11:09/pam_ssh.patch
# fetch http://security.FreeBSD.org/patches/SA-11:09/pam_ssh.patch.asc
b) Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/lib/libpam/modules/pam_ssh
# make obj && make depend && make && make install
NOTE: On the amd64 platform, the above procedure will not update the
lib32 (i386 compatibility) libraries. On amd64 systems where the i386
compatibility libraries are used, the operating system should instead
be recompiled as described in
<URL:http://www.FreeBSD.org/handbook/makeworld.html>
3) To update your vulnerable system via a binary patch:
Systems running 7.4-RELEASE, 7.3-RELEASE, 8.2-RELEASE, or 8.1-RELEASE on
the i386 or amd64 platforms can be updated via the freebsd-update(8)
utility:
# freebsd-update fetch
# freebsd-update install
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
CVS:
Branch Revision
Path
-------------------------------------------------------------------------
RELENG_7
src/lib/libpam/modules/pam_ssh/pam_ssh.c 1.44.2.2
RELENG_7_4
src/UPDATING 1.507.2.36.2.7
src/sys/conf/newvers.sh 1.72.2.18.2.10
src/lib/libpam/modules/pam_ssh/pam_ssh.c 1.44.2.1.8.2
RELENG_7_3
src/UPDATING 1.507.2.34.2.11
src/sys/conf/newvers.sh 1.72.2.16.2.13
src/lib/libpam/modules/pam_ssh/pam_ssh.c 1.44.2.1.6.2
RELENG_8
src/lib/libpam/modules/pam_ssh/pam_ssh.c 1.45.2.3
RELENG_8_2
src/UPDATING 1.632.2.19.2.7
src/sys/conf/newvers.sh 1.83.2.12.2.10
src/lib/libpam/modules/pam_ssh/pam_ssh.c 1.45.2.2.4.2
RELENG_8_1
src/UPDATING 1.632.2.14.2.10
src/sys/conf/newvers.sh 1.83.2.10.2.11
src/lib/libpam/modules/pam_ssh/pam_ssh.c 1.45.2.2.2.2
RELENG_9
src/lib/libpam/modules/pam_ssh/pam_ssh.c 1.47.2.2
RELENG_9_0
src/lib/libpam/modules/pam_ssh/pam_ssh.c 1.47.2.1.2.2
-------------------------------------------------------------------------
Subversion:
Branch/path Revision
-------------------------------------------------------------------------
stable/7/ r228421
releng/7.4/ r228843
releng/7.3/ r228843
stable/8/ r228420
releng/8.2/ r228843
releng/8.1/ r228843
stable/9/ r228410
releng/9.0/ r228414
-------------------------------------------------------------------------
VII. References
The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-SA-11:09.pam_ssh.asc
]]>
対象は FreeBSD 7.x, 8.x, 9.0 系です。
（続きに周知メールを転載）
]]>Content-Type:
text/plain; charset=ISO-2022-JP
=============================================================================
FreeBSD-SA-11:08.telnetd Security Advisory
The FreeBSD Project
Topic: telnetd code execution vulnerability
Category: core
Module: contrib
Announced: 2011-12-23
Affects: All supported versions of FreeBSD.
Corrected: 2011-12-23 15:00:37 UTC (RELENG_7, 7.4-STABLE)
2011-12-23 15:00:37 UTC (RELENG_7_4, 7.4-RELEASE-p5)
2011-12-23 15:00:37 UTC (RELENG_7_3, 7.3-RELEASE-p9)
2011-12-23 15:00:37 UTC (RELENG_8, 8.2-STABLE)
2011-12-23 15:00:37 UTC (RELENG_8_2, 8.2-RELEASE-p5)
2011-12-23 15:00:37 UTC (RELENG_8_1, 8.1-RELEASE-p7)
2011-12-23 15:00:37 UTC (RELENG_9, 9.0-STABLE)
2011-12-23 15:00:37 UTC (RELENG_9_0, 9.0-RELEASE)
CVE Name: CVE-2011-4862
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:http://security.FreeBSD.org/>.
I. Background
The FreeBSD telnet daemon, telnetd(8), implements the server side of the
TELNET virtual terminal protocol. It has been disabled by default in
FreeBSD since August 2001, and due to the lack of cryptographic security
in the TELNET protocol, it is strongly recommended that the SSH protocol
be used instead. The FreeBSD telnet daemon can be enabled via the
/etc/inetd.conf configuration file and the inetd(8) daemon.
The TELNET protocol has a mechanism for encryption of the data stream
(but it is not cryptographically strong and should not be relied upon
in any security-critical applications).
II. Problem Description
When an encryption key is supplied via the TELNET protocol, its length
is not validated before the key is copied into a fixed-size buffer.
III. Impact
An attacker who can connect to the telnetd daemon can execute arbitrary
code with the privileges of the daemon (which is usually the "root"
superuser).
IV. Workaround
No workaround is available, but systems not running the telnet daemon
are not vulnerable.
Note that the telnet daemon is usually run via inetd, and consequently
will not show up in a process listing unless a connection is currently
active; to determine if it is enabled, run
$ ps ax | grep telnetd | grep -v grep
$ grep telnetd /etc/inetd.conf | grep -vE '^#'
If any output is produced, your system may be vulnerable.
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to 7-STABLE or 8-STABLE, or to the
RELENG_8_2, RELENG_8_1, RELENG_7_4, or RELENG_7_3 security branch dated
after the correction date.
2) To update your vulnerable system via a source code patch:
The following patches have been verified to apply to FreeBSD 7.4, 7.3,
8.2, and 8.1 systems.
a) Download the patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch http://security.FreeBSD.org/patches/SA-11:08/telnetd.patch
# fetch http://security.FreeBSD.org/patches/SA-11:08/telnetd.patch.asc
b) Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/lib/libtelnet
# make obj && make depend && make && make install
# cd /usr/src/libexec/telnetd
# make obj && make depend && make && make install
3) To update your vulnerable system via a binary patch:
Systems running 7.4-RELEASE, 7.3-RELEASE, 8.2-RELEASE, or 8.1-RELEASE on
the i386 or amd64 platforms can be updated via the freebsd-update(8)
utility:
# freebsd-update fetch
# freebsd-update install
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
CVS:
Branch Revision
Path
-------------------------------------------------------------------------
RELENG_7
src/crypto/heimdal/appl/telnet/libtelnet/encrypt.c 1.1.1.2.24.1
src/contrib/telnet/libtelnet/encrypt.c 1.9.24.1
RELENG_7_4
src/UPDATING 1.507.2.36.2.7
src/sys/conf/newvers.sh 1.72.2.18.2.10
src/crypto/heimdal/appl/telnet/libtelnet/encrypt.c 1.1.1.2.38.1
src/contrib/telnet/libtelnet/encrypt.c 1.9.40.2
RELENG_7_3
src/UPDATING 1.507.2.34.2.11
src/sys/conf/newvers.sh 1.72.2.16.2.13
src/crypto/heimdal/appl/telnet/libtelnet/encrypt.c 1.1.1.2.36.1
src/contrib/telnet/libtelnet/encrypt.c 1.9.38.2
RELENG_8
src/crypto/heimdal/appl/telnet/libtelnet/encrypt.c 1.1.1.3.2.1
src/contrib/telnet/libtelnet/encrypt.c 1.9.36.2
RELENG_8_2
src/UPDATING 1.632.2.19.2.7
src/sys/conf/newvers.sh 1.83.2.12.2.10
src/crypto/heimdal/appl/telnet/libtelnet/encrypt.c 1.1.1.3.8.1
src/contrib/telnet/libtelnet/encrypt.c 1.9.36.1.6.2
RELENG_8_1
src/UPDATING 1.632.2.14.2.10
src/sys/conf/newvers.sh 1.83.2.10.2.11
src/crypto/heimdal/appl/telnet/libtelnet/encrypt.c 1.1.1.3.6.1
src/contrib/telnet/libtelnet/encrypt.c 1.9.36.1.4.2
RELENG_9
src/crypto/heimdal/appl/telnet/libtelnet/encrypt.c 1.1.1.3.10.1
src/contrib/telnet/libtelnet/encrypt.c 1.9.42.2
RELENG_9_0
src/crypto/heimdal/appl/telnet/libtelnet/encrypt.c 1.1.1.3.12.1
src/contrib/telnet/libtelnet/encrypt.c 1.9.42.1.2.2
-------------------------------------------------------------------------
Subversion:
Branch/path Revision
-------------------------------------------------------------------------
stable/7/ r228843
releng/7.4/ r228843
releng/7.3/ r228843
stable/8/ r228843
releng/8.2/ r228843
releng/8.1/ r228843
stable/9/ r228843
releng/9.0/ r228843
-------------------------------------------------------------------------
VII. References
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4862
The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-SA-11:08.telnetd.asc
]]>
対象は FreeBSD 7.x, 8.x, 9.0 系です。
（続きに周知メールを転載）
]]>Content-Type:
text/plain; charset=ISO-2022-JP
=============================================================================
FreeBSD-SA-11:07.chroot Security Advisory
The FreeBSD Project
Topic: Code execution via chrooted ftpd
Category: core
Module: libc
Announced: 2011-12-23
Affects: All supported versions of FreeBSD.
Corrected: 2011-12-23 15:00:37 UTC (RELENG_7, 7.4-STABLE)
2011-12-23 15:00:37 UTC (RELENG_7_4, 7.4-RELEASE-p5)
2011-12-23 15:00:37 UTC (RELENG_7_3, 7.3-RELEASE-p9)
2011-12-23 15:00:37 UTC (RELENG_8, 8.2-STABLE)
2011-12-23 15:00:37 UTC (RELENG_8_2, 8.2-RELEASE-p5)
2011-12-23 15:00:37 UTC (RELENG_8_1, 8.1-RELEASE-p7)
2011-12-23 15:00:37 UTC (RELENG_9, 9.0-STABLE)
2011-12-23 15:00:37 UTC (RELENG_9_0, 9.0-RELEASE)
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:http://security.FreeBSD.org/>.
I. Background
Chroot is an operation that changes the apparent root directory for the
current process and its children. The chroot(2) system call is widely
used in many applications as a measure of limiting a process's access to
the file system, as part of implementing privilege separation.
The nsdispatch(3) API implementation has a feature to reload its
configuration on demand. This feature may also load shared libraries
and run code provided by the library when requested by the configuration
file.
II. Problem Description
The nsdispatch(3) API has no mechanism to alert it to whether it is
operating within a chroot environment in which the standard paths for
configuration files and shared libraries may be untrustworthy.
The FreeBSD ftpd(8) daemon can be configured to use chroot(2), and
also uses the nsdispatch(3) API.
III. Impact
If ftpd is configured to place a user in a chroot environment, then an
attacker who can log in as that user may be able to run arbitrary code
with elevated ("root") privileges.
IV. Workaround
Don't use ftpd with the chroot option.
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to 7-STABLE or 8-STABLE, or to
the RELENG_8_2, RELENG_8_1, RELENG_7_4, or RELENG_7_3 security
branch dated after the correction date.
2) To update your vulnerable system via a source code patch:
The following patches have been verified to apply to FreeBSD 7.4, 7.3,
8.2 and 8.1 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
[FreeBSD 7.3 and 7.4]
# fetch http://security.FreeBSD.org/patches/SA-11:07/chroot7.patch
# fetch http://security.FreeBSD.org/patches/SA-11:07/chroot7.patch.asc
[FreeBSD 8.1 and 8.2]
# fetch http://security.FreeBSD.org/patches/SA-11:07/chroot8.patch
# fetch http://security.FreeBSD.org/patches/SA-11:07/chroot8.patch.asc
b) Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
c) Recompile the operating system as described in
<URL: http://www.freebsd.org/handbook/makeworld.html> and reboot the
system.
3) To update your vulnerable system via a binary patch:
Systems running 7.4-RELEASE, 7.3-RELEASE, 8.2-RELEASE, or 8.1-RELEASE on
the i386 or amd64 platforms can be updated via the freebsd-update(8)
utility:
# freebsd-update fetch
# freebsd-update install
4) This update adds a new API, __FreeBSD_libc_enter_restricted_mode()
to the C library, which completely disables loading of shared libraries
upon return. Applications doing chroot(2) jails need to be updated
to call this API explicitly right after the chroot(2) operation as a
safety measure.
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
CVS:
Branch Revision
Path
-------------------------------------------------------------------------
RELENG_7
src/include/unistd.h 1.80.2.4
src/lib/libc/include/libc_private.h 1.17.2.4
src/lib/libc/Versions.def 1.3.2.3
src/lib/libc/net/nsdispatch.c 1.14.2.3
src/lib/libc/gen/Symbol.map 1.6.2.7
src/lib/libc/gen/Makefile.inc 1.128.2.6
src/lib/libc/gen/libc_dlopen.c 1.2.2.2
src/libexec/ftpd/popen.c 1.26.10.2
src/libexec/ftpd/ftpd.c 1.212.2.2
RELENG_7_4
src/UPDATING 1.507.2.36.2.7
src/sys/conf/newvers.sh 1.72.2.18.2.10
src/include/unistd.h 1.80.2.3.4.2
src/lib/libc/include/libc_private.h 1.17.2.3.4.2
src/lib/libc/Versions.def 1.3.2.2.4.2
src/lib/libc/net/nsdispatch.c 1.14.2.2.2.2
src/lib/libc/gen/Symbol.map 1.6.2.6.4.2
src/lib/libc/gen/Makefile.inc 1.128.2.5.4.2
src/lib/libc/gen/libc_dlopen.c 1.2.4.2
src/libexec/ftpd/popen.c 1.26.10.1.2.2
src/libexec/ftpd/ftpd.c 1.212.2.1.6.2
RELENG_7_3
src/UPDATING 1.507.2.34.2.11
src/sys/conf/newvers.sh 1.72.2.16.2.13
src/include/unistd.h 1.80.2.3.2.2
src/lib/libc/include/libc_private.h 1.17.2.3.2.2
src/lib/libc/Versions.def 1.3.2.2.2.2
src/lib/libc/net/nsdispatch.c 1.14.2.1.6.2
src/lib/libc/gen/Symbol.map 1.6.2.6.2.2
src/lib/libc/gen/Makefile.inc 1.128.2.5.2.2
src/lib/libc/gen/libc_dlopen.c 1.1.2.1
src/libexec/ftpd/popen.c 1.26.24.2
src/libexec/ftpd/ftpd.c 1.212.2.1.4.2
RELENG_8
src/include/unistd.h 1.95.2.2
src/lib/libc/include/libc_private.h 1.20.2.3
src/lib/libc/Versions.def 1.8.2.3
src/lib/libc/net/nsdispatch.c 1.18.2.3
src/lib/libc/gen/Symbol.map 1.21.2.6
src/lib/libc/gen/Makefile.inc 1.144.2.7
src/lib/libc/gen/libc_dlopen.c 1.1.4.2
src/libexec/ftpd/popen.c 1.26.22.3
src/libexec/ftpd/ftpd.c 1.214.2.3
RELENG_8_2
src/UPDATING 1.632.2.19.2.7
src/sys/conf/newvers.sh 1.83.2.12.2.10
src/include/unistd.h 1.95.2.1.6.2
src/lib/libc/include/libc_private.h 1.20.2.2.4.2
src/lib/libc/Versions.def 1.8.2.2.4.2
src/lib/libc/net/nsdispatch.c 1.18.2.2.2.2
src/lib/libc/gen/Symbol.map 1.21.2.5.2.2
src/lib/libc/gen/Makefile.inc 1.144.2.6.2.2
src/lib/libc/gen/libc_dlopen.c 1.2.8.2
src/libexec/ftpd/popen.c 1.26.22.2.4.2
src/libexec/ftpd/ftpd.c 1.214.2.1.6.2
RELENG_8_1
src/UPDATING 1.632.2.14.2.10
src/sys/conf/newvers.sh 1.83.2.10.2.11
src/include/unistd.h 1.95.2.1.4.2
src/lib/libc/include/libc_private.h 1.20.2.2.2.2
src/lib/libc/Versions.def 1.8.2.2.2.2
src/lib/libc/net/nsdispatch.c 1.18.2.1.4.2
src/lib/libc/gen/Symbol.map 1.21.2.3.2.2
src/lib/libc/gen/Makefile.inc 1.144.2.4.2.2
src/lib/libc/gen/libc_dlopen.c 1.2.10.2
src/libexec/ftpd/popen.c 1.26.22.2.2.2
src/libexec/ftpd/ftpd.c 1.214.2.1.4.2
RELENG_9
src/include/unistd.h 1.101.2.2
src/lib/libc/include/libc_private.h 1.26.2.2
src/lib/libc/Versions.def 1.9.2.2
src/lib/libc/net/nsdispatch.c 1.19.2.2
src/lib/libc/gen/Symbol.map 1.38.2.2
src/lib/libc/gen/Makefile.inc 1.159.2.2
src/lib/libc/gen/libc_dlopen.c 1.1.6.2
src/lib/libc/iconv/citrus_module.c 1.1.2.2
src/libexec/ftpd/popen.c 1.27.2.2
src/libexec/ftpd/ftpd.c 1.220.2.2
RELENG_9_0
src/include/unistd.h 1.101.2.1.2.2
src/lib/libc/include/libc_private.h 1.26.2.1.2.2
src/lib/libc/Versions.def 1.9.2.1.2.2
src/lib/libc/net/nsdispatch.c 1.19.2.1.2.2
src/lib/libc/gen/Symbol.map 1.38.2.1.2.2
src/lib/libc/gen/Makefile.inc 1.159.2.1.2.2
src/lib/libc/gen/libc_dlopen.c 1.2.6.2
src/lib/libc/iconv/citrus_module.c 1.1.2.1.2.2
src/libexec/ftpd/popen.c 1.27.2.1.2.2
src/libexec/ftpd/ftpd.c 1.220.2.1.2.2
-------------------------------------------------------------------------
Subversion:
Branch/path Revision
-------------------------------------------------------------------------
stable/7/ r228843
releng/7.4/ r228843
releng/7.3/ r228843
stable/8/ r228843
releng/8.2/ r228843
releng/8.1/ r228843
stable/9/ r228843
releng/9.0/ r228843
-------------------------------------------------------------------------
VII. References
The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-SA-11:07.chroot.asc
]]>
対象は FreeBSD 7.x, 8.x, 9.0 系です。
（続きに周知メールを転載）
]]>Content-Type:
text/plain; charset=ISO-2022-JP
=============================================================================
FreeBSD-SA-11:06.bind Security Advisory
The FreeBSD Project
Topic: Remote packet Denial of Service against named(8) servers
Category: contrib
Module: bind
Announced: 2011-12-23
Affects: All supported versions of FreeBSD.
Corrected: 2011-11-17 01:10:16 UTC (RELENG_7, 7.4-STABLE)
2011-12-23 15:00:37 UTC (RELENG_7_4, 7.4-RELEASE-p5)
2011-12-23 15:00:37 UTC (RELENG_7_3, 7.3-RELEASE-p9)
2011-11-17 00:36:10 UTC (RELENG_8, 8.2-STABLE)
2011-12-23 15:00:37 UTC (RELENG_8_2, 8.2-RELEASE-p5)
2011-12-23 15:00:37 UTC (RELENG_8_1, 8.1-RELEASE-p7)
2011-12-01 21:13:41 UTC (RELENG_9, 9.0-STABLE)
2011-12-01 21:17:59 UTC (RELENG_9_0, 9.0-RC3)
2011-11-16 23:41:13 UTC (ports tree)
CVE Name: CVE-2011-4313
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:http://security.FreeBSD.org/>.
I. Background
BIND 9 is an implementation of the Domain Name System (DNS) protocols.
The named(8) daemon is an Internet Domain Name Server.
II. Problem Description
A remote attacker could cause the BIND resolver to cache an invalid
record, which could cause the BIND daemon to crash when that record
is being queried.
III. Impact
An attacker that is able to send an specifically crafted response to the
BIND daemon can cause it to crash, resulting in a denial of service.
Note that due to the nature of this vulnerability, the attacker does
not necessarily have to have query access to the victim server. The
vulnerability can be triggered by tricking legitimate clients, for
instance spam filtering systems or an end user browser, which can be
made to the query on their behalf.
IV. Workaround
No workaround is available, but systems not running the BIND resolving
name server are not affected.
Servers that are running in authoritative-only mode appear not to be
affected by this vulnerability.
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to 7-STABLE or 8-STABLE, or to the
RELENG_8_2, RELENG_8_1, RELENG_7_4, or RELENG_7_3 security branch dated
after the correction date.
2) To update your vulnerable system via a source code patch:
The following patches have been verified to apply to FreeBSD 7.4, 7.3,
8.2 and 8.1 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
[FreeBSD 7.3-RELEASE and 7.4-RELEASE]
# fetch http://security.FreeBSD.org/patches/SA-11:06/bind7.patch
# fetch http://security.FreeBSD.org/patches/SA-11:06/bind7.patch.asc
[FreeBSD 8.1-RELEASE and 8.2-RELEASE]
# fetch http://security.FreeBSD.org/patches/SA-11:06/bind8.patch
# fetch http://security.FreeBSD.org/patches/SA-11:06/bind8.patch.asc
b) Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/lib/bind/
# make obj && make depend && make && make install
# cd /usr/src/usr.sbin/named
# make obj && make depend && make && make install
3) To update your vulnerable system via a binary patch:
Systems running 7.4-RELEASE, 7.3-RELEASE, 8.2-RELEASE, or 8.1-RELEASE on
the i386 or amd64 platforms can be updated via the freebsd-update(8)
utility:
# freebsd-update fetch
# freebsd-update install
4) Install and run BIND from the Ports Collection after the correction
date. The following versions and newer versions of BIND installed from
the Ports Collection already have the mitigation measure:
bind96-9.6.3.1.ESV.R5.1
bind97-9.7.4.1
bind98-9.8.1.1
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
CVS:
Branch Revision
Path
-------------------------------------------------------------------------
RELENG_7
src/contrib/bind9/lib/dns/rbtdb.c 1.1.1.4.2.9
src/contrib/bind9/bin/named/query.c 1.1.1.6.2.8
RELENG_7_4
src/UPDATING 1.507.2.36.2.7
src/sys/conf/newvers.sh 1.72.2.18.2.10
src/contrib/bind9/lib/dns/rbtdb.c 1.1.1.4.2.6.2.1
src/contrib/bind9/bin/named/query.c 1.1.1.6.2.6.2.1
RELENG_7_3
src/UPDATING 1.507.2.34.2.11
src/sys/conf/newvers.sh 1.72.2.16.2.13
src/contrib/bind9/lib/dns/rbtdb.c 1.1.1.4.2.3.2.2
src/contrib/bind9/bin/named/query.c 1.1.1.6.2.3.2.2
RELENG_8
src/contrib/bind9/lib/dns/rbtdb.c 1.3.2.9
src/contrib/bind9/bin/named/query.c 1.3.2.8
RELENG_8_2
src/UPDATING 1.632.2.19.2.7
src/sys/conf/newvers.sh 1.83.2.12.2.10
src/contrib/bind9/lib/dns/rbtdb.c 1.3.2.5.2.1
src/contrib/bind9/bin/named/query.c 1.3.2.5.2.1
RELENG_8_1
src/UPDATING 1.632.2.14.2.10
src/sys/conf/newvers.sh 1.83.2.10.2.11
src/contrib/bind9/lib/dns/rbtdb.c 1.3.2.3.2.1
src/contrib/bind9/bin/named/query.c 1.3.2.3.2.1
RELENG_9
src/contrib/bind9/lib/dns/rbtdb.c 1.13.2.1
src/contrib/bind9/bin/named/query.c 1.11.2.1
RELENG_9_0
src/contrib/bind9/lib/dns/rbtdb.c 1.13.4.1
src/contrib/bind9/bin/named/query.c 1.11.4.1
-------------------------------------------------------------------------
Subversion:
Branch/path Revision
-------------------------------------------------------------------------
stable/7/ r227603
releng/7.4/ r228843
releng/7.3/ r228843
stable/8/ r227599
releng/8.2/ r228843
releng/8.1/ r228843
stable/9/ r228189
releng/9.0/ r228190
-------------------------------------------------------------------------
VII. References
https://www.isc.org/software/bind/advisories/cve-2011-4313
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4313
The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-SA-11:06.bind.asc
]]>
筆者の現在の外部向けサーバ環境は次の通り。
以下、変更手順を記す。
４バイトユニコードを Movable Type で使う為の手順は、大きく分けて二つである。
データベースのバックアップを行ったら、設定を変更して行こう。
ブログ用データベース（ここでは仮に mt であるとする）にログインし、記事のテーブル設定を確認する。
# mysql -p mt
mysql> SHOW CREATE TABLE mt_entry\G
*************************** 1. row ***************************
Table: mt_entry
Create Table: CREATE TABLE `mt_entry` (
`entry_id` int(11) NOT NULL AUTO_INCREMENT,
`entry_allow_comments` tinyint(4) DEFAULT NULL,
（中略）
KEY `mt_entry_dd_entry_tag_count` (`entry_blog_id`,`entry_status`,`entry_class`,`entry_id`),
KEY `mt_entry_auth_stat_class` (`entry_author_id`,`entry_status`,`entry_class`)
) ENGINE=MyISAM AUTO_INCREMENT=753 DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
mysql> SHOW TABLE STATUS FROM mt WHERE Name = 'mt_entry'\G
*************************** 1. row ***************************
Name: mt_entry
Engine: MyISAM
Version: 10
Row_format: Dynamic
Rows: 747
Avg_row_length: 3708
Data_length: 2770156
Max_data_length: 281474976710655
Index_length: 260096
Data_free: 0
Auto_increment: 753
Create_time: 2011-12-10 19:34:55
Update_time: 2011-12-11 16:49:28
Check_time: 2011-12-11 02:12:01
Collation: utf8_general_ci
Checksum: NULL
Create_options:
Comment:
1 row in set (0.01 sec)
mysql>
上の例では、キャラクタセット utf8、照合順序（Collation）が utf8_general_ci である。
それでは、テーブルの既定（デフォルト）キャラクタセットと照合順序を変更しよう。
mysql> ALTER TABLE mt_entry DEFAULT CHARACTER SET utf8mb4, COLLATE utf8mb4_general_ci;
Query OK, 746 rows affected (0.99 sec)
Records: 746 Duplicates: 0 Warnings: 0
続いて、テーブルmt_entry各項目のキャラクタセットと長さを変更する。
mysql> ALTER TABLE mt_entry
-> modify `entry_atom_id` varchar(191) CHARACTER SET utf8mb4 DEFAULT NULL
-> ,modify `entry_basename` varchar(191) CHARACTER SET utf8mb4 DEFAULT NULL
-> ,modify `entry_class` varchar(191) CHARACTER SET utf8mb4 DEFAULT 'entry'
-> ,modify `entry_convert_breaks` varchar(30) CHARACTER SET utf8mb4 DEFAULT NULL
-> ,modify `entry_excerpt` mediumtext CHARACTER SET utf8mb4
-> ,modify `entry_keywords` mediumtext CHARACTER SET utf8mb4
-> ,modify `entry_pinged_urls` mediumtext CHARACTER SET utf8mb4
-> ,modify `entry_tangent_cache` mediumtext CHARACTER SET utf8mb4
-> ,modify `entry_text` mediumtext CHARACTER SET utf8mb4
-> ,modify `entry_text_more` mediumtext CHARACTER SET utf8mb4
-> ,modify `entry_title` varchar(191) CHARACTER SET utf8mb4 DEFAULT NULL
-> ,modify `entry_to_ping_urls` mediumtext CHARACTER SET utf8mb4
-> ;
Query OK, 746 rows affected (0.38 sec)
Records: 746 Duplicates: 0 Warnings: 0
以上でデータベースの変換は終了である（少々強引だが、utf8からutf8mb4の変更なので、文字項目のコード変換は省略している）。
参考
以下の手順は、Movable Type 添付のファイルを強制的に変更するものなので、当然ながら、ベンダーのサポートは期待できない。ファイルに手を入れる前に、オリジナルをバックアップしておくのはもちろんのこと、何をしているのか理解できない人は、やらない方が良いと考える。念の為。
[mt導入ディレクトリ]/lib/MT/ObjectDriver/Driver/DBD/mysql.pm内のデータベース読み出しキャラクタセットの定義を変更する。
※これにより、サイトの出力キャラクタセットにUTF-8を指定すると、データベースからは常に utf8mb4 で読み出される。
【修正個所差分】
--- ./mysql.pm.orign 2011-06-03 15:14:21.000000000 +0900 +++ ./mysql.pm 2011-12-11 16:42:41.000000000 +0900 @@ -64,7 +64,9 @@ # MySQL 4.1+ and non-latin1(database) == needs SET NAMES call. my $c = lc $cfg->PublishCharset; my %Charset = ( - 'utf-8' => 'utf8', +### for MySQL-5.5.x utf8mb4 (2011 Dec. 11) + 'utf-8' => 'utf8mb4', +# 'utf-8' => 'utf8', 'shift_jis' => 'sjis', 'shift-jis' => 'sjis', 'euc-jp' => 'ujis',
以上の変更が終ったら、Webサーバ（Apache等）をリスタートして完了である。
]]>筆者が興味を持ったのは、その中の、ユニコードサポートの変更である。
MySQL-5.5では、「ucs2」「utf8」「utf16」「utf32」に加えて、新しく「utf8mb4」というキャラクタセットが定義されている。
これは何かというと、４バイトユニコードの文字を使えるということである。
これまでのMySQLでは、３バイトの範囲のユニコードで定義された文字しか、ユニコードの文字としては扱えなかった。
３バイト以下のユニコード文字は、いわゆる基本面に定義されている文字で、具体的には、基本から拡張Ａまでの文字群である。つまり、これまでは、ユニコードで定義した文字項目でも、拡張Ｂ、拡張Ｃの文字を登録しようとすると、文字化けを起こしていたのである。
どうしても拡張Ｂ以降の定義文字を使用したい場合は、項目のキャラクタセットをbinaryにして入出力するなどの工夫が必要だった。
筆者の場合、古文献などの文字をそのままデータベースに使いたい場合が侭あるので、４バイトユニコードが使えるようになるのは有難い。
しかし、utf8mb4は使用可能な文字範囲が増える代わりに、同一文字数で使用する領域が増えるので、例えば、MyISAMのデータベースにおける１行（１レコード）の最大領域は65535バイト（E.10.4. Table Column-Count and Row-Size Limits）なので、１文字当り従来型キャラクタセットで３バイトだったものが、４バイトに変われば、当然のことながら、１レコードで扱える最大文字数は少なくなる。
その他にもレプリケーション関連など、かなり大胆に機能強化を図ったようだが、反面、使用する資源も相当増えていると思われるし、機能によっては動作速度の低下も覚悟しておかないといけない。そういったメリット・デメリットを比較して、MySQL-5.5に移行するかどうかを考えればいいと思う。いずれは新しいバージョンに移行せざるを得ない時が来るのだが、慌てる必要は無いのである。
注意すべき点を一つ挙げれば、MySQL-5.5では、既定データベースエンジンがInnoDBになった。 筆者の様な日曜プログラマ的な使用では、トランザクションを必要とする程のシステムはいらないので、ちょっと余計なお世話に感じる。筆者としては、MySQLでトランザクション機能を使うというのは「無理な方向の使い方」に思えて仕方ないのだが、今回の機能変更などを見ると、Oracleは必ずしもそうは考えていないような印象で、むしろ、このまま肥大化の道をたどりそうな気配も感じる。
さて、実際に導入する手順を記しておく。
筆者が現在使用しているサーバは、FreeBSD-7-STABLEとCentOS-5.7の２種類のＯＳを使用しているので、それぞれについて記述する。
# mysqldump -p --all-databases > ./all-data_20111203.sql
# cp -p /etc/my.cnf /etc/my.cnf_20111203_old
※1 FreeBSDのportsを介して導入する場合は不要。
※2 CentOSの場合は、次のrpmパッケージを取得する（i86マシン＋64bit OSの場合）。※※ remiリポジトリを使ってyumで導入する方法もある。（参照: Install MySQL 5.5.18 on Fedora 16/15, CentOS/Red Hat (RHEL) 6/5.7）
- MySQL-server-5.5.18-1.linux2.6.x86_64.rpm
- MySQL-client-5.5.18-1.linux2.6.x86_64.rpm
- MySQL-devel-5.5.18-1.linux2.6.x86_64.rpm
- MySQL-shared-compat-5.5.18-1.linux2.6.x86_64.rpm
次のオプション指定行はコメントアウトする（下線行を追加した）。[mysqld]
character-set-server=utf8mb4
#default-character-set=utf8
collation-server=utf8mb4_general_ci
#collation-server=utf8_general_ci
#log-long-format
# /etc/rc.d/init.d/mysqld stop
# yum remove mysql-server.x86_64 mysql-devel.x86_64
# rpm -ivh MySQL-server-5.5.18-1.linux2.6.x86_64.rpm MySQL-client-5.5.18-1.linux2.6.x86_64.rpm MySQL-devel-5.5.18-1.linux2.6.x86_64.rpm MySQL-shared-compat-5.5.18-1.linux2.6.x86_64.rpm
# yum localinstall perl-DBD-MySQL-4.014-1.el5.rfx.x86_64.rpm
# /etc/rc.d/init.d/mysql start
Oracleのrpmパッケージでは、導入時に自動起動設定が削除されるので、あらためて自動設定を行う必要がある。# /sbin/chkconfig --add mysql
# /sbin/chkconfig mysql on
# /sbin/chkconfig --list mysql
mysql 0:off 1:off 2:on 3:on 4:on 5:on 6:off
MAKE_ARGS = {
'databases/mysql41-client' => 'WITH_CHARSET=ujis WITH_XCHARSET=all',
'databases/mysql41-server' => 'WITH_CHARSET=ujis WITH_XCHARSET=all',
'databases/mysql50-client' => 'WITH_CHARSET=ujis WITH_XCHARSET=all',
'databases/mysql50-server' => 'WITH_CHARSET=ujis WITH_XCHARSET=all',
'databases/mysql51-client' => 'WITH_CHARSET=ujis WITH_XCHARSET=all',
'databases/mysql51-server' => 'WITH_CHARSET=ujis WITH_XCHARSET=all',
'databases/mysql55-client' => 'WITH_CHARSET=ujis WITH_XCHARSET=all',
'databases/mysql55-server' => 'WITH_CHARSET=ujis WITH_XCHARSET=all',
'editors/openoffice.org-2' => 'LOCALIZED_LANG=alllangs',
'*' => 'WITHOUT_IPV6=yes',
}
# /usr/local/etc/rc.d/mysql-server stop
# pkg_deinstall -fv mysql-client-5.1.60 mysql-server-5.1.60 p5-DBD-mysql51-4.019
# portinstall -vp databases/mysql55-server databases/p5-DBD-mysql55
# /usr/local/etc/rc.d/mysql-server start
# mysql_upgrade -p
Enter password:Looking for 'mysql' as: mysql Looking for 'mysqlcheck' as: mysqlcheck Running 'mysqlcheck with default connection arguments Running 'mysqlcheck with default connection arguments books.booklist error : Table upgrade required. Please do "REPAIR TABLE `booklist`" or dump/reload to fix it! epco_advisory.Company error : Table upgrade required. Please do "REPAIR TABLE `Company`" or dump/reload to fix it! events.Event OK mysql.columns_priv OK mysql.db OK mysql.event OK mysql.func OK mysql.general_log OK mysql.help_category error : Table upgrade required. Please do "REPAIR TABLE `help_category`" or dump/reload to fix it! mysql.help_keyword error : Table upgrade required. Please do "REPAIR TABLE `help_keyword`" or dump/reload to fix it! mysql.help_relation OK mysql.help_topic error : Table upgrade required. Please do "REPAIR TABLE `help_topic`" or dump/reload to fix it! mysql.host OK mysql.ndb_binlog_index OK mysql.plugin OK mysql.proc error : Table upgrade required. Please do "REPAIR TABLE `proc`" or dump/reload to fix it! mysql.procs_priv OK mysql.servers OK mysql.slow_log OK mysql.tables_priv OK mysql.time_zone OK mysql.time_zone_leap_second OK mysql.time_zone_name error : Table upgrade required. Please do "REPAIR TABLE `time_zone_name`" or dump/reload to fix it! mysql.time_zone_transition OK mysql.time_zone_transition_type OK mysql.user OK test.userpref OK test_inno.data OK Repairing tables books.booklist OK mysql.help_category OK mysql.help_keyword OK mysql.help_topic OK mysql.proc OK mysql.time_zone_name OK Running 'mysql_fix_privilege_tables'... OK #
apache等、MySQLを参照するアプリケーション動作させている場合は、それぞれをリスタートさせる。
テーブルロックを行っている場合で、プログラム中でviewを参照している時、LOCK TABLESにviewの定義も加えないと、実行時エラーになるようである。
また、筆者の環境の一つ（Oracle版rpmパッケージ）では、クライアント側のキャラクタ設定コマンドSET NAMES eucjpmsを、SET NAMES ujisに変更しなければならなかった。
これはビルドオプションの関係で、eucjpmsが組み込まれずに構築された為と考えられる。キャラクタセットの定義上、eucjpmsは変らず存在する（参照: 9.1.14. Character Sets and Collations That MySQL Supports）。
MySQLにログインした後、次の様にすると、その環境で使用可能なキャラクタセットが確認できる。
mysql> SHOW CHARACTER SET;
（12月５日追記）と、書いておきながら、調べてみると、Oracle版パッケージでも、ちゃんとeucjpmsは組み込まれていた。
してみると、Perl-DBD-mysqlドライバ辺りが原因かもしれない。
（12月11日追記）perl-DBD-MySQL-4.014-1.el5.rfx.x86_64.rpmを導入した所、eucjpmsの障害は解消した。やはり、ドライバが古いせいだった様である。
ソースからビルドしたい方はこちらのサイトを参考にされたい。
データベースをアップグレードした直後にCGIがエラーになった場合は、上記の点を確認して欲しい。
]]>揺れが長く続いたので、那覇市からは比較的遠い震源なのだろうと考えたが、沖縄本島北西沖（北緯27.2度東経125.8度）深さ220km、推定M6.8だったようである。
幸い、津波注意報は出なかった。
震度４でこれだから、東日本大震災や阪神淡路の際の震度７なんてのは、さぞかし強烈なのだろう。願わくは遭遇したくないものだが、、叶うかどうかは運次第である。
科学番組としてみれば、工学実験機「はやぶさ」に到るまでのわが国のロケット開発の歴史から、今回の意義、プロジェクトの始まりと、その運営の苦労など、網羅的に詰め込まれていて、なかなかいい出来だった様に思う。140分が長くは感じなかった。
筆者は、前にも書いたと思うが、「はやぶさ」が通信途絶した時点で、ああ、今回は失敗か、と思って関心を失った程度の興味しか持っていなかった。
しかし、その後、奇跡的に通信を回復、つまり、この広大な宇宙空間の中から点の様な「はやぶさ」を探し出したと聞いたときから、俄然、このプロジェクトに興味が湧いた口である。
そして、昨年６月13日22時51分、「おかえり、はやぶさ」とつぶやいたであろう多くの人の一人であった。
今回の映画でちょっと残念だったのは、最も感動的な場面である筈の帰還の時に、盛り上がりに欠けていたように感じたことである（いや、画面では複数の関係者が涙でその瞬間を迎えていたのだが）。
何でだろうと、つらつら考えてみたのだが、一つだけ思い当たる点があった。
「はやぶさ」は、もともとは、地球上空に帰還して再突入カプセルを分離した後待機し、その後、別の探査に向かわせる計画だったのだ。
古くから「はやぶさ」動向を追っている人にとって、それは周知の事実である。
しかし、トラブルに次ぐトラブルで、地球付近で軌道変更を実現するための大推力を得られる化学スラスタが使用不能になったことで、再突入カプセルを地球に届けるためには、「はやぶさ」本体をも大気圏に突入させざるを得なくなったのだ。
その辺りの経緯は、川口プロジェクトマネージャの「「はやぶさ」、そうまでして君は。」内で簡単に触れられている。
スタッフの多くは、長い宇宙の旅路の果てに帰還してきた機体を、科学的な意味からも心情的な意味からも、何とかして残したかったのだが、サンプルリターンという大目標の為に、機体焼失による運用終了という道を選んだのである。
その悔しさ、哀しさがあの再突入時のスタッフの涙に繋がっていると筆者は理解しているのだが、作品の中では、計画変更によって機体が大気圏に突入したことは触れられていない。最初からの予定だったように見えてしまうのである。計画通りだったら、スタッフはあんなに泣かないだろうと思うのだ。
「はやぶさ」関連の映画は、あと２本が製作中である。
対象は FreeBSD 7.x, 8.x, 9.0 系です。
（続きに周知メールを転載）
]]>
Content-Type:
text/plain; charset=ISO-2022-JP
=============================================================================
FreeBSD-SA-11:05.unix Security Advisory
The FreeBSD Project
Topic: Buffer overflow in handling of UNIX socket addresses
Category: core
Module: kern
Announced: 2011-09-28
Credits: Mateusz Guzik
Affects: All supported versions of FreeBSD.
Corrected: 2011-10-04 19:07:38 UTC (RELENG_7, 7.4-STABLE)
2011-10-04 19:07:38 UTC (RELENG_7_4, 7.4-RELEASE-p4)
2011-10-04 19:07:38 UTC (RELENG_7_3, 7.3-RELEASE-p8)
2011-10-04 19:07:38 UTC (RELENG_8, 8.2-STABLE)
2011-10-04 19:07:38 UTC (RELENG_8_2, 8.2-RELEASE-p4)
2011-10-04 19:07:38 UTC (RELENG_8_1, 8.1-RELEASE-p6)
2011-10-04 19:07:38 UTC (RELENG_9, 9.0-RC1)
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit ]]>