5 ms·

That screenshots doesn't really prove anything. I mean....i can't even tell is it's the latest vlc version. Anyway....interesting debate about statically linke

That screenshots doesn't really prove anything. I mean....i can't even tell is it's the latest vlc version. Anyway....interesting debate about statically linked libraries. Seems like the original vulnerability was in ffmpeg (vlc statically links to it). So in this case what should/can videolan do ?

maaaats 13y ago
One can argue that for a user it doesn't matter if it's ffmpeg, VLC or something else that's buggy. A user is installing VLC, has probably no knowledge of what ffmpeg is, and it's the use of VLC that exposes the user to the security bug. As such, it's VLC responsibility to not ship a product that may harm a user's computer, even if the error is not in their code.
- PhantomLobe 13y ago
  > A user is installing VLC, has probably no knowledge of what ffmpeg is, and it's the use of VLC that exposes the user to the security bug. A user that won't care about that will neither care about Secunia.
- jbk 13y ago
  All the known vulnerabilities have been fixed. Which one are you referring to?
  - maaaats 13y ago
    None in particular, just the general concept that you are responsible for all the parts in the end product, even if not made by you.
    - jbk 13y ago
      Oh, yes, we agree on that. Which is why we patched FFmpeg for the SWF issue.
iuguy 13y ago
Videolan should fix the bug. Secunia should report the bug to ffmpeg. If the bug's fixed by a later version of ffmpeg then great, use a later version. If it's not, fix the bug, wait for ffmpeg to have a fixed update and off you go. To give you a similar example, have a look at this post about the impact of vulnerabilities in third party libraries on commercial forensic products[1]. I would suspect that expert witnesses relying on this could have a case argued against them in court regarding the integrity of the application data and their processes if they're not prepared. [1] - https://www.cert.org/blogs/certcc/2013/07/forensics_software_and_oracle.html https://www.cert.org/blogs/certcc/2013/07/forensics_software...
- jbk 13y ago
  > Videolan should fix the bug. All the vulnerabilities have been fixed. Which one are you referring to?
  - iuguy 13y ago
    The parent's question was: > Seems like the original vulnerability was in ffmpeg (vlc statically links to it). So in this case what should/can videolan do ? I responded to the question. But to answer yours: > Which one are you referring to? Specifically the ffmpeg bug that Secunia reported that you claimed to fix, which wasn't quite correctly fixed, when you decided to go and stir up drama on the Internet and threaten Secunia with lawyers you don't have and can't afford. That one. And that it's fixed now is irrelevant. You made a dick move by threatening legal action without having anything to back it up and it's cost you a lot of goodwill no doubt by stirring it up.
    - brigade 13y ago
      You're missing a couple steps in your timeline, specifically that the bug was fixed before Secunia's public disclosure, then Secunia ignored said fix, then claimed it wasn't fixed but provided no proof, then ignored VLC for months while claiming them to be uncooperative. Only then do they stir up this drama in a final attempt to get Secunia to either back up their claims or acknowledge their mistakes. Thus far Secunia has done neither.
jbk 13y ago
The issue on the screenshot is an unhandled exception in the MKV plugin of VLC. It should not be exploitable, and has already been patched in months.

maaaats 13y ago

One can argue that for a user it doesn't matter if it's ffmpeg, VLC or something else that's buggy. A user is installing VLC, has probably no knowledge of what ffmpeg is, and it's the use of VLC that exposes the user to the security bug. As such, it's VLC responsibility to not ship a product that may harm a user's computer, even if the error is not in their code.

PhantomLobe 13y ago
> A user is installing VLC, has probably no knowledge of what ffmpeg is, and it's the use of VLC that exposes the user to the security bug. A user that won't care about that will neither care about Secunia.
jbk 13y ago
All the known vulnerabilities have been fixed. Which one are you referring to?
- maaaats 13y ago
  None in particular, just the general concept that you are responsible for all the parts in the end product, even if not made by you.
  - jbk 13y ago
    Oh, yes, we agree on that. Which is why we patched FFmpeg for the SWF issue.

iuguy 13y ago

Videolan should fix the bug. Secunia should report the bug to ffmpeg. If the bug's fixed by a later version of ffmpeg then great, use a later version. If it's not, fix the bug, wait for ffmpeg to have a fixed update and off you go. To give you a similar example, have a look at this post about the impact of vulnerabilities in third party libraries on commercial forensic products[1]. I would suspect that expert witnesses relying on this could have a case argued against them in court regarding the integrity of the application data and their processes if they're not prepared. [1] - https://www.cert.org/blogs/certcc/2013/07/forensics_software_and_oracle.html https://www.cert.org/blogs/certcc/2013/07/forensics_software...

jbk 13y ago
> Videolan should fix the bug. All the vulnerabilities have been fixed. Which one are you referring to?
- iuguy 13y ago
  The parent's question was: > Seems like the original vulnerability was in ffmpeg (vlc statically links to it). So in this case what should/can videolan do ? I responded to the question. But to answer yours: > Which one are you referring to? Specifically the ffmpeg bug that Secunia reported that you claimed to fix, which wasn't quite correctly fixed, when you decided to go and stir up drama on the Internet and threaten Secunia with lawyers you don't have and can't afford. That one. And that it's fixed now is irrelevant. You made a dick move by threatening legal action without having anything to back it up and it's cost you a lot of goodwill no doubt by stirring it up.
  - brigade 13y ago
    You're missing a couple steps in your timeline, specifically that the bug was fixed before Secunia's public disclosure, then Secunia ignored said fix, then claimed it wasn't fixed but provided no proof, then ignored VLC for months while claiming them to be uncooperative. Only then do they stir up this drama in a final attempt to get Secunia to either back up their claims or acknowledge their mistakes. Thus far Secunia has done neither.

jbk 13y ago

The issue on the screenshot is an unhandled exception in the MKV plugin of VLC. It should not be exploitable, and has already been patched in months.