Vulnerabilities in various GTK-based PDF readers

Even with the first version, in a technical sense it may have needed to be an absolute path, in a practical sense it did not: if a malicious file exploit.pdf knows it will likely reside at /home/user/Downloads/exploit.pdf and likely be opened by an application with /home/user as the current work directory, it can force an access to /proc/self/cwd/Downloads/exploit.pdf and not need to know the user's name.

> I would go further. There is way too much use of the shell to do things that you could just as easily do by hand.

This is, unfortunately, true. I suspect some languages, and their communities, dragged countless young developers to the dark side. PHP in particular is horrible in this regard. AFAIK, it only added a way to spawn processes without a shell to its standard library with PHP 7.4 (2019!) - and still in a horrible way.
The advice to new developers usually was "use escaping!", which is a fool's errand given the potential of non-standard shells and the existence of Windows. Those developers then carried those patterns to other languages.

As a positive example, Perl makes it very easy to get it right - and young developers usually are also taught to do it right. Assuming $cmd is not attacker controlled, this is safe in Perl on a POSIX system: system($cmd, @args). DOS-lineage systems may need the slightly annoying system { $cmd } ($cmd, @args). POSIX systems can also use this; they have to if they want to override ARGV0.

This is basically fork() + execlp() + wait().

By the way, why not use directly posix_spawn() or posix_spawnp(), they remove need for fork, close what should be closed and the second one even takes PATH into account?

Agreed. Not invoking the shell for anything is a good rule. But it can also be expressed in more black-box terms. If the test suite for all programs routinely tested operation using “bad” filenames, a lot of shell-injection bugs would be caught, though perhaps not all of them (and probably not this one).

system() is indeed a banana skin. Perl provides a second form of that call which takes a list of arguments and doesn’t go via the shell. That could be carried back into the C library. But even with good hygiene making the command, you might still get tripped up by the program’s own argument parsing. A filename beginning - could be interpreted as an option. Libraries like GTK can add their own peculiar command line options, as happened here. So even without shell interpretation, running anything at all is tricky enough to get right.

This code is using g_app_info_create_from_commandline(), not system(), and there doesn't seem to be an execlp()-like equivalent available. That does limit how much a mistake can mess up the parsing, but not enough to avoid passing arbitrary arguments to a program that's not designed for that.

> system(3) is more convenient than fork(2)/execlp(3) (get over it and write the extra 5-10 lines of code).

It's not just fork + execlp. It's also wait, SIGINT, SIGQUIT, SIGCHLD blocking / ignoring (then restoring), waiting for the exit status, etc. Most programmers get all those details wrong 90% of the time.

Also notice that your execlp() may end up calling the shell, too, if execve fails with ENOEXEC (different from plain execl()).

A better idea would be to standardize a function which takes a list of arguments (like execve), and does everything system(3) does <b>except</b> ever calling a shell. Just like the "system" from perl when called with multiple arguments.

> You have some convoluted command line and don't want to do it all by hand (write a very short shell script instead).

That's just kicking the can down the alley. Your "very short" shell script will most certainly be exploitable via its arguments. Nobody knows how to write "secure" shell scripts when their arguments are controlled by a hostile third party.

In that tangent,

You can have bookmarks (highlights), annotations (notes) and collections of them, in pages but also in PDFs in a collaborative environment (comments, users and groups with https://web.hypothes.is/

I found it useful in a research setting where you have to read a number of PDFs and later can't remember where is what.

It's a very cool project not widely known and thought to bring it up. I am not affiliated with them in any way.

even if $browser is already running?

> the only requirement is to place 9 "magic" bytes (%PDF-1.4\n) in the first 1024 bytes of the ELF/PDF

What's the logic behind _not_ placing magic header in the beginning of the file like ELF does?