_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
HTML Visit Hacker News on the Web
COMMENT PAGE FOR:
HTML Twenty One Zero-Days in FFmpeg
techscruggs wrote 7 hours 2 min ago:
The incentives structure is deeply broken in the field of Security
Research.
They are the middle management of the FOSS world.
Celebrated for dumping more work on volunteers. The more urgent the
work, the more they are celebrated. Acknowledging the realistic impact
of issues or the pragmatic implications of an issue are at odds with
their incentives.
It's hard not to see them as bottom feeders of the software industry
and I wish we would starting treating them like pariah. Submit the PR
or STFU.
codedokode wrote 9 hours 36 min ago:
> DFVULN-123 (Integer Overflow): In the RTP LATM depacketizer
(rtpdec_latm.c), latm_parse_packet() performs a signed 32-bit addition
that overflows and bypasses its bounds check
Again there is another vulnerability caused by unchecked addition, and
still modern languages like Rust or Go do not raise exception on
overflow, and modern CPU architectures like RISC-V provide no overflow
traps. And older languages like C or C++ do not have overflow checks
also.
Ridiculous. It is obvious that humans cannot be trusted with writing
correct arithmetics code.
heinrich5991 wrote 7 hours 53 min ago:
Rust enables overflow checking in debug mode, you can (and I do)
enable it in release mode as well.
Rust's default integer overflow in release mode is defined as well,
it'll just wrap around. This makes it less likely to result in a
vulnerability (unless you start writing unsafe Rust).
zahlman wrote 5 hours 7 min ago:
... do `unsafe {}` blocks not have the same semantics? I thought
that was only about memory safety. Or are you thinking of cases
where a wrapped-around integer gets interpreted as a pointer or
something?
steveklabnik wrote 3 hours 59 min ago:
unsafe never changes the semantics of anything. Unsafe gives you
access to additional features, never changes the meaning of a
feature.
pornel wrote 7 hours 34 min ago:
Additionally, integer overflow is less immediately dangerous in
Rust, because buffer access is bounds-checked after the arithmetic.
You can still get some logic bugs that eventually lead to
vulnerabilities, but it's not an arbitrary memory write gadget.
uecker wrote 7 hours 15 min ago:
What convinced me that this is wishful thinking was
CVE-2023-53156. Yes, it used "unsafe" but the wraparound in
release defeated the manual check, and when you aim for
performance comparable to C, Rust tends to be full of unsafe
blocks.
IMHO better C tooling would be a far better investment than
rewriting in Rust.
AlienRobot wrote 9 hours 6 min ago:
Zig raises overflow. There are +|= and +%= operators for clamped and
wrapping addition.
Rust doesn't raise overflow by default. But you can just
123.checked_add(321). Now your code is unreadable, but it's overflow
safe.
Honestly, based on the way I write code I'd rather something like an
end of line comment. Like:
var x = y + z; # wrapped
Because I'm very unlikely to mix wrapped/checked/clamped arithmetic
in a single line. It can't be a compiler state like doing(wrapped) {
x + y } because in Zig every line must be "compilable" by itself,
without requiring context from other parts of the code. Function
names are too verbose. Casting is too verbose. Having a
statement-level modifier would be a good compromise.
codedokode wrote 5 hours 11 min ago:
Nobody is going to write "checked_add" because that's too long and
people are too lazy. The checked addition should be "+" operator.
zahlman wrote 5 hours 5 min ago:
Agreed, the option that sacrifices security in search of
performance should be the more verbose one. There's a reason Rust
doesn't have `safe {}` blocks and there's a reason it chose
immutable-by-default semantics.
deafpolygon wrote 11 hours 0 min ago:
I just had an unsettling thought⦠those with access to Mythos/Fable
finding these flaws â how many might be holding back and keeping some
of these exploits in their back pocket?
guessmyname wrote 14 hours 32 min ago:
I think the industry is optimizing for the wrong thing. Generating
thousands of AI-written bug reports is easy, at least with Mythos
(preview 1) or GPT-5.5. Getting bugs fixed is the hard part.
A few months ago I started working on a system that finds critical
security issues and opens PRs instead of just filing reports. The
acceptance rate is sitting at roughly 94% so far. Most of the failures
were due to project-specific kill switches or other internal mechanisms
that werenât documented, not because the vulnerability itself was
misidentified.
Developers generally seem to prefer this approach. A bug report creates
work. A good PR removes work. That sounds obvious, but a lot of
security products still stop at the report and call it a day.
Rygian wrote 12 hours 35 min ago:
> I think the industry is optimizing for the wrong thing.
Indeed: The industry optimizes for speed, time to market, and
features, and applies the ostrich model to everything that doesn't
bring short-time revenue (security considerations, accessibility,
vendor lock-in, interoperability, â¦)
This has been going on for as long as the industry exists, and now we
start to have the proper tools to assess the damage and understand
the brittleness of it all.
rcbdev wrote 14 hours 25 min ago:
I think I'm missing something here. Apple software has no open source
code, how are you suggesting fixes?
tkocmathla wrote 14 hours 19 min ago:
What?
HTML [1]: https://github.com/apple
dgellow wrote 8 hours 21 min ago:
Also, check
HTML [1]: https://opensource.apple.com/projects/
rcbdev wrote 14 hours 12 min ago:
I genuinely didn't know about their OSS efforts, thanks!
Thev00d00 wrote 12 hours 59 min ago:
I wouldn't go so far as efforts, so much as legally required
publication of 3rd party code they use, or open wrappers to
their proprietary libraries
mort96 wrote 5 hours 23 min ago:
Or .. their operating system and kernels
appleappleapple wrote 17 hours 19 min ago:
Help me understand: depthfirst seems to be bigging up their âsecurity
agentâ here, but is it not just prompt engineering + writing skill
files? What goes into producing a âsecurity agentâ beyond this?
Feels like theyâre really gussying up a process that is ultimately
just LLM usage
0xbadcafebee wrote 18 hours 0 min ago:
Even if this isn't as big a deal as this [advertisement for a security
company] seems, it is a reminder that every application you release
does have a security hole somewhere, and a script kiddie can now find
it 5 minutes after release for $2 in credit. If you're not red-teaming
your code before release, hackers are doing it after.
kodt wrote 18 hours 14 min ago:
Infinity - 21 is still infinity
tom_ wrote 19 hours 4 min ago:
> A victim only has to run ffmpeg -i rtsp://attacker/stream, the most
ordinary command imaginable
What about "ls"?
throwaway2037 wrote 9 hours 37 min ago:
I had to read your comment a couple of times to understand it. I
assume you are saying that "/bin/ls" is the "most ordinary command
imaginable"? I think your original quote is saying most ordinary
when running ffmpeg, which has a famously complex command line
interface.
lschueller wrote 19 hours 15 min ago:
Inflated use of the term zero-day, while none of the described
vulnerabilities is actually a zero-day. But it sounds and clicks good..
thank you for the PoC.
da_chicken wrote 19 hours 40 min ago:
That's not what "zero-day" means.
journal wrote 12 hours 38 min ago:
Explain what it means along with your statement. Maybe I have the
wrong definition too.
perlgeek wrote 12 hours 23 min ago:
(not op)
If a security bug is exploited in the wild, it's an n-day if it's
been first exploited n days after the publication of the bug, and a
zero-day if it's been exploited before or on the day of the
publication.
When a bug is not yet exploited in the wild, it's just a discovery
of a bug, not a zero-day.
dingaling wrote 6 hours 55 min ago:
Even that's revisionist.
Originally a zero-day exploit was one that was found by crackers
on the first day of release of a software product. Like finding
a licence crack for a new Microsoft program on the day it went on
sale.
There used to be fierce competition to find such an exploit
within those 24 hours, and great kudos for those who did.
Nowadays a zero-day can apparently be found years after release,
which makes no sense.
AlienRobot wrote 9 hours 0 min ago:
Does "publication" refer to the software or to something
documenting the existence of the bug? Because I thought zero-day
meant the bug was exploited the same day the software containing
the bug was released, but your phrasing sounds like if you
exploit a bug before the maintainers know about it then it's a
negative day.
nerdsniper wrote 19 hours 14 min ago:
It seems to have lost its meaning after getting popularized following
Stuxnet coverage.
da_chicken wrote 18 hours 46 min ago:
No, I think it was since Code Red.
I understand why it's poorly understood. It's a snappy term, and
people assume it means "bad" and nothing else because that's all
you can get from the context. However, since most people also don't
know the difference between a vulnerability and an exploit, they
won't understand the definition of a zero-day when they read it.
But I'm still going to complain if a security vulnerability
research company is using the term incorrectly in their own press
copy. It makes them look amateurish.
NooneAtAll3 wrote 17 hours 24 min ago:
> the difference between a vulnerability and an exploit
is it the difference between a knife and a stab wound?
da_chicken wrote 15 hours 23 min ago:
No, that's the difference between exploit (knife) and either
the incident or impact (wound). The vulnerability would be a
gap in armor.
The vulnerability is the exposed weakness. Vulnerabilities get
fixes, and they exist without anybody knowing about them.
Vulnerabilities get CVEs assigned to them.
The exploit is the means of attack. It's the specific actions
or calls that let you take advantage of a vulnerability. It
could be a worm, or botnet scripts, or specifically crafted
data[0]. A proof of concept is not an exploit itself, but it
demonstrates that the vulnerability can be exploited.
An example of a vulnerability might be a gate where the gap
between the door and the jam are too wide. The exploit is a
coat hanger used to lift the inside latch from outside the
gate. That results in unprivileged access.
And zero-day specifically compares when the white hats
(vendors, system owners) and the black hats learn about the
existence of a vulnerability. If white hats learn that a
vulnerability exists by being subject to an in-the-wild black
hat exploit of it, then it's a true zero-day.
[0]:
HTML [1]: https://xkcd.com/327/
Philpax wrote 19 hours 52 min ago:
"No way to prevent this" say users of only language where this
regularly happens, etc, etc. Several of these bugs do not appear to be
in hot code and would have been detected by a language with saner
behaviour.
izacus wrote 12 hours 50 min ago:
Well, get to work then and rewrite, should be quick. Chop-chop!
omoikane wrote 20 hours 6 min ago:
Is there a timeline for each of these bugs? I wonder if these bugs had
been reported to ffmpeg yet.
bayouborne wrote 20 hours 8 min ago:
What about VLC's own built-in versions of decoding libraries (I think,
from the FFmpeg project)? Is there a scenario here where we may have to
deal with malicious MP4 files?
jeffbee wrote 19 hours 8 min ago:
All media containers are potentially hostile. Any offset, extent, or
reference has to be considered hostile user-provided input.
zerobees wrote 20 hours 16 min ago:
Ffmpeg has an exceptionally terrible track record when it comes to
security. People have been throwing fuzzers at it for as long as I
remember and coming back with a nearly inexhaustible supply of memory
corruption bugs. Here's an effort by one Googler a decade ago: [1] So,
while it's a demo of the capabilities of LLMs, this should not be at
all surprising. Ffmpeg is absolutely not something you should be
running outside of a sandbox if you're touching any untrusted or
user-supplied content. I know that people do, and these people are
taking unreasonable risks.
HTML [1]: https://security.googleblog.com/2014/01/ffmpeg-and-thousand-fi...
preg_match wrote 2 hours 16 min ago:
FFmpeg is extremely complex software, with an extreme (and necessary)
focus on performance, that exists in an extremely complex domain.
Itâs not just FFmpeg. Apple has had more vulnerabilities in image
and video decoders than I can count. That stuff is just very hard,
and FFmpeg is doing more than anyone else.
mr_toad wrote 5 hours 27 min ago:
The difficulty in exploiting ffmpeg is getting anyone to use it on
your input. Sure, you might pwn a few people, but is it worth the
effort?
hahn-kev wrote 9 hours 3 min ago:
I use it in WASM on the client and call it a day. It works for our
use case, but obviously not most.
jstanley wrote 11 hours 10 min ago:
Some of the ffmpeg developers were on Lex Fridman's podcast recently,
and the topic of security came up.
They were talking about how there was a vulnerability in an extremely
niche codec that is only used for one video game from the 90s or
something, and were saying that the person who reported the
vulnerability was acting like it was a big deal but it's really not
because this codec is hardly ever used.
I was left wondering whether they were oblivious to the fact that an
attacker who can supply a video file to you is free to use whatever
video codec they want? It wouldn't matter if the developers thought
the codec was never used at all; if it is still available then an
attacker can use it.
Or was I just missing something? Is there a good reason why
vulnerabilities in this codec are not a big deal after all?
franga2000 wrote 10 hours 9 min ago:
The user is not free to use whatever codec they want. Many niche
codecs can't be put into the usual containers, so if you only
accept QuickTime/MP4 and AVI, sometimes even just by limiting the
file extension, those codecs can't be used.
If your service works by taking whatever file the user gives you
and shoving it into unsandboxed ffmpeg, you've already fucked up.
It would be nice if you could do that, but that's not a guarantee
ffmpeg has ever provided, nor would it make sense for them to spend
their limited resources on it.
RetroTechie wrote 8 hours 12 min ago:
> If your service works by taking whatever file the user gives
you and shoving it into unsandboxed ffmpeg, you've already fucked
up.
Isn't that what fuzzing and input validation is about? Most bugs
presented in article suggest failures in the latter.
m4rtink wrote 10 hours 59 min ago:
Is it really available in practice ? Eg. do major distros even
compile ffmpeg with these obscure codecs or you need to recompile
it yourself to get it ?
TD-Linux wrote 1 hour 19 min ago:
Yes. The default ffmpeg build enables everything, and most
distros follow suit. Security conscious web services generally
disable a lot of them, but there is no official list on which are
considered more secure than others, so every site tends to have
its own unique mix.
defrost wrote 11 hours 6 min ago:
Big pipeline fat data users of ffmpeg can and do build their own
executables that only include the top N codecs, that eliminates
minor bug in obscure never used format problems pretty thoroughly.
imjonse wrote 11 hours 49 min ago:
The obvious question is, how many of those were the sort that writing
in a memory-safe language would make impossible?
They should prompt one of the more adventurous LLMs to find security
bugs and with some luck it will deviate from the prompt and rewrite
ffmpeg in Rust.
lionkor wrote 11 hours 16 min ago:
Rewriting ffmpeg in Rust will not solve it. The parts that are
memory unsafe in ffmpeg, and similar projects, are not unsafe
because C or C++ is inherently unsafe. Instead, it's the CODE that
is unsafe. Translating the code (data structures, logic, etc) to
Rust does not fix bugs in the code. That code will be littered with
"unsafe" code, and of course, it will no longer be maintainable.
simjnd wrote 11 hours 56 min ago:
FFMPEG has consistently expressed their frustration with the fact
that there is a large number of people willing and eager to publish
vulnerabilities found in the project, but a comparatively minuscule
number of people willing to work on patches to fix them.
LegionMammal978 wrote 9 hours 3 min ago:
On the other hand, there's been an endless parade of recent posts
from other FOSS maintainers saying "we don't want your drive-by
PRs": it's not hard to see people getting dissuaded from the whole
dance of determining whether a project is receptive at all, then
whether it has a reasonable number of hoops for outsiders to jump
through.
Now, personally, when I file a bug report for a FOSS project I like
to suggest an underlying cause and fix if I can figure it out, but
I more rarely just submit a PR outright.
xboxnolifes wrote 4 hours 50 min ago:
There is a different dynamic between this and that.
sph wrote 5 hours 31 min ago:
On the third hand, pestering and shaming open-source maintainers
because they don't accept your PR is how you get the XZ backdoor
situation.
ftchd wrote 7 hours 53 min ago:
If I have to choose between no PR and a "drive-by PR" where the
author doesn't understand the changes to have a discussion, or
isn't available to do changes and expects me to "take it from
there", then I'd much rather go with "no PR" for the sake of
everyone.
codedokode wrote 10 hours 5 min ago:
If there are so many vulnerabilities, should not they change
approach to development, for example, use memory-safe languages,
static analysis, do not use dubious "hacks" that break it?
ivanjermakov wrote 9 hours 54 min ago:
Memory safety and critical performance rarely go together. Big
chunk of FFmpeg is written in assembly to sqweeze most hardware
performance.
HTML [1]: https://news.ycombinator.com/item?id=43140614
IshKebab wrote 7 hours 19 min ago:
Sure but it seems like most of these vulnerabilities are being
found in the C code.
cryo32 wrote 10 hours 3 min ago:
No. They tried that with coreutils and look what happened. More
CVEs.
99% of what I throw though ffmpeg is trusted i.e. I created it.
Itâs not a major risk.
acdha wrote 9 hours 23 min ago:
coreutils was a category error: they took a set of tools which
were not very exposed to memory safety errors and rewrote them
in a language which does nothing to prevent the kind of logic
errors coreutils has suffered from (mostly races around file
operations). Itâs like complaining that an airbag didnât
save you after driving into a lake.
In contrast, ffmpeg is exactly the sweet spot for a memory-safe
language with those complex decoders operating on data which is
often untrusted. I wouldnât suggest a project of that scale
lightly but itâs at least a near-perfect fit on the problem
domain.
IshKebab wrote 7 hours 16 min ago:
Rust does not do "nothing" to prevent logic errors. On the
contrary, its strong type system makes them much less likely
than in C.
Also security isn't the only reason to prefer Rust to C.
But I do agree ffmpeg would see a much bigger benefit from
being written in Rust.
anoneng wrote 8 hours 35 min ago:
I would say itâs the opposite. coreutils is core utils, you
cannot write shell scripts without them, they are widely and
almost unavoidably used in trusted environments. They are
also relatively simple.
With ffmpeg, anyone who knows anything about secure
application development in the past 20 years knows that it is
a huge security tarpit and throwing it untrusted inputs in
trusted environment is asking to be owned. You thoroughly
sandbox that shit. Thatâs true for all untrusted media
conversion, but absolutely with ffmpeg.
zahlman wrote 5 hours 10 min ago:
> you cannot write shell scripts without them, they are
widely and almost unavoidably used in trusted environments.
True.
That doesn't make them "very exposed to memory safety
errors".
krageon wrote 8 hours 52 min ago:
The coreutils rewrite was shit because of the license change.
Most of the other founding ideas were also bad as you say,
but the license change was absolutely a much worse signal.
Just a bunch of people rolling over and showing big corps
their belly. And for what? So they can be more exploited by
people that treat them like cattle.
codedokode wrote 9 hours 28 min ago:
In case with coreutils, as I remember, there were mostly race
conditions. Not memory safety issues. Maybe we just need better
I/O libraries.
uecker wrote 7 hours 11 min ago:
Or use a buffer abstraction in C. This is not exactly rocket
science. The "this is impossible to prevent in C" nonsense
does far more harm than good.
shermantanktop wrote 3 hours 17 min ago:
Errors are easily found and corrected for a modest
one-person project in C.
But weâre combining probability of error creation (which
is effectively constant) and the limits of human cognition.
Some things are impossible at one scale, become possible at
another, and become inevitable at yet another.
codedokode wrote 5 hours 9 min ago:
To be fair, C is a pain to use, so it is better to improve
Rust. It is annoying when for example, you have to free
several allocated structures when there is an error in the
middle of a functon.
uecker wrote 4 hours 31 min ago:
I personally like to use C and find Rust annoyingly
complex. I think it may be an alternative to C++, but C++
is also too complex for my taste. I do not find it
annoying to free several allocated structures when there
is an error, but one could also automate this with a
often used extension.
There is also the question whether trading memory safety
against supply chain risks is really worth it.
teravor wrote 13 hours 22 min ago:
while sandboxing ffmpeg directly isn't difficult, unfortunately with
something like MPV/VLC that uses ffmpeg it's more challenging. until
recently (virtio gpu native context) it wasn't even possible to
sandbox a video player without losing all hardware acceleration. at
least not from the outside, they could always try to sequester ffmpeg
and seccomp it to hell like chromium.
BoingBoomTschak wrote 7 hours 57 min ago:
Sandboxing not only OS access but also hardware access feels almost
impossible to be honest. At least not via user-friendly exec based
stuff like bwrap.
Personally, I still try to contain them a bit:
HTML [1]: https://git.sr.ht/~q3cpma/ezbwrap/tree/master/item/profile...
endofreach wrote 14 hours 19 min ago:
Of course. Everybody knows to rather use the obvious alternative to
ffmpeg!
dspillett wrote 8 hours 29 min ago:
> the obvious alternative to ffmpeg
IIRC that is currently sandboxed ffmpeg.
Until the people going on about making an equivalent in pure rust
being automatically much safer, stop talking about it and actually
get on with making it, of course!
bitwize wrote 14 hours 47 min ago:
Time to RIIR, then?
anonymousiam wrote 14 hours 36 min ago:
I haven't seen that acronym before, but my guess is that it's
"Re-Implement In Rust", right?
erk__ wrote 14 hours 20 min ago:
Usually it's Rewrite it in Rust, but both work I guess
cubefox wrote 15 hours 43 min ago:
> Ffmpeg is absolutely not something you should be running outside of
a sandbox if you're touching any untrusted or user-supplied content.
You would change your opinion quickly if your browser, apps and TV
suddenly stopped supporting videos due to relying on FFmpeg.
defrost wrote 15 hours 36 min ago:
What prevents running a data stream in, transcoded data out sandbox
with no access to unlimited resources, system files, system
stacks, etc.
It's okay for a sandbox to fall over due to bad inputs and poor
memory security if it can just be restarted and move onto other
streams.
mr_toad wrote 5 hours 16 min ago:
Most of them require hardware acceleration from the CPU or GPU
and that can potentially be exploited to escape the sandbox.
GPUs in particular are difficult to sandbox.
ReactiveJelly wrote 14 hours 29 min ago:
I think Chromium already does sandbox ffmpeg in the renderer
process because of their "Rule of Two": [1] Thus:
1. Code which processes untrusted input
2. Code written in unsafe languages like C or C++
3. Code that runs without a sandbox
So ffmpeg should be sandboxed, same as the network code and GPU
process are sandboxed.
HTML [1]: https://chromium.googlesource.com/chromium/src/+/HEAD/do...
defrost wrote 14 hours 21 min ago:
I completely agree, with regard for the GP's point about
Android TV's with onboard ffmpeg libraries and Addon Apps that
call on said libraries (or pull in their own) ..
Cheap arse low resource TVs should either include some form of
sandboxing OR the entire device should be treated as a "can
fall over" sandbox .. well isolated from any household LAN of
consequence, etc.
It seems unlikely that BoxStore Brand Android TVs will be well
designed with an eye to security so they're an exercise for
home net admin masochists and/or an opportunity to market
sensible easy to use IoT age routers that come preconfigured to
handle bad-device(s).
cubefox wrote 13 hours 40 min ago:
Am I getting this right, you expect TVs which are running
Google TV (Android TV is the old name) to be less secure than
TVs which are running a different operating system? I think
the opposite is the case, because Google TV is developed by
Google, which has a lot of experience with software security,
while other TV operating systems are developed by companies
which clearly don't have that experience.
defrost wrote 13 hours 11 min ago:
There are a lot of "Android like" TVs out there.
cubefox wrote 11 hours 58 min ago:
Those are running mainly on Google TV. Tizen or webOS are
also common but are not based on Android.
anon-3988 wrote 16 hours 36 min ago:
Doesn't this negate all the amazing muh assembly hacking that they do
lol
oinoom wrote 16 hours 49 min ago:
Funny, John Carmack was just admiring the creator of ffmpeg the other
day for being a better programmer.
HTML [1]: https://x.com/id_aa_carmack/status/2064095424420487226?s=46
mjg59 wrote 13 hours 24 min ago:
The majority of code in ffmpeg today isn't written by Fabrice, but
also there's multiple axes that people view programming ability on.
Some people can write software that will do things you couldn't
imagine given the constraints. Some people can write software that
is resilient against all malformed input. Sometimes these people
are the same people, but frequently they're not.
wavemode wrote 16 hours 2 min ago:
Security vulnerabilities are less about programming ability and
more about rigor.
tptacek wrote 16 hours 43 min ago:
One thing has nothing to do with the other.
nerdsniper wrote 19 hours 15 min ago:
Is GStreamer a more secure alternative or does it just get a bit less
attention than ffmpeg?
samiv wrote 12 hours 3 min ago:
Gstreamer is a multimedia framework where the user creates media
DAGs by placing video/audio/multimedia elements such as demuxers,
decoders etc in a pipeline. The framework then takes care of
running the media pipeline and handles the data buffering etc.
Within the framework there are multitudes of plugin packages that
contain said elements and many of them are built on top of ffmpeg.
derf_ wrote 15 hours 51 min ago:
Any multimedia project trying to support a large number of formats,
whose usage in the wild differs by orders of magnitude, is going to
have code of varying quality (although quality is not strictly
correlated with usage: age and complexity are also big factors,
among others). GStreamer puts plugins into different categories
(-good, -bad, etc.) based on things like the maturity of the code,
which helps you judge what risks you are taking. With FFmpeg it is
harder to know which formats are more likely to have issues. Of
course GStreamer can use FFmpeg, in which case you will also have
all of FFmpeg's problems.
In both cases you are best off restricting things to what you
actually use.
hugmynutus wrote 16 hours 0 min ago:
GStreamer is just a different front end to ffmpeg.
ffmpeg's core functionality (encode, decode, streams, pipes,
channels) are all implemented in `libav` which gstreamer links
against.
mort96 wrote 5 hours 27 min ago:
GStreamer is not "just a different front end to ffmpeg".
GStreamer is a pluggable media graph system.
"GStreamer" doesn't link against libav. The GStreamer plugin
"gst-libav" links against libav. If you're not using the
gst-libav, you're not using ffmpeg. I'd bet a relatively small
amount of GStreamer use cases use gst-libav; I typically see
people use e.g x264dec and x264enc (from the x264 plugin) to
decode and encode media, or, for hardware encoding/decoding, the
v4l2enc and v4l2dec elements (or elements from a SoC vendor's
plug-in such as gst-rockchip). It also has its own non-libav
elements to handle container formats, pixel format conversion,
scaling, etc, which are more natural to use since they're part of
the core gstreamer plug-in packages rather than gst-libav.
harrall wrote 15 hours 33 min ago:
GStreamer doesnât use ffmpegâs pipeline at all. It implements
a much more advanced directed graph with disconnect, connection
and pad negotiation. You can dynamically swap out the entire
filter graph during live playback with zero disruption. Swap
feeds, outputs, effects⦠all at runtime.
ffmpeg and other media frameworks (Windows Media Foundation,
Appleâs AVFramwork) only support static pipelines. You can use
âswitcherâ components but the inputs are still static.
GStreamer is extremely special. The only thing that comes close
was Microsoftâs DirectShow, which has since been replaced with
Media Foundation which canât do it. And while DirectShow did
support it, it was fragile because many 3rd party filters did not
support dynamic configuration.
GStreamer does use ffmpeg, but it just wraps the core
encoder/decoder/filter code and discards the streams/graph/pipe
part of ffmpeg.
Sesse__ wrote 12 hours 45 min ago:
> ffmpeg and other media frameworks (Windows Media Foundation,
Appleâs AVFramwork) only support static pipelines.
FFmpeg doesn't do âpipelinesâ. It's a library, not a
framework.
mort96 wrote 5 hours 16 min ago:
It's also a command line tool, where you can design (limited)
media graphs: sources, sinks, filters, encoders, decoders,
muxers, demuxers. You don't express it as directly as
gst-launch's pipeline syntax, but it's very much a pipeline.
wmf wrote 16 hours 43 min ago:
Doesn't GStreamer mostly use ffmpeg plugins?
WD-42 wrote 17 hours 47 min ago:
From what I understand gstreamer is more about building complex
pipelines and plugins, ffmpeg is better at playing some obscure 20
year old video format extremely efficiently so you can watch it
compiled for a potato.
Different cases really I think both are good.
hackernudes wrote 16 hours 58 min ago:
That's not really true. Ffmpeg is a Swiss army knife for anything
related to digital multimedia (old and new). It is broken into a
few libraries but doesn't really have plugins.
Gstreamer has a different model, chaining together plugins. Lots
of overlap, but I think Gstreamer only has real traction because
some silicon vendors use it.
ranger_danger wrote 18 hours 4 min ago:
In my experience it's mainly run by very grumpy and opinionated
Europeans who take pride in having bugs old enough to drink.
naturalmovement wrote 19 hours 18 min ago:
If there was a nearly inexhaustible supply of Indian security
researchers emailing you a nearly inexhaustible supply of LLM slop
daily, there is a point where you or I would stop caring too.
ffmpeg is Free Software. You are also free not to use it.
Oddly enough, despite all these endless grievances, no one has come
up with a better or more capable tool, certainly not one that is
freely available.
Evidently no one cares either, because most implementations of ffmpeg
I've seen typically run it as root "because we have to". Don't worry
we use Docker bro.
bawolff wrote 19 hours 13 min ago:
> nearly inexhaustible supply of LLM slop daily,
Actual well written vulnerability reports are not the same as slop.
AI slop is a real problem and annoying. Just because it exists does
not mean every vulnerability report is AI slop.
Ffmpeg devs are free not to care, but then they cant complain when
they start to get a bad reputation.
krageon wrote 8 hours 34 min ago:
Even before the advent of AI the quality of most reports was
depressingly low. Most of your reports will quite simply come
from folks in lower-wage countries that broadly don't speak
English well and that use a shotgun approach to bug bounties.
That means you are receiving a lot of them, they will be hard to
read (assuming the information you need is in there at all) and
if they get one success out of fifty then for them it is a really
good return.
The advent of LLMs has made this a hundred times worse. Both
because it makes it easier for most people to create reports that
sound good (and so are more effort to dissect) and because people
who didn't have to work hard to get any amount of competence are
usually more entitled and more rude (the stakes are even lower
for them).
It is economically no longer a good idea to run a bug bounty
program at all. I honestly question whether or not even having a
direct input for such things makes any sense anymore. The volume
is becoming so great you need a classical spam filter to plow
through it. But that won't work, because they all sound
reasonable.
naturalmovement wrote 19 hours 7 min ago:
> AI slop is a real problem and annoying. Just because it exists
does not mean every vulnerability report is AI slop.
Ok but who is going to sift through it all to triage the good
bits when you're working on something for free?
> Ffmpeg devs are free not to care, but then they cant complain
when they start to get a bad reputation
Who gives a shit about reputation when you're the only game in
town?
There is nothing out there that even attempts to approximate an
ffmpeg clone. They are the Swiss army knife of media encoding and
all complainers have produced are plastic sporks.
notenlish wrote 1 hour 31 min ago:
Its not as full featured as ffmpeg but I remember hearing about
mediabunny, It's a web native ffmpeg alternative, and according
to its website, seems to be a lot faster than ffmpeg.wasm
bawolff wrote 17 hours 19 min ago:
> Ok but who is going to sift through it all to triage the good
bits when you're working on something for free?
Its like anything else in open source. Maintainers will do so
if they care. Maybe they decide they don't care. That is always
their decision to make but there are consequences for the
project. Maybe those consequences make sense. Being a
maintainer is all about making cost-benefit trade offs.
> Who gives a shit about reputation when you're the only game
in town?
Its up to the maintainers whether they care or not. It depends
on what they value.
Ultimately if maintainers make decisions that are at odds with
what their userbase want, someone eventually forks and people
vote with their feet.
RossBencina wrote 7 hours 18 min ago:
"care" is not a viable metric for prioritising the allocation
of a scarce resource.
dspillett wrote 8 hours 11 min ago:
> Maintainers will do so if they care.
Caring is only part of the problem. If you are inundated by
low quality reports, or many duplicates of what turn out to
effectively be the same problem, that you have to sift
through to find the useful reports, then by the time you have
something actionable you have no time left to take action on
it.
The amount of reports coming in, particularly the low/zero
quality ones, is apparently growing at a much faster rate
than the time volunteers have for dealing with them.
Caring does not magically solve problems without enough
people with enough time.
eipi10_hn wrote 15 hours 36 min ago:
Yes, and people will sit there and sip tea while waiting for
"someone"? For how long?
bawolff wrote 14 hours 27 min ago:
> Yes, and people will sit there and sip tea while waiting
for "someone"? For how long?
Until someone cares enough to do it. This is open source
software. When it comes to open source, the golden rule is
you either do the things you care about yourself or stfu.
Given the libav fork wasn't all that long ago, it can
obviously happen to ffmpeg just as much as it can happen to
any other project.
naturalmovement wrote 17 hours 14 min ago:
Security is a bit different.
Today it's an industry driven by unscrupulous clout-chasers
and a commitment to quantity over quality.
There is a difference between going through patches and pull
requests vs. the endless stream of LLM-assisted bullshit that
has started cluttering security inboxes in the last few
years.
tptacek wrote 16 hours 41 min ago:
Vulnerability researchers don't create the vulnerabilities
they report. The vulnerabilities exist whether or not
they're reported by "clout chasers".
dspillett wrote 7 hours 51 min ago:
There is a difference between a proper vulnerability
researcher and a clout chaser calling themselves a
vulnerability researcher. Research for a start, to assess
the problem to see if it is genuine and if so if there
are significant mitigating factors (by default or that
can be implemented), and checking if it hasn't already
been reported, instead of just copypasting some LLM
output with minimal review. And to many clout chasers
everything they find is a grade A world wrecking highest
possible priority "if you don't drop everything else and
fix this now you are a kitten murderer and I'm going to
release the information to the world in 24 hours" level
issue (they know this because they suggested it to an LLM
and it told them they were so right).
tptacek wrote 5 hours 56 min ago:
No there isn't. The vulnerability is either real or it
isn't. How you feel about the researchers doesn't enter
into it. People angry about vulnerability research have
been making this argument since 1992.
gerdesj wrote 19 hours 23 min ago:
ffmpeg is also rather popular and delivers a lot of functionality.
Its unlikely that you don't have it installed.
Yes, there are security issues but quite a few are not ffmpeg itself
related - the input is pretty shabby or at least not exactly easy to
deal with!
Obviously, they could do with some assistance and I'm sure you and I
will both dive in with equal zeal.
RetroTechie wrote 7 hours 41 min ago:
Hmm.. "shabby input" that makes software xyz fail is a problem in
software xyz itself!
"Validate your inputs" is a common rule. Fuzzing is a thing. Both
for good reasons (including security).
loeg wrote 19 hours 57 min ago:
They're also extremely hostile to security researchers who report
these issues.
dspillett wrote 8 hours 37 min ago:
I wouldn't call "nice find, care to help us fix that?" extremely
hostile. It can be frustrating for open source projects that far
more people want a pat on the back for the identification of a
problem (be it security, performance, documentation, or anything
else) than there are people who have the time and inclination to
help resolve the issue (or ability and inclination to fund the
project so it can more easily find help if needed). The use of LLM
based tools apparently making that pat on the back easier to attain
is going to exacerbate that problem for a while at least.
hsbauauvhabzb wrote 6 hours 24 min ago:
I donât deal with ffmpeg or C/asm, but there are certainly some
4gl applications that a random patch may cause more problems than
it solves. I imagine many researchers would be in that box.
lkt wrote 15 hours 36 min ago:
The guy running the twitter account is incompetent but the actual
devs are a lot saner I think.
I agree it reflects poorly on them though
duped wrote 16 hours 9 min ago:
One dude running an X account is not indicative of a community to
be honest.
That said, that dude has a point. "Researchers" chasing clout with
their names attached to CVEs is kind of ridiculous. Half these CVEs
are missing bounds checks that can be fixed with a patch in as much
effort as writing up the blog post announcing that there was a
missing bounds check.
boomlinde wrote 15 hours 53 min ago:
I guess that the perceived problem from a security perspective is
that they're there, not that they're necessarily hard to fix once
found.
duped wrote 2 hours 44 min ago:
The main beef is the noise created around these disclosures
instead of sending patches to fix the bugs.
grahamjperrin wrote 18 hours 46 min ago:
> ⦠hostile to security researchers who report these issues.
Do you have an example?
lukaslalinsky wrote 15 hours 15 min ago:
I don't have an example, but I know the pattern. You are working
on your software, security researcher finds a bug, it's in your
project, for you it's just another bug, but for them it's a point
on their CV, so they make a theater about it, and expect priority
in dealing with it. It must get tiring if you get many of these.
krageon wrote 8 hours 45 min ago:
I've run a bug bounty program for a relatively large
corporation and you are exactly right. It's worse in open
source, because none of the developers owe a researcher their
time. At least in a bug bounty program you've communicated
willingness both ways already
naturalmovement wrote 18 hours 6 min ago:
I have numerous examples of security researchers being hostile
and impossible to work with (but cannot share them
unfortunately).
insanitybit wrote 19 hours 6 min ago:
[1] Security is the punch line for ffmpeg.
HTML [1]: https://x.com/ffmpeg/status/2039115531744334180?s=46&t=qCS...
stackghost wrote 14 hours 24 min ago:
In their defense, the "rewrite it in rust" crowd can be really
grating.
KPGv2 wrote 17 hours 10 min ago:
Apr Fools Day really is the shittiest day to be online. For one
thing, practical jokes/pranks are just gussied-up asshole
behavior. For another thing, nerds generally SUCK at
information-delivery pranks, which is what the Internet is full
of on Apr 1.
hdgvhicv wrote 12 hours 13 min ago:
Back in 2004 when free email services like hotmail were limited
to 10-15mb, on April 1st the evening standard front page
headline, which I saw in the office around 2pm, was something
âGoogle lunched 1gb emailâ
I couldnât believe they had fallen for an April fools so
hard.
grahamjperrin wrote 18 hours 46 min ago:
I'm glad to see their sense of humour :-)
HTML [1]: https://nitter.net/ffmpeg/status/2039115531744334180
KPGv2 wrote 17 hours 8 min ago:
> Assembly is a human readable version of machine code. It's
exactly the same.
goddamn, and this is a project that prides itself on having
had-written assembly in it
breppp wrote 14 hours 46 min ago:
There's certainly assembly that maps directly to the machine
language bytes, I assume you are talking about the version of
assembly with the high level loop macros
rcbdev wrote 14 hours 26 min ago:
In some circles, High Level Assembly (HLA) is lovingly
called "Mainframe Assembly".
hootz wrote 18 hours 55 min ago:
Oh my god! They are so funny and memeable! gets RCE'd
fizzynut wrote 20 hours 19 min ago:
I find difficult to know how serious the issue is, if it is even an
issue.
LLM constantly confidently giving me this same sounding script with a
"the root cause" and how it "is simple" while being completely
incorrect.
lostglass wrote 17 hours 24 min ago:
Most of them involve very weird and unlikely scenarios and bad
security practices or access to the ffmpeg binaries and being allowed
to run arbitrary commands at an elevated permission.
In and of itself there's not a massive issue from what I can see,
they're entry vectors that can lead to worse situations.
That's not to say they're not serious but if a Russian hacking group
is using one of them it's in conjunction with other exploits or
security flaws. Which is common in practice when it comes to
decoding.
josephg wrote 18 hours 29 min ago:
Its 21 issues. And they've been human validated, as far as I can
tell.
ttoinou wrote 20 hours 25 min ago:
Is the future of defense-against-foreign-agents-on-my-codebase to
subtly hide prompt injections into oneâs codebase that would defeat
agents to find security bugs ?
If the attackers of ffmpeg need to be using such those authorsâ
services to find RCE in popular tools to attack, what the ffmpeg team
needs to defeat attackers is to reduce efficiency of such tools
depthfirst
Davidzheng wrote 20 hours 23 min ago:
No...
wavemode wrote 20 hours 42 min ago:
> At this point the corrupted free pointer is called, and control of
the instruction pointer is ours.
Very serious, though in practice it doesn't sound like this bug
achieves arbitrary RCE on its own (especially in the presence of ASLR).
You would need there to be some writable and executable page of memory
lying around.
skupig wrote 19 hours 50 min ago:
The article glosses over this, but it looks like the next variable in
the struct is conveniently the first parameter to the function, so
you can run arbitrary code with system() or whatever. But, yeah, you
would need some other exploit to defeat ASLR.
jacobgold wrote 20 hours 50 min ago:
I've been using ffmpeg for a very long time, both personally and for
services I've built. Fabrice Bellard is a genius, and the developers
who have taken it so far have made the world measurably richer.
But I can't think of a program more worthy of sandboxing when run with
untrusted input than ffmpeg. It's a huge amount of C dealing with the
most complicated video and audio codecs, which is notoriously
impossible to get completely right.
But it's not actually that big of a problem. I run ffmpeg inside a VM
or gVisor, and the end result is usually a video file that I'm
perfectly willing to play in my browser, where it gets decoded in yet
another sandbox because this shit is hard.
Terr_ wrote 15 hours 58 min ago:
I glumly predict that copyright-holding companies wanting DRM,
"trusted platforms", regulatory capture, etc. will drive some of the
damage here.
Secure sandboxing tends to mean opportunities to make unrestricted
copies.
cyberax wrote 20 hours 17 min ago:
But then you also often need hardware accelerators for encoding, so
you need to use C again.
Gehinnn wrote 20 hours 46 min ago:
What do you mean "video file that I'm perfectly willing to play in my
browser". Isn't it safe to assume that no video file can escape the
browser decoding sandbox?
preg_match wrote 2 hours 11 min ago:
No, browsers have had many sandbox escape exploits related to
decoding.
kjs3 wrote 17 hours 38 min ago:
Isn't it safe to assume that no video file can escape the browser
decoding sandbox?
It's 'safe to assume' it's not. It's emphatically not safe to
assume any mitigation is perfect.
thaumasiotes wrote 20 hours 43 min ago:
> Isn't it safe to assume that no video file can escape the browser
decoding sandbox?
Why would that be safe to assume? If that were a reasonable
assumption, you could just as well assume that it's safe to run
ffmpeg.
Denvercoder9 wrote 20 hours 15 min ago:
I'm not up-to-speed with the current state of sandboxing in
browsers, but in principle it's (on modern operating systems) not
especially hard for them to sandbox the decoding into a separate
process with basically no privileges beyond rendering a video
stream. It's a bit trickier if we're only considering demuxing
and delegating decoding to the hardware, but that's a much
smaller attack surface.
A manually run ffmpeg on the command line does nothing to
restrict its privileges, and its security model has very little
interest in doing so, while browsers very much have.
lostglass wrote 17 hours 29 min ago:
Yeah, then you need to stream content in real time between
multiple processes. And not screw up the licensing.
And get hardware acceleration working...
ttoinou wrote 20 hours 30 min ago:
The parent does argues it is safer to sandbox ffmpeg yes
nemothekid wrote 21 hours 4 min ago:
>The reach of this bug is what makes it serious. Any deployment that
points FFmpeg at an attacker-influenced RTSP URL is exposed: media
ingest pipelines fetching user-supplied stream URLs, surveillance and
CCTV systems pulling RTSP feeds, and transcoding services processing
remote AV1-over-RTP sources
Wow this is actually pretty serious - I'm even surprised its being
published. There are several services where I can imagine this is
exploitable today.
TiredOfLife wrote 14 hours 1 min ago:
ffmpeg has stated many many times that they don't care about bug or
security reports
skupig wrote 19 hours 56 min ago:
You would also need some sort of ASLR leak to make this exploitable
woodruffw wrote 19 hours 16 min ago:
Speaking from firsthand experience: codec and other media
processing libraries are some of the easiest software to find
address leaks in.
(There are a number of reasons for this, not least being that C
makes it very easy to ship partially initialized memory over the
wire.)
lostglass wrote 17 hours 32 min ago:
Speed and security are not good bedfellows. Combine that with
really shitty standards and dozens of years of development...
Oh, and licensing. Licensing is the real killer. I could just
write my own mp3 decoder easily (the format not the file type)
but I'm not gonna risk my company getting sued into the ground by
doing that.
throwaway2037 wrote 9 hours 42 min ago:
> I could just write my own mp3 decoder easily (the format not
the file type) but I'm not gonna risk my company getting sued
into the ground by doing that.
I am confused.
> The MP3 format is now patent-free and requires no
licensing fees to distribute or use. Fraunhofer IIS and
Technicolor officially terminated their MP3 licensing programs,
with all core patents having expired. Anyone can encode,
decode, and distribute MP3 files or software without paying
royalties.
Ref: [1] Ref: [2] Ref:
HTML [1]: https://forum.gamemaker.io/index.php?threads/do-you-st...
HTML [2]: https://www.reddit.com/r/gamedev/comments/5stq8z/mp3_l...
HTML [3]: https://www.audioblog.iis.fraunhofer.com/mp3-software-...
lostglass wrote 1 hour 11 min ago:
Sorry I was painting a broad image. I'm also worried about
copyright infringement, discovery, someone switching to a
different different that requires glpl, etc
woodruffw wrote 16 hours 12 min ago:
I donât think this is necessarily true! Constraints can be
liberating: a language that allows strong encoding of
invariants makes it easier for the languageâs compiler to
optimize.
I agree about long periods of development and difficult
standards, though.
akerl_ wrote 20 hours 26 min ago:
Some people might suggest itâs crucial to publish if youâre aware
of a serious vulnerability, so that people using the software in a
vulnerable way can take steps to mitigate the risk.
bethekidyouwant wrote 21 hours 9 min ago:
How does the browser use it ?unless they mean thereâs a zero day in
libavcodec
fpoling wrote 21 hours 1 min ago:
Browsers run it in a sandbox process together with allocator
hardening. Most of the bugs then are just crashed of the sandbox
Another option is WASM or WASM-style sandboxes if using another
process is undesirable.
johnnythunder wrote 20 hours 48 min ago:
One chained sandbox escape away from compromise.
loeg wrote 19 hours 54 min ago:
Which is of course better than zero sandbox escapes.
ttoinou wrote 20 hours 28 min ago:
Ahah
But are the compiler+OS that runs the ffmpeg executable really a
sandbox ?
fpoling wrote 12 hours 19 min ago:
For executables on Linux there are things like bubblewrap or
firejail. One can also use a restrictive container. But those
are strictly weaker than browser sandboxes.
The most secure way presently is to use qubes-os that allows to
use a very hardened VM to run individual applications.
DIR <- back to front page