Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FFmpeg dealing with a security researcher

twitter.com

Post reply on HN
Print view View original

161–170 of 174 posts

Re: FFmpeg dealing with a security researcher

#161

Post by 63stack »

bawolff wrote: post #137
leoedin wrote: post #86

Earlier quoted context omitted.

> The person who makes the software has the duty to fix the security issues in their own code, nobody else, no matter how big they are. That’s just clearly untrue for freely available software. So every person that ever published a hobby project on GitHub has a duty to fix security issues in it? The organisation who ships software to paying customer may have a duty to fix security issues. If they didn’t, it could be…

> That’s just clearly untrue for freely available software. So every person that ever published a hobby project on GitHub has a duty to fix security issues in it? Yes, i think there is a moral duty if you are presenting the software for the general public to use. Or if you dont to at least make it clear how you handle stuff so that users can make their own decisions. > But there’s no contract with the free software d…

Software licenses already make the conditions íj which they are offered to you very clear.

It is up to you, the end user of the software to evaluate whether those terms, risks, and options are good enough for you. If not, don't use it. You have it completely backwards, and frankly, sound quite entitled.

Re: FFmpeg dealing with a security researcher

#162

Post by hitekker »

mappu wrote: post #159
hitekker wrote: post #80

Earlier quoted context omitted.

I'm not sure if Kostya's account is truthful. He has a huge axe to grind against ffmpeg https://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html IIRC, his "LibAV" fork was malicious and his people lied a lot to the community ("ffmpeg is now deprecated!"). Ultimately, they failed, but I see a lot of their rhetoric and resentment in Kostya's post today.

This isn't my place to argue, and certainly he was involved at the time, but LibAV wasn't really "his fork". Reading the full list of names who signed off https://lwn.net/Articles/423703/ I'm more interested in some other names, including darkshikari's deadname and the other heavy hitters of x264. And if you browse through the ffmpeg mailing list of that historic month https://ffmpeg.org/pipermail/ffmpeg-devel/2011-J…

Kostya fanned the flames https://codecs.multimedia.cx/2011/10/why-ffmpeg-is-better-th... As for "his" ownership, I think LibAV was a failure each team member should own and comes to terms with.

That's my point and also why I won't dig more. The author hasn't come to terms with his bad experience with ffmpeg, in LibAV or otherwise. Whatever the baggage is, it feels quite messy and heavy. It weighs down the article, with too much bitterness and resentment. That could work for self-therapy, less so for a credible account. As he confesses at the end:

> I wrote this post with an ulterior motive—I don’t want to feel shame when remembering that I took part in that project. So far though the more I hear about it the more disgusted I become.

Re: FFmpeg dealing with a security researcher

#163

Post by Sophira »

Sophira wrote: post #109
haskellshill wrote: post #41

Earlier quoted context omitted.

VLC is pretty popular on windows, but ffmpeg? Is there any commonly used windows app that relies on it? I doubt it'd be worth one's time to write exploits for desktop linux

Yes, lots. To name an example, yt-dip uses it on all platforms, including Windows, which means that any video downloader front-end that uses it also uses FFmpeg.

...I mean "yt-dlp", of course. Phone autocorrected >_<

Re: FFmpeg dealing with a security researcher

#164

Post by bawolff »

63stack wrote: post #161
bawolff wrote: post #137

Earlier quoted context omitted.

> That’s just clearly untrue for freely available software. So every person that ever published a hobby project on GitHub has a duty to fix security issues in it? Yes, i think there is a moral duty if you are presenting the software for the general public to use. Or if you dont to at least make it clear how you handle stuff so that users can make their own decisions. > But there’s no contract with the free software d…

Software licenses already make the conditions íj which they are offered to you very clear. It is up to you, the end user of the software to evaluate whether those terms, risks, and options are good enough for you. If not, don't use it. You have it completely backwards, and frankly, sound quite entitled.

Morality and legality are not the same thing.

