• 1(current)
  • 2
  • 3
  • 4
  • 5
  • 7
Known security risk unresolved for gotham due to obsolete internal ffmpeg code
#1
Thumbs Down 
The debate of using internal ffmpeg code versus external ffmpeg one is not new and XBMC devs have made it clear they have no intend to support external ffmpeg.

However, in light of new post about security problem http://googleonlinesecurity.blogspot.com...fixes.html and http://ffmpeg.org/security.htmluser and packagers should be warned that by using XBMC with internal ffmpeg code, they will put their system at risk because the bugs that have been discovered and fixed in upstream are still in XBMC internal ffmpeg code.

Worse, opening bugs for gotham related to this particular security issues have been purely closed as WONT FIX meaning security issues are deemed not important:http://trac.xbmc.org/ticket/14838 In addition while it was possible to use external ffmpeg code, devs intend to drop this feature without clearly indicating that they will make effort to stay current with ffmpeg code.

I really do not understand the rationale behind such move and closing security bug as WONTFIX is for me a bad practice.

EDITED: fixed URL as per comment.
Reply
#2
Im pretty sure that, instead of complaining if you submit a PR for the patch security patch that fixes the problem it will be done.

However I dont see neither a specific security issue being pointed to nor a ffmpeg upstream patch nor any trac issues link goes nowehere and pointing to ffmepg changelogs and releases wont do anything to help any point you had.

This is a poorly constructed argument and -- fact all you will achieve is cause further hate for this subject.
Reply
#3
You pretend none of the bug listed in the links above are in XBMC internal ffmpeg? Fine. I pretend you did not read the article nor the ffmpeg git changelog or the ffmpeg security link and just demonstrate the lack of security awareness of some members.

I do use external ffmpeg so I'm not affected by most of the the security issues. However, preventing me to do this by forcing me:
1) to use an outdated version of ffmpeg by supporting only internal version,
2) or closing bugs solely on the fact hat exetyrenal ffmpeg is not supported
is just getting on y nerves. I do not choose to have my internal copy of a widely available program. XBMC dev did, but forget the security implications of it.
Reply
#4
Err, we could fix all bugs, release and the very next day have 10 more bugs 'found'. it's a never ending cycle. so we do the best we can with limited resources.

What we try to do is have the most compatible version of FFMpeg with our patches that matches our internal code for the best playback, decode experience. Given that we allow user installed addons that can access the entire system seems to be a more serious security issue. Crafting a malicious addon is trivial and it's also trivial to install a payload that will gain root access via said addon.

In all, anyone that is running XBMC on a box that is exposed to the raw internet is a fool who will soon learn a painful lesson.
Reply
#5
(2014-01-11, 20:29)davilla Wrote: Err, we could fix all bugs, release and the very next day have 10 more bugs 'found'. it's a never ending cycle. so we do the best we can with limited resources.

What we try to do is have the most compatible version of FFMpeg with our patches that matches our internal code for the best playback, decode experience. Given that we allow user installed addons that can access the entire system seems to be a more serious security issue. Crafting a malicious addon is trivial and it's also trivial to install a payload that will gain root access via said addon.

In all, anyone that is running XBMC on a box that is exposed to the raw internet is a fool who will soon learn a painful lesson.

I understand the resource problem. I just say that the cost of upgrading ffmpeg is usually really light and could be done near release point and that keeping external ffmpeg is a good thing for the security aspects. I tested ffmpeg git today and it worked (because they just have fixed a API subtle API breakage in 2.1). I do not understand closing security problem as WONTFIX!

For the addon, they are other software with addons and this can be secured and nobody force you to install unsigned, unverified add-ons.
Reply
#6
(2014-01-11, 20:39)EricV Wrote: I understand the resource problem. I just say that the cost of upgrading ffmpeg is usually really light and could be done near release point and that keeping external ffmpeg is a good thing for the security aspects.


really? where's your PR for doing this for ALL platforms?
sure linux might be easy but you also must do it for iOS, OSX, windows, Android....

