On Fri, May 11, 2018 at 12:14:47AM +0100, Derek Buitenhuis wrote:
> > please correct me if iam wrong, theres quite a bit iam guessing here
> > IIUC the problem is that in your usecase
> > 1. ffmpeg has access to sensitive files
> > 2. one of these files can be opened by an attacker with ffmpeg
> >
On Fri, 11 May 2018 01:49:58 +0200
James Darnley wrote:
> ...
Security in ffmpeg sure is weird. On one hand we get all kinds of crazy
stuff that's supposed to mitigate... something (like whitelists), on
the other hand we get this.
> I haven't tried to stand in the way of other bad changes to ff
On Fri, May 11, 2018 at 12:49 AM, James Darnley wrote:
> I want to argue some more so here you go: it isn't "by default".
Strange definition of default, but OK.
> It gets rendered because you asked for it to be rendered. You asked for
> /etc/passwd to be rendered so ffmpeg did that. It produce
On Fri, 11 May 2018 00:53:16 +0100
Rostislav Pehlivanov wrote:
> On 11 May 2018 at 00:44, wm4 wrote:
>
> > On Fri, 11 May 2018 00:41:20 +0100
> > Derek Buitenhuis wrote:
> >
> > > On Fri, May 11, 2018 at 12:35 AM, Paul B Mahol wrote:
> > > > I do not have time to explain security basics.
On 11 May 2018 at 00:44, wm4 wrote:
> On Fri, 11 May 2018 00:41:20 +0100
> Derek Buitenhuis wrote:
>
> > On Fri, May 11, 2018 at 12:35 AM, Paul B Mahol wrote:
> > > I do not have time to explain security basics.
> > > Get a decent book and read it from a start to an end.
> >
> > Speaking frankl
On 2018-05-11 00:57, Derek Buitenhuis wrote:
>> Disabling demuxers by default does not seem to be a good idea to me.
>
> So rendering arbitrary text files by default seems like a good idea in
> comparsion?
I want to argue some more so here you go: it isn't "by default".
It gets rendered because
On Fri, May 11, 2018 at 12:36 AM, wm4 wrote:
> Experience shows that it's always the obscure features which cause
> security issues. Regarding the bloat: these small things add up a lot,
> and suddenly you have hundreds of demuxers. It's hard to filter them
> out manually, and why make each user d
On Fri, 11 May 2018 00:41:20 +0100
Derek Buitenhuis wrote:
> On Fri, May 11, 2018 at 12:35 AM, Paul B Mahol wrote:
> > I do not have time to explain security basics.
> > Get a decent book and read it from a start to an end.
>
> Speaking frankly for a second: Why do people put up with this sor
On Fri, May 11, 2018 at 12:41 AM, Derek Buitenhuis
wrote:
> Speaking frankly for a second: Why do people put up with this sort of
> crud on this
> mailing list?
Unrelatedly, sorry for the broken linebreaks. Bad MUA...
- Derek
___
ffmpeg-devel mailing l
On Fri, May 11, 2018 at 12:35 AM, Paul B Mahol wrote:
> I do not have time to explain security basics.
> Get a decent book and read it from a start to an end.
Speaking frankly for a second: Why do people put up with this sort of
crud on this
mailing list?
Insult-laden fact-less response. It's in
On Fri, 11 May 2018 00:21:37 +0100
Rostislav Pehlivanov wrote:
> On 10 May 2018 at 23:27, Paul B Mahol wrote:
>
> > On 5/11/18, wm4 wrote:
> > > On Thu, 10 May 2018 16:44:59 +0100
> > > Derek Buitenhuis wrote:
> > >
> > >> These demuxers have probes that mainly probe based on file extensi
On 5/11/18, Derek Buitenhuis wrote:
>> If you think you are fixing security issue you are very wrong.
>
> You've nailed that "saying what you think" part of communication, but
> need to word a little
> on the all important "saying why you think that" part. Keep
> practicing, you can do it. I
> bel
On 11 May 2018 at 00:04, Paul B Mahol wrote:
> On 5/11/18, Derek Buitenhuis wrote:
> >> Disabling demuxers by default does not seem to be a good idea to me.
> >
> > So rendering arbitrary text files by default seems like a good idea in
> > comparsion?
>
> That is useful feature.
> __
> If you think you are fixing security issue you are very wrong.
You've nailed that "saying what you think" part of communication, but
need to word a little
on the all important "saying why you think that" part. Keep
practicing, you can do it. I
believe in you.
- Derek
___
On 5/11/18, Derek Buitenhuis wrote:
>> please correct me if iam wrong, theres quite a bit iam guessing here
>> IIUC the problem is that in your usecase
>> 1. ffmpeg has access to sensitive files
>> 2. one of these files can be opened by an attacker with ffmpeg
>> 2b. This involves the file being p
On 10 May 2018 at 23:27, Paul B Mahol wrote:
> On 5/11/18, wm4 wrote:
> > On Thu, 10 May 2018 16:44:59 +0100
> > Derek Buitenhuis wrote:
> >
> >> These demuxers have probes that mainly probe based on file extension,
> >> and map to codec IDs that render text as video. The result is that
> >> ff
> please correct me if iam wrong, theres quite a bit iam guessing here
> IIUC the problem is that in your usecase
> 1. ffmpeg has access to sensitive files
> 2. one of these files can be opened by an attacker with ffmpeg
> 2b. This involves the file being probed as a supported format
It is "probed
On 5/11/18, Derek Buitenhuis wrote:
>> Disabling demuxers by default does not seem to be a good idea to me.
>
> So rendering arbitrary text files by default seems like a good idea in
> comparsion?
That is useful feature.
___
ffmpeg-devel mailing list
ff
> Disabling demuxers by default does not seem to be a good idea to me.
So rendering arbitrary text files by default seems like a good idea in
comparsion?
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ff
> You web people already have options for the various annoying whitelists.
> Is this not covered by one of them?
As noted in my other reply to Paul, I find it a poor choice to shunt
the responsibility
of good/secure defaults to the user.
As a side note, derisively referring to me as "you web peo
On 5/11/18, wm4 wrote:
> On Thu, 10 May 2018 16:44:59 +0100
> Derek Buitenhuis wrote:
>
>> These demuxers have probes that mainly probe based on file extension,
>> and map to codec IDs that render text as video. The result is that
>> ffmpeg will, by default, happily render, for example, .txt file
On Thu, 10 May 2018 16:44:59 +0100
Derek Buitenhuis wrote:
> These demuxers have probes that mainly probe based on file extension,
> and map to codec IDs that render text as video. The result is that
> ffmpeg will, by default, happily render, for example, .txt files
> as images. This is not exact
On 2018-05-10 17:44, Derek Buitenhuis wrote:
> These demuxers have probes that mainly probe based on file extension,
> and map to codec IDs that render text as video. The result is that
> ffmpeg will, by default, happily render, for example, .txt files
> as images. This is not exactly a good securi
2018-05-10 17:44 GMT+02:00, Derek Buitenhuis :
> These demuxers have probes that mainly probe based on file extension,
> and map to codec IDs that render text as video. The result is that
> ffmpeg will, by default, happily render, for example, .txt files
> as images. This is not exactly a good secu
On Thu, May 10, 2018 at 04:44:59PM +0100, Derek Buitenhuis wrote:
> These demuxers have probes that mainly probe based on file extension,
> and map to codec IDs that render text as video. The result is that
> ffmpeg will, by default, happily render, for example, .txt files
> as images. This is not
On Thu, May 10, 2018 at 6:52 PM, Gyan Doshi wrote:
> On 5/10/2018 11:17 PM, Marton Balint wrote:
>> Maybe it is better if we simply get rid of the "probing" part, so the user
>> would have to explicitly specify the demuxer to use them.
>
> +1
>
> Maybe shift such probes to inside a block and add a
On 5/10/2018 11:17 PM, Marton Balint wrote:
Maybe it is better if we simply get rid of the "probing" part, so the
user would have to explicitly specify the demuxer to use them.
+1
Maybe shift such probes to inside a block and add a new generic lavf
option to set whether such probes are en
On Thu, 10 May 2018, Derek Buitenhuis wrote:
These demuxers have probes that mainly probe based on file extension,
and map to codec IDs that render text as video. The result is that
ffmpeg will, by default, happily render, for example, .txt files
as images. This is not exactly a good security p
On Thu, May 10, 2018 at 5:11 PM, Paul B Mahol wrote:
> I do not like it being disabled by default.
With all due respect, this is not a valid technical argument, in any respect.
> There are options to disable compilation of such modules already.
We should be defaulting to 'safe/sane by default'.
On Thu, May 10, 2018 at 4:55 PM, Rostislav Pehlivanov
wrote:
> Could you send a patch to disable the decoders as well?
> Looks good otherwise.
Yeah, I thought about doing that too. I can add that, though the option
will have to be renamed to something else.
- Derek
__
On 5/10/18, Jan Ekstroem wrote:
> On Thu, May 10, 2018 at 6:53 PM, Paul B Mahol wrote:
>>
>> Against.
>
> Hi,
>
> Thank you for your review.
>
> I would recommend you put a bit more effort into explaining which
> parts you are opposed to. Think of yourself being on the receiving end
> of such com
On Thu, May 10, 2018 at 6:53 PM, Paul B Mahol wrote:
>
> Against.
Hi,
Thank you for your review.
I would recommend you put a bit more effort into explaining which
parts you are opposed to. Think of yourself being on the receiving end
of such comments, how you would like to just get a flat out r
On 10 May 2018 at 16:44, Derek Buitenhuis
wrote:
> These demuxers have probes that mainly probe based on file extension,
> and map to codec IDs that render text as video. The result is that
> ffmpeg will, by default, happily render, for example, .txt files
> as images. This is not exactly a good
On 5/10/18, Derek Buitenhuis wrote:
> These demuxers have probes that mainly probe based on file extension,
> and map to codec IDs that render text as video. The result is that
> ffmpeg will, by default, happily render, for example, .txt files
> as images. This is not exactly a good security pract
These demuxers have probes that mainly probe based on file extension,
and map to codec IDs that render text as video. The result is that
ffmpeg will, by default, happily render, for example, .txt files
as images. This is not exactly a good security practice, an only
makes it easier for potential at
35 matches
Mail list logo