Although perhaps my previous comment went a little too far. I think its fine to not fix issues as long as you publish them so that users can make an informed decision. Where i think it would be morally wrong is if a project pretends it fixes security issues but doesn't or if it tries to cover them up - insisting external reporters dont talk about them while also having no intention of fixing them.

Basically i think open source projects (like everyone) have a moral duty to be honest and not try and decieve people, regardless of what the license says.

Re: FFmpeg dealing with a security researcher

#165

Post by bawolff »

eipi10_hn wrote: post #153
bawolff wrote: post #143

Earlier quoted context omitted.

By the same token nobody has the duty to responsibly disclose security bugs. The entire premise of responsible disclosure is that security researchers give time for upstream projects to fix security issues by privately reporting the issues, in exchange the maintainers graciously accept the reports. Its a deal that benefits maintainers much more than it benefits researchers. If ffmpeg doesn't want that deal, then goog…

Yes, that's right. Nobody has the duty to disclosure the security bugs. It's the security researchers' principles, and if they want to follow that, they can follow that. But don't take it further that the maintainers have the duty to fix the issues. They choose that career, don't make it sound like ffmpeg is forcing them to disclosure. Maintainers don't "deal" with any security researchers about those, and don't put…

I mean, i agree, ffmpeg are under no obligation to do anything. (In the heat of the moment i think my previous comment went too far, i would phrase it more, as if you want to be a "quality" software project then you have to respond to real security bugs promptly).

My biggest gripe though is that ffmpeg does seem to value these sorts of reports highly. If i'm reading the timestamps right, they fixed this report within 1 day: https://github.com/FFmpeg/FFmpeg/commit/c41a70b6bb79707e1e3a...

How often do you get your bug reports fixed that fast? When i file bugs in open source projects it usually takes at least weeks if im lucky to get a response. People almost never respond within 1 day. I think that demonstrates how valuable ffmpeg views these reports.

If the report was a garbage report (like e.g. the ones the curl maintainer complains about) i'd have more sympathy, but clearly ffmpeg views this issue submission as valuable. The whole thing makes me think of choosing-beggars. They want the google report but also are trying to use social pressure to make google contribute even more.

If they didn't want google's reports that's one thing - just reject them, but both wanting them while also demanding more is scummy in my opinion. Either accept or reject them.

Re: FFmpeg dealing with a security researcher

#166

Post by godelski »

bawolff wrote: post #142
godelski wrote: post #128

Earlier quoted context omitted.

> because they use FFmpeg in a bunch of commercial products like Youtube and Chrome Not to mention they just have a vested interest in getting the problem solved. Even if we don't talk about money. I'm not sure why this is an unpopular idea, but contribute back to your upstream dependencies. If they're a dependency, they're part of * your code* .

> Not to mention they just have a vested interest in getting the problem solved. Even if we don't talk about money. Correct me if im wrong, but based on the report this looks like something that would affect regular users of ffmpeg but not google's use.

FWIW I tried replicating it and didn't get the same result. I end up with a failed conversion, exit code 69[0]. Same thing when I run with my installed version of ffmpeg.

But I think Google would still be concerned. Even if they're running ffmpeg in a sandbox you can escape sandboxes. The sandbox is a security layer, not what makes the thing safe. You should be using it as a layer of defense for unknown vulns, and try to resolve vulns. I mean Google is much more likely to have an attacker trying to chain a vuln with a sandbox escape than the average user.

Btw:

  ffmpeg -codecs | cat | grep SANM 2&>/dev/null
  ffmpeg version n8.0 Copyright (c) 2000-2025 the FFmpeg developers
  ... ffmpeg flags ...
  D.V.L. sanm                 LucasArts SANM/SMUSH video
So my version does have that codec, as others are reporting.

[0] Will expire soon https://0x0.st/KL6K.log

[DISCLOSURE]: I AM NOT A SECURITY PROFESSIONAL. If I am wrong please correct me

Re: FFmpeg dealing with a security researcher

