> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@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-requ...@ffmpeg.org with subject "unsubscribe".
