1991年から存在していたX11のバグが発見される 37
ストーリー by headless
発見 部門より
発見 部門より
あるAnonymous Coward 曰く、
X.Orgは7日、X11に1991年から存在する脆弱性が発見されたことを発表した(X.Org Security Advisory: CVE-2013-6462、 Phoronixの記事、 本家/.)。
原因はlibXfontのバグで、BDF形式のフォントファイルをパースする際にスタックオーバーフローを引き起こす可能性があるというもの。このバグはX11R5から存在し、libXfont 1.4.6に至るすべてのバージョンに影響するという。
なお、X.Orgではバグを修正したlibXfont 1.4.7を1月7日にリリースしている(libXfontのgitリポジトリ)。
フォントか (スコア:5, おもしろおかしい)
フォントなのか
Re: (スコア:0)
フォントです
Re: (スコア:0)
フォトントゥーピードです
Re: (スコア:0)
フォンドボーです。
2009年ぐらいからWindowsでは常識です (スコア:4, 興味深い)
「Windows が特別に細工された OpenType フォント ファイルや TrueType フォント (TTF) ファイルを処理する方法、および Windows がメモリ内のオブジェクトを処理する方法を修正することにより、これらの脆弱性を解決します。」というMSxx-xxxの説明を何度見たことか。
セキュリティバグだけど、そのためにまず特定の特別に細工された悪用用フォントをロードさせるところから始めるんだから悪用の実用度低いと思うけどねぇ。
ちなみに「特別に細工されたフォント [microsoft.com]」のキーワードでTechnetで検索すると約 16,300 件もヒットしちゃう。
※このキーワードで脆弱性情報以外の話題が入るとは思えない
Re:2009年ぐらいからWindowsでは常識です (スコア:1)
つ[Webフォント]
woffも結局内部でotfに変換してからロードしてるし。
Re: (スコア:0)
IEのWebフォント（というかスタイルによるフォント置換）の処理は挙動が怪しい。
やんちゃな記述をすると簡単にクラッシュする。
バグの見つけ方 (スコア:3)
cppcheckに掛けたら見つかったって事なのかな。
古いソースコードなんて読まないから、やっぱりそうなるのか。
BDF形式ってなんだ…? (スコア:2)
と思って検索したらBitmapfontだった.
ディスクの中を検索したら,tex用に一応存在した.
どっかに書いてあったけど,誰もメンテしないようなコードはさっさと削ってしまうのが良いという事ですね.
Re:BDF形式ってなんだ…? (スコア:2)
日常生活の X11 で bdf 形式を常用することは基本的になく、bdftopcf で pcf に変換して使うものです。そういう話ではない?
実際 bdf はテキストファイルなので、ソースコードみたいなものですね。
X11R4 の頃は pcf でなく snf というのになっていて、アーキテクチャが違うマシンに持って行くと..
さっき bdf2pcf かと記憶違いで見つからなかったのは秘密
空目 (スコア:1)
X1のバグと空目してしまったんですがこの何とも言えないもやもや感はどこに持っていけば良いんでしょうか？
Re:空目 (スコア:1)
１９９１年から稼働していた、我が家の冷蔵庫の脆弱性が先週発見され、
冷却機構が停止し、貯蔵品に深刻なダメージが生じました。
しょうが無いので全貯蔵物を廃棄すると共に、新形へのリプレースを本日決行しました。
＃普通に寿命ですね。むしろ今までよく動いた。
Re:空目 (スコア:1)
使用者の内臓にはダメージはありませんでしたか？
Re: (スコア:0)
まだ間に合います。こちらに応募するのはいかがでしょうか。
http://www.conoha.jp/conoha/1097.html [conoha.jp]
マルチバイト系の処理とか (スコア:0)
マルチバイト系の処理とか、ほとんど誰もチェックしてなくて、バグがたまってそうな気がする。
Re:マルチバイト系の処理とか (スコア:1)
X11のプログラムを最後に作ってから１５年くらい経ってるんで記憶があいまいですが、文字はコンパウンドストリングとかいうのに変換しないと表示できず、ちゃんとマルチバイトだとかマルチリンガルが考慮されていたような。
まあ、だからと言って十分なチェックされてる保証は無いですが。
Xtの方の仕組みだったかな？
Re:マルチバイト系の処理とか (スコア:1)
私も20年近く前の知識ですが、マルチバイト系（というかマルチリンガル系）の関数セットと、バイト系の関数セットの２通りがありますね。
個々のアプリケーションを書く個々のプログラマが、マルチリンガルのことを意識して、あえて難しいほうの書き方をしないと、
そのプログラムはマルチバイト対応にならない（なのでマルチバイト対応アプリケーションの割合は全然高まらない）という仕組みです。
どうやって世界中のプログラマにマルチリンガルの必要性を説いて回るんだ、と思ったものでした。
何もないところから、その仕組みを作ってXに入れさせただけでも、ものすごい功績だとは思いますけど。
Re: (スコア:0)
ああ…Lesstifが日本語通らなくてソース修正しまくった思い出がよみがえってまいりました…。
Perfect is the enemy of good (スコア:0)
で、デフォルトの文字列をUTF-8にしようとしたら日本の原理主義者が反対するというおなじみすぎる流れでもう笑うしかなかった。あいつらがいなかったらアプリケーションの(あいつらの主張によれば)なんちゃって国際化は10年くらい早まったんじゃねーの。
Re:Perfect is the enemy of good (スコア:1)
米国でコードを書いていた経験から言わせてもらうと、それは1byte文字コード圏の人を甘く見すぎです。
Re:Perfect is the enemy of good (スコア:1)
void mbcs2wcs(unsigned char *mbcs,unsigned short *wcs,int len){
while(len--)*(wcs++)=*(mbcs++);
}
みたいなこと平気でやるからなぁ…
# お前の事だぞ、Adobe。
Re: (スコア:0)
だからこそ、日本語圏プログラマが率先してマルチバイトを利用していかねばならんのです。
テスターだと思ってください。
Re: (スコア:0)
Unicodeすらまともに扱えない連中がそれよりはるかにはるかに難しいISO/IEC 2022系のi18nにまともに対応してくれるという思考回路が理解不可能。
Re: (スコア:0)
そう読み取ったら理解不可能だろうね
Re: (スコア:0)
ここには、いまでもメールはISO-2022-JPに拘ってる奴が大勢いるじゃんよ。
Re: (スコア:0)
Marericksの仕様の隙間を突いて [applech2.com]までISO-2022-JPでの送信に固執する奴とかどうにかしてほしい
Re:Perfect is the enemy of good (スコア:2)
折角なので関連リンク
日本語のe-mail、ISO-2022-JP以外のcharsetを使うのは是か非か [srad.jp]
Re: (スコア:0)
何で？
Re: (スコア:0)
Win 32のUnicode系のAPIの使用率すらなかなか高まらないんだから、いわんやISO/IEC 2022ベースのマルチバイト系APIをや
Re: (スコア:0)
プロプライエタリ・ソフトウェアにバグは存在しませんすべて仕様ですの間違いじゃないの？
Re: (スコア:0)
まるでOSSにはバグが存在するような言い回しだな
Re: (スコア:0)
#2526466は『Wiondowsはもっとひどいアピール』だったのか…
X11では2014年にようやくバグが発見されました⇒Windowsでは2009年頃から同様のバグを見つけて修正しています⇒さすがはMicrosoft、というアピールかと思ってた。