#167

Post by eipi10_hn »

bawolff wrote: post #165
eipi10_hn wrote: post #153

Earlier quoted context omitted.

Yes, that's right. Nobody has the duty to disclosure the security bugs. It's the security researchers' principles, and if they want to follow that, they can follow that. But don't take it further that the maintainers have the duty to fix the issues. They choose that career, don't make it sound like ffmpeg is forcing them to disclosure. Maintainers don't "deal" with any security researchers about those, and don't put…

I mean, i agree, ffmpeg are under no obligation to do anything. (In the heat of the moment i think my previous comment went too far, i would phrase it more, as if you want to be a "quality" software project then you have to respond to real security bugs promptly). My biggest gripe though is that ffmpeg does seem to value these sorts of reports highly. If i'm reading the timestamps right, they fixed this report within…

Nope. Don't mistake a quick fix as they are "valuable" to the maintainers. They said clearly that it's a hobby project and at the most it just simply means that some volunteers were interested and wanted to fix it, or the fix is not complex, and I would just stop at that. The "valuable" is, again, an outsider view that is forced to the maintainers. Same as "They want google report" thing. Just because they fix some issues reported from someones doesn't mean that they view all of those reports being "valuable".

At most, I would just see that they are annoyed by the issue procedures (without PRs) of the "researchers" and they complaint on the social. I don't agree with their complaints because the "researchers" did nothing wrong either. And that's it, I would stop at that. Putting the whole "duty", "valuable reports" and "demand more" on them is just as bs as their complaints.

Re: FFmpeg dealing with a security researcher

#168

Post by bawolff »

eipi10_hn wrote: post #167
bawolff wrote: post #165

Earlier quoted context omitted.

I mean, i agree, ffmpeg are under no obligation to do anything. (In the heat of the moment i think my previous comment went too far, i would phrase it more, as if you want to be a "quality" software project then you have to respond to real security bugs promptly). My biggest gripe though is that ffmpeg does seem to value these sorts of reports highly. If i'm reading the timestamps right, they fixed this report within…

Nope. Don't mistake a quick fix as they are "valuable" to the maintainers. They said clearly that it's a hobby project and at the most it just simply means that some volunteers were interested and wanted to fix it, or the fix is not complex, and I would just stop at that. The "valuable" is, again, an outsider view that is forced to the maintainers. Same as "They want google report" thing. Just because they fix some i…

> volunteers were interested and wanted to fix

If that's not the definition of valuable then what is?

As you said, its a volunteer project. What other metric of value is there other than a volunteer being interested?

Re: FFmpeg dealing with a security researcher

#169

Post by 63stack »

bawolff wrote: post #164
63stack wrote: post #161

Earlier quoted context omitted.

Software licenses already make the conditions íj which they are offered to you very clear. It is up to you, the end user of the software to evaluate whether those terms, risks, and options are good enough for you. If not, don't use it. You have it completely backwards, and frankly, sound quite entitled.

Morality and legality are not the same thing. Although perhaps my previous comment went a little too far. I think its fine to not fix issues as long as you publish them so that users can make an informed decision. Where i think it would be morally wrong is if a project pretends it fixes security issues but doesn't or if it tries to cover them up - insisting external reporters dont talk about them while also having no…

You make it sound like this is a common problem in open source projects, like they are trying to cover up existing issues, or claiming they are fixing security issues when they are actually ignoring. Do you think this is the case? Can you name a few projects where you noticed this?

Re: FFmpeg dealing with a security researcher

#170

Post by ValdikSS »

ls612 wrote: post #149
IshKebab wrote: post #139

Earlier quoted context omitted.

Really ? You think trackers download files and analyse their contents before listing them? I don't.

TPB? No. But 1337 and rutracker definitely do basic quality control. Nothing like a private tracker but they take down things like .mkv.lnk and similar.

You can report viruses on TPB's forum, there's usually entire accounts which upload viruses which are easy to find.
Post reply on HN