[過去ﾛｸﾞ] 【VideoLAN】VLC media player 29 (ﾜｯﾁｮｲ無し) (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
577: 2019/07/24(水)12:22 ID:fyzh9H9D0(1/2) AAS
正直CVEは
VLCチームだけに報告してさっさと直してもらってから公開してほしいわ
578: 2019/07/24(水)14:59 ID:fyzh9H9D0(2/2) AAS
外部ﾘﾝｸ:nvd.nist.gov
3か月以内の物を検索して4件
クリティカルなものが多い
579: 2019/07/24(水)15:42 ID:Bia5zKzV0(1) AAS
2.2.8使ってればとりあえずセーフなんだな
580(1): 2019/07/24(水)15:47 ID:knPqJklg0(1) AAS
>>576
理屈とかわからんが
俺もまったく同じ状態だ
切った方が速くなる場合と、切らない方が速い場合があってよくわからん
581: 2019/07/24(水)17:21 ID:u9RcDULJ0(1) AAS
そもそもローカルの動画しか再生しないし
582: 2019/07/24(水)19:32 ID:RqvTdaYK0(1) AAS
Confusion about a recently disclosed vulnerability in VLC Media Player
外部ﾘﾝｸ:www.ghacks.net
何が何やら・・・
583: 2019/07/24(水)20:52 ID:OITI/fVs0(2/3) AAS
>>580
ですよね
あと、動画が重くてもコマ落ちするだけにしてほしい
VLCみたいに画面がぐちゃぐちゃに溶けられると何もできない…
一定率以上デコードできなかったコマはフリップしないとかもっと賢くやるモードを付けられないかなと思う
「ハードウェアアクセラレーションを切らないとコマ落ちする、切ればコマ落ちしない」、なんてことも
自動的に試行して、最適の状態に追従するモードを付けて欲しい、
例えば動画再生中に特定のキーを押したら、その時点で色々試行して負荷状況に合わせて自動設定するとか。
その時に、「バッファRAMに使うのはビデオカードとメインメモリのどっちにするか」とかの項目も、どっちが速いのか、
実測して、速い方に自動的に決めてくれる機能が欲しい（本来は別の意味の選択項目なのだろうけど）
584(1): 2019/07/24(水)21:28 ID:qJCsIIiw0(1) AAS
>>576
古いRadeonのハードウェアアクセラレーションは4K非対応だからじゃない？
585: 2019/07/24(水)22:36 ID:OITI/fVs0(3/3) AAS
>>584
そうなんだ。なるほどね。
4k非対応ってのはGPU支持のコマンドを送った時に拒否が返されるのか、それともOKは出すくせに性能が追いつかないって意味なのか、
たぶん後者なんだろうけど。
他のプレイヤーみたいに、（処理が追いついてない時も）コマ落ちしながらもどうにか画面が見られるんならいいんだけど、
VLCみたいに画面ぐちゃぐちゃで何も見れないんじゃ、（CPUの負荷を落とせるとはいえ）再生してること自体に何の意味もなくなるんだから、
自動的にGPUアクセラレータを無効にもしてみて、いい方を採るオプションを付けるとか、賢くなってほしいわ。
586: 2019/07/25(木)01:29 ID:y6rTxgv+0(1/2) AAS
今回の脆弱性というのはVLCの通信をファイアウォールで全部遮断してるおいらでも危険なものなのかの？
587: 2019/07/25(木)01:42 ID:T/pV7CL80(1) AAS
そもそも脆弱性があるかどうかが分からない状況みたいよ
仮に正しければ細工されたファイルの再生によるコード実行だから通信遮断で安全とも言い切れないと思う
588(1): 2019/07/25(木)02:17 ID:n4ktizyw0(1) AAS
続報 再検証結果
#22474 closed defect (fixed) heap-buffer-overflow on demux_sys_t::FreeUnused
外部ﾘﾝｸ:trac.videolan.org
Issue is too old libebml in Ubuntu 18.04: libebml 1.3.6 fixes this issue.
End of story: VLC is not vulnerable, whether this is 3.0.7.1 or even 3.0.4.
The issue is in a 3rd party library, and it was fixed in VLC binaries version 3.0.3, out more than one year ago...
1年以上前に3.0.3nightlyで対策済3.0.4安定版以降最新の3.0.7.1の脅威ではない
589: 2019/07/25(木)02:47 ID:DRkP0sN20(1/2) AAS
一次情報確認しない&関係者に問い合わせない糞メディアを炙り出す踏み絵みたくなってるな
590(1): 2019/07/25(木)03:08 ID:y6rTxgv+0(2/2) AAS
>>588
んー、つまり、安全宣言が出て事態は収束したってことでおｋ？
591: 2019/07/25(木)03:21 ID:DRkP0sN20(2/2) AAS
>>590
報告者のおま環だった可能性が高い
脆弱性スコアががっつり下方修正されてるけどvideolanはそもそも脆弱性はないと言ってる
外部ﾘﾝｸ:www.cert-bund.de
592: 2019/07/25(木)04:11 ID:7p7ibOlH0(1) AAS
ロクな検証しないで酷い話だな
593: 2019/07/25(木)08:52 ID:a9vNzlC/0(1) AAS
ゴリホーモの言いがかり陰湿やなあ
594: 2019/07/25(木)10:42 ID:MIodg0190(1) AAS
一部メディアが報ずる「VLC media player」の致命的な脆弱性は誤り
外部ﾘﾝｸ[html]:forest.watch.impress.co.jp
報じられている脆弱性は「libebml」と呼ばれるサードパーティー製ライブラリに起因するもので、16カ月以上前にすでに修正されている。
「VLC」でもv3.0.3から修正されており、報告された問題は再現できなかったとのこと。
報告者は古い「Ubuntu 18.04」を利用しており、ライブラリが適切にアップデートされていなかったようだ。
しかし、この未検証の脆弱性はMITREにも通報され、開発チームに知らされないうちに“CVE-2019-13615”として登録されたという。
「VLC」の開発チームは、今回のような事例は初めてではないとして、CVEの管理方法を強く批判している。
595: 2019/07/25(木)12:34 ID:P26z4vB70(1) AAS
ダークウェブに掲載されてる
596: 2019/07/25(木)13:16 ID:YVpe165t0(1) AAS
結局問題なかったんかい、アンインストールしちまったよ
まあアプデしてなかったから最新版にするか
上下前次1-新書関写板覧索設栞歴
あと 406 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.017s