zerobees
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:https://security.googleblog.com/2014/01/ffmpeg-and-tho
usand-...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.
|
> simjnd
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
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.
|
> > > ftchd
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.
|
> > > sph
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.
|
> > > xboxnolifes
There is a different dynamic between this and
that.
|
> > j1elo
Well this is nothing but an obvious expectation
given the technical level required for doing good
quality contributions, no?I felt this is kinda
like there being a large number of people willing
to send spam email, but a comparatively minuscule
number of people willing to work on ML filters to
block it.
|
> > > simjnd
You could assume that if someone has the
technical level to identify a vulnerability
and how to exploit it, they probably have the
technical level to fix it.In most cases
researchers have no interest in actually
"making the software better" and publishing
vulns is just a way to increase their cred to
land a better job.FFMPEG's position as a well
know very popular open source project means
it's very interesting for this type of
researcher to find a vuln and put their name
on it.It's an exhausting dynamic.
|
> > codedokode
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
Memory safety and critical performance rarely
go together. Big chunk of FFmpeg is written in
assembly to sqweeze most hardware
performance.https://news.ycombinator.com/item?
id=43140614
|
> > > > IshKebab
Sure but it seems like most of these
vulnerabilities are being found in the C
code.
|
> > > > > bybrooklyn
Rust could help with this!
|
> > > > leonidasrup
It would be interesting to see the results
from a fuzzer, developed for FFmpeg style
assembly code.
|
> > > cryo32
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
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.
|
> > > > > krageon
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.
|
> > > > > anoneng
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
> 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".
|
> > > > > > acdha
My point about coreutils was that
they're rarely used in situations
where an attacker can provide
arbitrary input - it's more like
race conditions with code already
running on the same system trying
to escalate access - so what you
need to protect against are things
like race conditions around file
operations or symlink safety.
|
> > > > > IshKebab
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.
|
> > > > > > acdha
Look, I like Rust and ported every
bit of C I used to it a decade ago
but this is not a compelling
argument. The coreutils rewrite is
an existence proof that the typing
system doesn't motivate this class
of error and a moment's thought
would explain why (you'd have to
be very familiar with the attack
patterns to know to create types
like "handle to private file
failing if the name exists" and
they weren't).What could help
would be a modern API implementing
the same patterns that GNU
coreutils evolved over the last 4
decades but that'd be less the
language than the library and it'd
only go so far because some of
those utilities legitimately need
to things which are otherwise rare
in most applications.
|
> > > > codedokode
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
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
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
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
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.
|
> jstanley
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?
|
> > m4rtink
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
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.
|
> > franga2000
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
> 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.
|
> > defrost
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.
|
> > twobitshifter
I'm this video you will also learn that much of it
is coded in assembly! The developers are
prioritizing performance to the extreme, which has
its benefits, but I would expect assembly to open
up the code to a whole world of vulnerabilities.
|
> endofreach
Of course. Everybody knows to rather use the obvious
alternative to ffmpeg!
|
> > dspillett
> the obvious alternative to ffmpegIIRC 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!
|
> preg_match
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.
|
> > nulltype
For the implemented formats, wuffs is safer and
also often faster: https://github.com/google/wuffs
|
> teravor
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
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:
https://git.sr.ht/~q3cpma/ezbwrap/tree/master/item
/profiles
|
> loeg
They're also extremely hostile to security researchers
who report these issues.
|
> > dspillett
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
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.
|
> > insanitybit
https://x.com/ffmpeg/status/2039115531744334180?s=
46&t=qCSkw...Security is the punch line for
ffmpeg.
|
> > > grahamjperrin
I'm glad to see their sense of humour
:-)https://nitter.net/ffmpeg/status/2039115531
744334180
|
> > > > KPGv2
> 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
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
In some circles, High Level
Assembly (HLA) is lovingly called
"Mainframe Assembly".
|
> > > hootz
Oh my god! They are so funny and memeable!
gets RCE'd
|
> > > stackghost
In their defense, the "rewrite it in rust"
crowd can be really grating.
|
> > > KPGv2
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
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.
|
> > lkt
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
|
> > grahamjperrin
> ... hostile to security researchers who report
these issues.Do you have an example?
|
> > > lukaslalinsky
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
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
I have numerous examples of security
researchers being hostile and impossible to
work with (but cannot share them
unfortunately).
|
> > duped
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
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
The main beef is the noise created around
these disclosures instead of sending
patches to fix the bugs.
|
> > > > > boomlinde
If you quietly patch the vulnerable
software it's unlikely that I will
ever hear about the vulnerability. CVE
disclosure is important because that's
how I learn of security problems in
software I critically depend on. It's
not merely a service to the
maintainers, but to the users who
might otherwise critically depend on
vulnerable software.
|
> naturalmovement
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.
|
> > LeoPanthera
You should rethink this kind of casual racism.
|
> > bawolff
> 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
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
> 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 reputationWho 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
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
> 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.
|
> > > > > naturalmovement
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
Vulnerability researchers don't
create the vulnerabilities they
report. The vulnerabilities exist
whether or not they're reported by
"clout chasers".
|
> > > > > > dspillett
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
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.
|
> > > > > > dspillett
> No there isn't.Yes there is,
because:> The vulnerability is
either real or it isn't.this,
exactly: sometimes the
vulnerability isn't, or isn't a
fraction as serious as it is made
out to be because it doesn't
affect any sane configuration. And
the project contributors don't
know this until they've wasted
time looking into it, time that
could be spent looking into actual
serious problems.The extra problem
right now is several people/groups
dropping the same set of
vulnerabilities with not
coordination because they've got
this great new tool to garner
attention and want to be first. So
projects have several things to
look into that turn out to be
exactly the same thing.
|
> > > > > > tptacek
I have no idea what you mean by a
"proper" vulnerability researcher
and I find the concept faintly
offensive. But what do I know?
|
> > > > > > akerl_
Nobody is obligating open source
maintainers to accept or read
these reports.
|
> > > > > > dspillett
Plenty of people will loudly state
that they are irresponsible for
not looking into the reports that
they send, so while that isn't a
direct obligation it is certainly
a punishment, via potential
reputation damage¹, for not doing
so.--------[1] for example, see
comments elsewhere in this thread
saying things like "maintainers
will if they care"
|
> > > > > > akerl_
No matter what you do, there will
be some group of people that
thinks you're wrong.It's up to
each of us to decide which
peoples' opinions we actually care
about.
|
> > > > > dspillett
> 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.
|
> > > > > RossBencina
"care" is not a viable metric for
prioritising the allocation of a
scarce resource.
|
> > > > > eipi10_hn
Yes, and people will sit there and sip
tea while waiting for "someone"? For
how long?
|
> > > > > > bawolff
> 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.
|
> oinoom
Funny, John Carmack was just admiring the creator of
ffmpeg the other day for being a better programmer.
https://x.com/id_aa_carmack/status/2064095424420487226
?s=46
|
> > mjg59
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.
|
> > tptacek
One thing has nothing to do with the other.
|
> > wavemode
Security vulnerabilities are less about
programming ability and more about rigor.
|
> mr_toad
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
I use it in WASM on the client and call it a day. It
works for our use case, but obviously not most.
|
> nerdsniper
Is GStreamer a more secure alternative or does it just
get a bit less attention than ffmpeg?
|
> > derf_
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.
|
> > samiv
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.
|
> > WD-42
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
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.
|
> > hugmynutus
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.
|
> > > harrall
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__
> 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
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.
|
> > > mort96
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.
|
> > wmf
Doesn't GStreamer mostly use ffmpeg plugins?
|
> > ranger_danger
In my experience it's mainly run by very grumpy
and opinionated Europeans who take pride in having
bugs old enough to drink.
|
> cubefox
> 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
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.
|
> > > ReactiveJelly
I think Chromium already does sandbox ffmpeg
in the renderer process because of their "Rule
of Two":
https://chromium.googlesource.com/chromium/src
/+/HEAD/docs/s...Thus:1. Code which processes
untrusted input2. Code written in unsafe
languages like C or C++3. Code that runs
without a sandboxSo ffmpeg should be
sandboxed, same as the network code and GPU
process are sandboxed.
|
> > > > defrost
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 <shrug> 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
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
There are a lot of "Android like"
TVs out there.
|
> > > > > > cubefox
Those are running mainly on Google
TV. Tizen or webOS are also common
but are not based on Android.
|
> > > mr_toad
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.
|
> > anonymousiam
I haven't seen that acronym before, but my guess
is that it's "Re-Implement In Rust", right?
|
> > > erk__
Usually it's Rewrite it in Rust, but both work
I guess
|
> gerdesj
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
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).
|
> imjonse
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
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.
|
guessmyname
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
> 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
I think I'm missing something here. Apple software has
no open source code, how are you suggesting fixes?
|
> > tkocmathla
What?https://github.com/apple
|
> > > dgellow
Also, check
https://opensource.apple.com/projects/
|
> > > rcbdev
I genuinely didn't know about their OSS
efforts, thanks!
|
> > > > Thev00d00
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
Or .. their operating system and
kernels
|