and also confirm that our custom patches still work, no regressions and so on.

fyi talk was done to update to 2.0 / 2.1 but since it will be a lot of work it won't be for Gotham.
and closing the ticket as won't fix was just because you simply told us to update to 2.1 ffmpeg or whatever. that's not a bug but a request and some random throwing around with some vague thread about security issues isn't helping either
Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe
Reply
#7
If I remember correctly, you ran arround for some weeks, cause you could not even get xbmc compiled with version 2.1 .... so much about "easy and light" ...
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#8
(2014-01-11, 20:57)fritsch Wrote: If I remember correctly, you ran arround for some weeks, cause you could not even get xbmc compiled with version 2.1 .... so much about "easy and light" ...

Compiling was not the problem. Execution was due to a subtle API breakage for VDPAU. The bug is now fixed in ffmpeg https://ffmpeg.org/trac/ffmpeg/ticket/3133 BUT the proper fix would be for XBMC to use a new ffmpeg 2.1 API and fernetmenta already knows about it.
Reply
#9
The cost of upgrading ffmpeg is very, very heavy. We are multi-plaform. Arm asm can get every tricky on Android/iOS and those platforms are hardly ever 'tested' by FFMpeg gods. The last version bump was painless, the one before that killed iOS platforms with changes in asm/linker code. It took a year to get someone interested in understanding and fixing the issue.

We don't like external ffmpeg, it gets abused and distros don't take the time or do not understand that as a mediacenter we are ver, very sensitive to FFMpeg changes. They toss the most recent version at it, fix compile issues and presto... We run like crap and users flock into the forums complaining.

So, if you want something that works, use our internal FFMpeg. If you want something that is secure but cannot reliably play audio/video content, use external FFMpeg or Libav.

EDIT:
Besides, it's just plain way too late in our current release cycle to bump FFMpeg. We would have to start from scratch again and add 2-3 months for stability testing.
Reply
#10
(2014-01-11, 20:43)Martijn Wrote:
(2014-01-11, 20:39)EricV Wrote: I understand the resource problem. I just say that the cost of upgrading ffmpeg is usually really light and could be done near release point and that keeping external ffmpeg is a good thing for the security aspects.


really? where's your PR for doing this for ALL platforms?
sure linux might be easy but you also must do it for iOS, OSX, windows, Android....

and also confirm that our custom patches still work, no regressions and so on.

fyi talk was done to update to 2.0 / 2.1 but since it will be a lot of work it won't be for Gotham.
and closing the ticket as won't fix was just because you simply told us to update to 2.1 ffmpeg or whatever. that's not a bug but a request and some random throwing around with some vague thread about security issues isn't helping either

I will not argue about the cost for all platform. I'm however curious to know how many lines of patches in the ffmpeg directory for all platforms (can probably do a diff myself)? Releasing gotham with a 9 month old ffmpeg, that is not even an official ffmpeg version but a custom git snaphot and not going to the last official 1.2.4 for example is for me bad policy.

What will you offer with a released gotham when youtube, for 4K, will start proposing H265/HEVC material ?
Reply
#11
(2014-01-11, 21:02)EricV Wrote:
(2014-01-11, 20:57)fritsch Wrote: If I remember correctly, you ran arround for some weeks, cause you could not even get xbmc compiled with version 2.1 .... so much about "easy and light" ...

Compiling was not the problem. Execution was due to a subtle API breakage for VDPAU. The bug is now fixed in ffmpeg https://ffmpeg.org/trac/ffmpeg/ticket/3133 BUT the proper fix would be for XBMC to use a new ffmpeg 2.1 API and fernetmenta already knows about it.

qed
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#12
(2014-01-11, 20:03)EricV Wrote: You pretend none of the bug listed in the links above are in XBMC internal ffmpeg? Fine. I pretend you did not read the article nor the ffmpeg git changelog or the ffmpeg security link and just demonstrate the lack of security awareness of some members.

