
Linux、2003年にバックドアを仕掛けられそうになっていた 56
ストーリー by headless
改変 部門より
改変 部門より
2003年に何者かがLinuxカーネルにバックドアを仕掛けようとしていたそうだ(Freedom to Tinkerの記事、
本家/.)。
当時、Linuxはソースコードのマスターコピーを保存するのにBitKeeperを使用していたが、BitKeeperを好まない人もおり、CVSにBitKeeperのクローンが置かれていたとのこと。マスターコードに変更を加える場合は認証プロセスを経る必要があり、認証された変更には短い説明と認証の記録へのポインターが含まれているが、2003年11月5日にCVSで認証の記録のない変更が発見される。調査を行ったところ、この変更は認証されておらず、BitKeeperのマスターコード側には存在しなかったという。変更内容は一見するとwait4関数を特定の方法で呼び出した際のエラーをチェックするコードのようだが、実際にはこの方法でwait4関数を呼び出すプログラムによるルートアクセスが可能となる古典的なバックドアだったとのことだ。
当時、Linuxはソースコードのマスターコピーを保存するのにBitKeeperを使用していたが、BitKeeperを好まない人もおり、CVSにBitKeeperのクローンが置かれていたとのこと。マスターコードに変更を加える場合は認証プロセスを経る必要があり、認証された変更には短い説明と認証の記録へのポインターが含まれているが、2003年11月5日にCVSで認証の記録のない変更が発見される。調査を行ったところ、この変更は認証されておらず、BitKeeperのマスターコード側には存在しなかったという。変更内容は一見するとwait4関数を特定の方法で呼び出した際のエラーをチェックするコードのようだが、実際にはこの方法でwait4関数を呼び出すプログラムによるルートアクセスが可能となる古典的なバックドアだったとのことだ。
超既出 (スコア:5, 参考になる)
http://srad.jp/story/03/11/07/0259211/ [srad.jp]
今回の件と同じ話であることは、コメント [srad.jp]→本家 [slashdot.org]→MLの投稿 [indiana.edu]とたどっていけば明らか。
なんで今はじめて判明したかのような話になってるの?
Re:超既出 (スコア:1)
・・・てことが昔あったけど、
あんときのアレはNSAの仕業だったんじゃねーの?
てのが今更話題になってるポイントのようですが
本家から/.Jへの引用時に最後が欠落したようです
(途中で切れたので再掲)
なにこの記事… (スコア:1)
#2476360も触れてる通り、既出も既出の話であるし。
そもそもこの問題の根源は、C言語でもなければ、BitKeeperにもなく、CVS、これ。
CVS 脆弱性でググればわんさか出てくる、当時の脆弱性の山こそが問題点。どんだけあったと思ってんの?
そしてこれこそがLinuxがCVS、ひいては完全なCVSとやらを目指して初まったSubversion嫌いへと繋がってるわけ。
だいたいからして、BitKeeperのクローンを勝手に作って無償提供打ち切られるわ、CVS版にはバックドア仕掛けられるわ、プロプラSCM使うことに対する論争はいつまでもいつまでも続くわとウンザリした結果がgitの作成なわけ。
gitの名前がgitなのも、そういったウンザリさせた奴等に対するLinusの皮肉なわけよ。
それを何をどう勘違いしたのか、それから10年も過ぎた今頃になって。
「2003年にバックドア仕掛けられそうになったことあるわー。危なかったわー」とかいうミサワばりの勘違い記事を元にタレこむとか…
情報弱者にも程があるだろ常識的に考えて。
誰だよ?こんなタレコミ採用した馬鹿。
ちゃんとチェックしてから採用しろよ。
10年前はさすがに・・・ (スコア:0)
2003年に既出、ってのは当時とは編集者も読者もだいぶ入れ替わってるし、気づけといっても厳しいっしょ。
それに気づけた古参な人が、やさしく指摘してあげつつ、当時を偲んで語ればいいと思うよ。
#下手すると生まれてない、って人もいるでしょ。
Re: (スコア:0)
そうか、じゃあこれからはWin95にバックドアが仕掛けてあったとか、ウィルスがあり得ないほど蔓延し始めたとかアプリの互換性がボロボロだったとか言うタレコミがわんさか出てくるわけだw
最近は都市伝説ばかりを信じて、昔のWinユーザーは(9801からの移行ですら互換性問題は無かったかのようにw)ハッピーな生活を送っていたと信じる人達もいるから、当時の記事がタレこまれるとむしろ新鮮に感じるかもね。
Re: (スコア:0)
> 初まった
なんて読むんですか?
Re: (スコア:0)
英訳して本家に言ってきなよ…
既にやつらは浸透している (スコア:0)
しかし、混入時に発覚せず、そのまま今に至るバックドアがいくらでもありそう。NSAにしろ、CIAにしろ、それをねらってる訳だしね。
Linuxに限らず、OSに限らず。
Re:既にやつらは浸透している (スコア:1)
アイヤー、ソフトよりハードに仕掛ける方が楽アルネ
Re:既にやつらは浸透している (スコア:1)
米政府系の場合はオープンソースなソフトよりプロプライエタリなソフトに入れさせる方が楽なんだろうなぁ
Re:既にやつらは浸透している (スコア:1)
ほぉ、バックドアですか。
あなたはソレをどうやって知ったのですか?弊社製品は知的財産権保護のために暗号化されておりますが。
なにリバースエンジニアリング。それはいけませんね。
デジタルミレニアム著作権法違反で提訴します。
Re: (スコア:0)
米政府が米企業のプロプライエタリなソフトを使う場合はいいんだろうけどよ
Re: (スコア:0)
職歴にNSAがあったり家族にCIA職員がいる人の投稿は制限したほうが良さそうですね。
Re:既にやつらは浸透している (スコア:1)
?
SELinuxの開発者は現役だよ?
日本人開発者と喧嘩になってLinusが中をとった。
基本誰がどこを書いたかわかってるし誰でも内容を見られるからかえっておかしなことはやりにくいと思うけど。
Re: (スコア:0)
SELinuxってNSAが提供してるんだ。
TOMOYO Linuxのときに強硬に反対して組み込み阻止しようとしたのは実はSELinuxに……
#考え過ぎか
Re: (スコア:0)
Android4.3がSELinuxを採用しているのですが、これ大丈夫なんでしょうか。
http://source.android.com/devices/tech/security/se-linux.html [android.com]
Re: (スコア:0)
自分で考えれば?
俺が大丈夫と言ったら使うのか?ってーか、何を心配してるんだ?
Re: (スコア:0)
乱数命令の件といいLinusマジGJ
Re: (スコア:0)
職歴を調べる手間をかけるなら、コードを調べたほうがずっといいだろ。
Re:既にやつらは浸透している (スコア:1)
本職のスパイ相手に、素人が職歴や家族構成を調べて対策って、どう考えても戦う前から負けてるわw
そんなことより、こっちの土俵であるコードの品質で戦った方がいいに決まってるな。
Re: (スコア:0)
本職のスパイですが言ってるような意味のスパイじゃないですよ。
LinkedInに盗聴プログラムのコードネーム書いちゃううっかりさんとか。
コミュニティ村八分にするというのはやっていることは制裁の意味も込めて有効だと思います。
Re: (スコア:0)
うっかりさん対策なら効果あるだろうけど、セキュリティ対策としては無意味だよね。
架空の完璧に無害な経歴持ちの人が、何年にも渡り普通のコードを投稿して、ある日ミスに見せかけてバックドアを仕込ませる・・・CIAやNSAってのはそういうことが出来る相手だと思いますよ。
Re: (スコア:0)
家族にCIA職員というのはともかく職歴にNSAがある時は警戒した方が良さそう。
部署にもよるがプログラマーなら盗聴を知ってた可能性もあるし、その場合政府の盗聴行為に抵抗のない人だということになるので。
NSAだろうが中国の検閲だろうがそういうことに関わっている人は隔離しておいた方が無難。
Re: (スコア:0)
盗聴行為を知った時点で辞めても職歴にNSAは残るので、
「職歴にNSAがあったら盗聴行為に抵抗のない人」という推論は賢くないと思う。
Re: (スコア:0)
お上が変えない価値がある。変えるものはマスターコードへ。
Re: (スコア:0)
だから、オープンソースだから安全という説は悪魔の証明そのものなんだよね。
無保障、未確認で使ってるだけ。
プロプラはその点、発覚時には責任を追求出来るだけまし。
Re:既にやつらは浸透している (スコア:1)
オープンソースのシステムは一つのところが集権的に開発しているわけではなくて、
例えばLinux本体に直接バックドアを仕掛けられなくても、GCCでもglibcでもOpenSSHでもApacheでも、
どこか一箇所に仕込まれたら一般的なLinuxベースのシステムはアウトだから厳しそうだよな。
逆にWindowsだとMSが確実に信用置けるならかなり安全かもしれない、ハードウェアまで危ないというなら本当に全部自社で作れるIBMだと安全かもしれない、
と言えなくもないが、現実的にはアメリカの大企業が圧力かけられたらどうしようもないだろうし、安全なんて無いのかね。
Re: (スコア:0)
じゃあハードまで公開されているBeagleBone Blackとか。
# 次はミクロの戦い(CPU内部)だ。
# ってことはCPUの創り方?
Re: (スコア:0)
Re: (スコア:0)
プロプラのことを言っているのだと思うが、バックドアが仕掛けられていることを外的視点から発見することはある。
バックドアなので、どうしても外とのやり取りが発生するのでわかるんだね。
で、たとえそうやってプロプラが酷いと言ったとしても、オプソの安全性を証明することは悪魔の証明であり、安全であるということは不可能っていうことには間違いないわけだ。
Re: (スコア:0)
で、たとえそうやってプロプラが酷いと言ったとしても、オプソの安全性を証明することは悪魔の証明であり、安全であるということは不可能っていうことには間違いないわけだ。
どうもいろいろ理解されていないようです。
オープンソースであれば安全だと主張する人など誰もいませんよ。
プロプラのことを言っているのだと思うが、バックドアが仕掛けられていることを外的視点から発見することはある。
外的視点から発見できないこともあるわけですね。
そういった場合にはどうするんでしょうか。
バックドアなので、どうしても外とのやり取りが発生するのでわかるんだね。
そんな時代もありましたね。
でもそんな昔の話を持ち出しても意味ないと思います。
C が悪い(フレームのもと) (スコア:0, 興味深い)
if((...) && (uid = 0)){}
これを 0 == uid 以外だめってことにすればいいんじゃない?
というか eq とか subst とかいうマクロにしたらどうだい?
Re:C が悪い(フレームのもと) (スコア:1)
その手のミスはコンパイラが検知してくれるので、わざわざおかしな書き方を強制するのは本末転倒。左辺に定数を書かせるやり方は、そもそも比較の両辺が変数だった場合に適用できないし。
Re:C が悪い(フレームのもと) (スコア:1)
本家には wait4: 'if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) ...' と書いてますね。なんで日本語だと本文に無いんだか。
で、これだと代入が括弧で囲まれてるから警告出ないと。確かにcurrent.uid == 0だと括弧要らないですが、&&の右辺だと括弧入れるコーディングスタイルの人も多いから厄介ですね。それもあって単なるうっかりミスかもしれないとも言われてました(ちゃんと議論追ってないので良く分からないですが)。
この場合だと二重括弧じゃないと警告出すようにすれば良いとも思うのですが、しかし色々と一貫性を考えてみるとそもそもCの構文が悪い気もする。
Re: (スコア:0)
> 色々と一貫性を考えてみるとそもそもCの構文が悪い気もする。
つまり、「=」が代入で「==」が比較というCの定義が悪いということだと思います。
あるいは、代入を構文ではなく演算子だとしてしまったために、式が書けるあらゆる
ところで代入が可能になってしまったのが悪いということでしょうか。
たしかに、Cの基本設計(代入は演算子なので、本来、ifの条件式の中でも代入が
できるべき)を認めた上で、かつ今回のような問題を防ぐには、小手先の小細工になって
しまうし、一貫性を失って奇妙なことになる(カッコで囲まれていたら警告を出さないとか)
と思います。
だったら、Cでその定義は今更変えられないから、新しい言語を作って、
BASICみたいに「=」は演算子じゃないことにしてしまうか、
FORTRANみたいに比較は「eq」とかを使うようにするか、
Pascalみたいに代入は「:=」で比較は「=」にするか、
でも、C式の定義がC以外にも広く使われてるし、かえって混乱を招くかもしれません。
Re: (スコア:0)
代入が式であることが問題で、記号はどうでもいいでしょう。
あとは条件式がbool以外を取れることが問題です。
言語仕様を変えなくても、コンパイラがそれをチェックして警告を出すことは可能だと思いますよ。
Re: (スコア:0)
しかし、この場合、条件の値が0なので、もしそんな警告が存在すれば、NULLやFALSEを0と定義している場合、全て警告を出されてしまうので、到底実用的じゃないと思う。
言ってるように、括弧が付こうがなんだろうが、代入を式として評価しない方がいいし、それで十分だろう。
Re: (スコア:0)
括弧付き代入の警告も、既存のプログラムだと警告が結構でるかもしれないと思ったので、
その点はあえて目をつぶりました。警告はOFFにできるしね。
Cじゃない別の言語を作る話なら、bool以外取らないという解決策の方が個人的には良いと思う。
代入式がそこら中に書けるのはシンプルで分かりやすいコードにできる方法だと思う。
代入1つのために中抜けループとか作りたくないし。
Re: (スコア:0)
> Cじゃない別の言語を作る話なら、bool以外取らないという解決策の方が個人的には良いと思う。
if ((count < MAX) || (f = true)) {
のようにbool型の変数へ代入してしまうバグは残る(作れる)ので万全とはいいにくい気が
# さらにboolの比較演算子をなくせばいいかな?
# if (!is_not_support() != false) みたいなコードもなくなるし
> 代入1つのために中抜けループとか作りたくないし。
while (c = getchar() ; c != EOF) {…}
のようにかければ、ほかは「代入文」でもなんとかなりません?
個人的には「代入文」(もしくは代入演算子の戻りをvoid)にして整理したほうが学習コストもバグ発生率も下げられるのでは?と思ってます
Re: (スコア:0)
#2476303 ですが、私が考えてたのは、代入が式として扱えることには何ら異論はなくて、
exp1 && exp2は正当なのに、if exp hogeと書けないのが変だなということでした。
&&のような条件演算子だって短絡評価を使えば実際if文に近い使い方はできるのに、左右に表れる式に括弧をつけなくても問題ない。ただし、自主的に括弧をつける人も多い。
一方、if文だと式に必ず括弧をつける必要がある。
で、代入文を括弧で囲わないと式として扱わない(警告を出す)ようにした場合、if文だとコード上は二重の括弧で囲われた形になるのに対し
Re: (スコア:0)
&&のあとだとどうだとか、二重括弧がどうだとか、
こんなにややこしいことを考えないといけないのなら、
いっそのこと、代入を式として扱えることを放棄してしまったほうが単純明快なのではと思います。
ひとつで複数の副作用を起こせる文(あるいは式)が存在する、ということそのものが、
人間のすなおな理解を超えているんじゃないかと思うのです。
(べつに、人間の理解力を超えていると言いたいわけじゃないです。
疲れてるときとか、うっかりとか、そういうときにミスが出やすいポイントだと思います)。
というわけで私は #2476486の意見に賛成です。
Re: (スコア:0)
いろいろ組み合わせると、マクロの方が鬱陶しいからなぁ。 定数を先に書くのはよくやるけど、両方変数だったら、運を天に任せる感じ。
Re: (スコア:0)
規約やマクロを用意したって、悪意があれば使わないでしょう。
「警告を尊重せよ」で充分な気がする。
Re: (スコア:0)
-Werror ですねわかります
Re: (スコア:0)
#include >iso646.h>
Cのダメなところはそこじゃない (スコア:0)
そういうおまじないは、鼻から出てきた悪魔には通用しない。どれだけ完璧なエラーチェックだとしても、未定義の悪魔はエラーチェックごと消し去ってしまう。
マクロ展開やインライン展開の裏側では、
プログラマの与り知らない所で、大量のデットコードが生成され、それを元に最適化がかけられるという。
世にも恐ろしい儀式が行われている。儀式の最中にコンパイラのオプティマイザが悪魔召喚の危険性を感知し警告したとしても、
殆どのプログラマはその警告を理解することが出来ない。なぜならそのコードはプログラマーが書いたものではないからだ。
そして悪魔そのものを召喚したデットコードは最適化の過程で削除される。
その結果、極めて妥当に見えて、まるで動いている様に見える、そしてその実、全く意味のないコードが発生する。
Re: (スコア:0)
まあなんだ、少なくともデッドコードと未定義挙動は全く別の警告が出るものだと思うが
それくらいはプログラマが理解しましょうよ
Re: (スコア:0)
どんなトラウマがあったのかは知りませんが、デッドストリップ最適化も未定義動作もゴッチャにして恐れてる時点で…。
Re: (スコア:0)
(1) そもそもifの中で代入なんかするのが悪い、代入したけりゃ分けて書け、というコーディングスタイルを確立する。
(2) それと同時に、ifの中で代入していたら、(カッコで囲っていようとも)問答無用でコンパイラが警告あるいはエラーを出すようにする。
定数を先に書くのはありだけど、比較をうっかり(あるいは、うっかりに見せかけて故意に)代入にしてしまうのを
防ぎたいという話なのだから、定数を先に書くのをうっかり忘れるのを防止する手段を講じない限り意味がない。
クリップ一発 (スコア:0)
UTPにカレントプローブをクリップしてFET入力のOPアンプでバッファしてHUBにつなげばあら不思議。