Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#47738 - [ffmpeg] rebuild without network support until the vulnerability is fixed

Attached to Project: Arch Linux
Opened by Сковорода Никита (ChALkeR) - Wednesday, 13 January 2016, 11:14 GMT
Last edited by Maxime Gauduin (Alucryd) - Friday, 15 January 2016, 19:44 GMT
Task Type Bug Report
Category Security
Status Closed
Assigned To Maxime Gauduin (Alucryd)
Architecture All
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No

Details

ffmpeg has a vulnerability in the current version that allows the attacker to create a specially crafted video file, downloading which will send files from a user PC to a remote attacker server. The attack does not even require the user to open that file — for example, KDE Dolphin thumbnail generation is enough. Desktop search indexers (i.e. baloo) could be affected. ffprobe is affected, basically all operations with file that involve ffmpeg reading it are affected.

The vulnerability is public (as public as it could be, it was on the index page of http://www.alexa.com/siteinfo/habrahabr.ru (and is now on page4 of the same site), has code samples and instructions on how to build a malicious file. The original blog post is in Russian: http://habrahabr.ru/company/mailru/blog/274855/, but you can use https://translate.yandex.com or https://translate.google.com to read it.

Short English summary at https://news.ycombinator.com/item?id=10893301

The recommended work-around is to rebuild ffmpeg without network support (--disable-network configure flag) until the vulnerability is fixed upstream.
This task depends upon

Closed by  Maxime Gauduin (Alucryd)
Friday, 15 January 2016, 19:44 GMT
Reason for closing:  Fixed
Additional comments about closing:  1:2.8.4-4
Comment by Сковорода Никита (ChALkeR) - Wednesday, 13 January 2016, 11:15 GMT
Moved from https://bugs.archlinux.org/task/47737, that one had wrong Project.
Comment by Сковорода Никита (ChALkeR) - Wednesday, 13 January 2016, 13:05 GMT
--disable-protocol=hls could also work, though I'm not exactly sure.
Comment by Ed Svaded (svadkos) - Wednesday, 13 January 2016, 15:35 GMT
Actually, this --disable-protocol=concat
And this issue also applies to libav and so on.
Comment by Сковорода Никита (ChALkeR) - Wednesday, 13 January 2016, 16:23 GMT
I am not sure that --disable-protocol=concat would solve this completely. Btw, one could also do --disable-demuxer='hls,applehttp', but rebuilding without network support looks like a more robust solution for now (until the issue is inspected and fixed upstream).
Comment by Maxime Gauduin (Alucryd) - Wednesday, 13 January 2016, 18:16 GMT
I'd rather only disable the offending demuxers than cripple the package, rebuild with --disable-demuxer='hls,applehttp' it is. @ChALkeR: did you try and confirm it does indeed do the trick?
Comment by Сковорода Никита (ChALkeR) - Wednesday, 13 January 2016, 18:37 GMT
@Alucryd A proper confirmation would involve inspecting the source code of ffmpeg to find other possible instances of the same vulnerability.

I did not do that, and I did not even try rebuilding with hls,applehttp disabled.
Comment by Maxime Gauduin (Alucryd) - Wednesday, 13 January 2016, 19:15 GMT
@ChALkeR: According to an ffmpeg dev, disabling hls should be enough, I'll also disable the concat protocol to be safe.
Comment by Chih-Hsuan Yen (yan12125) - Wednesday, 13 January 2016, 20:52 GMT
> According to an ffmpeg dev, disabling hls should be enough

Is there a mailing list archive or a bug report about this statement?
Comment by Maxime Gauduin (Alucryd) - Wednesday, 13 January 2016, 21:54 GMT
Nah, straight from IRC. I'll link this here though: http://seclists.org/oss-sec/2016/q1/85
Comment by Сковорода Никита (ChALkeR) - Wednesday, 13 January 2016, 23:36 GMT
mplayer is still affected.
Comment by Сковорода Никита (ChALkeR) - Wednesday, 13 January 2016, 23:45 GMT
Looks like mplayer bundles libavformat internally, that's why it's still affected.
Comment by Chih-Hsuan Yen (yan12125) - Friday, 15 January 2016, 17:52 GMT
Seems ffmpeg has fixed the problem. [1][2] Maybe include these fixes instead of disabling the whole HLS? HLS is important for downloading videos with youtube-dl for some websites. [3]

[1] https://github.com/FFmpeg/FFmpeg/commit/cfda1bea4c18ec1edbc11ecc465f788b02851488
[2] https://github.com/FFmpeg/FFmpeg/commit/6ba42b6482c725a59eb468391544dc0c75b8c6f0
[3] https://github.com/rg3/youtube-dl/issues/8242

Loading...