I do use external ffmpeg so I'm not affected by most of the the security issues. However, preventing me to do this by forcing me:
1) to use an outdated version of ffmpeg by supporting only internal version,
2) or closing bugs solely on the fact hat exetyrenal ffmpeg is not supported
is just getting on y nerves. I do not choose to have my internal copy of a widely available program. XBMC dev did, but forget the security implications of it.

You are assuming too much and actually didnt check that

1) Im not pretending anything, there are bugs for sure (in everything), even in ffmep 2.1, pretending that you actually understand any of it by making absurd claims is not something you want to do in public.
2) A Article by Google does not make for any absolute in making informed decisions about anything, if anything it makes me more suspicious and in need to actually have independent security assessment made by various parties

You go on the defensive and make presumptions and assumptions, without properly considering the implication of your judgement or your comments which are a best inflammatory and insulting.

Some facts about your post...

Code:
[quote='EricV' pid='1597357' dateline='1389461390']
The debate of using internal ffmpeg code versus external ffmpeg one is not new and XBMC devs have made it clear they have no intend to support external ffmpeg.

However, in light of new post about security problem [url]http://googleonlinesecurity.blogspot.com.au/2014/01/ffmpeg-and-thousand-fixes.html[/url] and [url]http://http://ffmpeg.org/security.html[/url]user and packagers should be warned that by using XBMC with internal ffmpeg code, they will put their system at risk because the bugs that have been discovered and fixed in upstream are still in XBMC internal ffmpeg code.

Worse, opening bugs for gotham related to this particular security issues have been purely closed as WONT FIX meaning security issues are deemed not important:[url]http://http://trac.xbmc.org/ticket/14838[/url] In addition while it was possible to use external ffmpeg code, devs intend to drop this feature without clearly indicating that they will make effort to stay current with ffmpeg code.

I really do not understand the rationale behind such move and closing security bug as WONTFIX is for me a bad practice.
[/quote]

link http://http//ffmpeg.org/security.html goes nowhere of consequence it has double http:. You meant to link to http://ffmpeg.org/security.html but ok everyone makes mistakes...
link http://http//trac.xbmc.org/ticket/14838 again double http its now obvious you are even unable to copy and paste, never mind make a valid argument.

SowWithout making any assumptions about your target audience e.g. other users like me--- my observation on this is that you are deeply oblivious drunk/ half asleep or on drugs, and even if you had a valid point you lost the argument when you clicked POST THREAD without actually bothering to do proper research.

I will agree that security issues exist, not just in ffmpeg, bt in even the OS we use, the security software we use to protect us and most of them you dont have access to source code.

Ya... you got on my nerves by insulting me with the very reply which insinuates Im am pretending anything.
Reply
#13
Quote:Compiling was not the problem. Execution was due to a subtle API breakage for VDPAU. The bug is now fixed in ffmpeg https://ffmpeg.org/trac/ffmpeg/ticket/3133 BUT the proper fix would be for XBMC to use a new ffmpeg 2.1 API and fernetmenta already knows about it.

Don't overestimate yourself in that game. Telling devs what they should do is definitely not your job. And in the same moment mentioning a software version that absolutely no one of the big three distributions has in its repositories ...
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#14
Thats enough. Let it go.
Reply
#15
(2014-01-11, 21:17)EricV Wrote: Releasing gotham with a 9 month old ffmpeg, that is not even an official ffmpeg version but a custom git snaphot and not going to the last official 1.2.4 for example is for me bad policy.
Uninformed statements like that doesn't help your argument.

XBMC never use git snaphots of ffmpeg as we only ever use released stable versions of ffmpeg, the current internal version of 1.2 was the latest stable version that was available at the time ffmpeg was last bumped.
Reply
  • 1(current)
  • 2
  • 3
  • 4
  • 5
  • 7

Logout Mark Read Team Forum Stats Members Help
Known security risk unresolved for gotham due to obsolete internal ffmpeg code2