Re: [FFmpeg-devel] [FFmpeg-cvslog] fftools/graphprint: Now, make it a Killer-Feature!

["softworkz ." <softworkz-at-hotmail.com@ffmpeg.org>]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Rémi Denis-
> Courmont
> Sent: Samstag, 24. Mai 2025 17:55
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] fftools/graphprint: Now, make it a
> Killer-Feature!
> 
> Le perjantaina 16. toukokuuta 2025, 1.19.15 Itä-Euroopan kesäaika softworkz .
> a écrit :
> > of course I understand that.
> > But it isn't constructed from untrusted input.
> 
> You're being ridiculous. `system()` has a long history of causign bugs, many
> of them security related, and many not fixable.
> 
> If you were implementing a command line interface that needs to process
> trusted input like the shell would, you would want to use `wordexp()`.
> 
> As you merely need to spawn a child process, use the `posix_spawn`*`()`
> available, and `fork()` then `exec`*`()` elsewhere. 


glibc's system() implementation is using posix_spawn internally since 2.34 and
before that, it is using fork() and execve() to launch sh.


> We don't want to spawn a
> shell just to start a well-known executable (other than the shell itself).

And yet, exactly the latter is happening, because the code is
invoking a shell script (xdg-open) - it doesn't launch a browser
executable.
Sadly, this has been misunderstood by many - who commented 
without even looking at the code.

Sure - we could invoke the script as an executable - that would
give us a single advantage: we would then supply the html file
path as an argument rather than in a command string. This 
prevents injection attacks that try to escape to the shell,
but that's just one possible attack vector. Just because we 
supply it as an argument to the script doesn't mean it's 
safe. The xdg-open scripts can differ by platform and can have
their own vulnerabilities. And since xdg-open is redirecting
to a variety of applications - from which every single one can 
have its own vulnerabilities, there is not much safety we 
would have gained by that.

It all burns down to this: 

It is our responsibility to make sure that the path we are
passing over is safe. No matter how we are calling xdg-open.

That path is constructed programmatically, it doesn't depend
on user input. It is constructed from the temp folder path
combined with a file name that has a fixed format generated 
from the time of execution.

There has been one comment (can't find it anymore) that I would
call the single most valid comment made in this regard, which 
was about the way how the temp path is determined on Linux,
and that's where I agree that it isn't safe enough in the way
how it was done.


Best regards,
sw

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".