How can I secure the plugins I load?

Question

Let's say my piece of code scans the directory ./plugins and loads .dlls/.sos with a known symbol ("function" here) in order to extend its functionnality, like this:

main.c

#include <stdlib.h>
#include <dirent.h>
#include <string.h>
#include <stdio.h>
#include <dlfcn.h>

int
main(void)
{
    DIR *dir;
    struct dirent *entry;
    dir = opendir("./plugins");
    if (dir == NULL)
        return -1;
    while ((entry = readdir(dir)) != NULL)
    {
        void *handle;
        char path[PATH_MAX];
        int (*function)(char *);
        if (strstr(entry->d_name, ".so") == NULL)
            continue;
        if (snprintf(path, sizeof(path), "./%s", entry->d_name) >= sizeof(path))
            continue;
        handle = dlopen(path, RTLD_LAZY);
        if (handle == NULL)
            continue; // Better: report the error with `dlerror()'
        function = (int (*)(char *)) dlsym(handle, "function");
        if (function != NULL)
            fprintf(stdout, "function: %d\n", function("example"));
        else
            fprintf(stderr, "symbol-not-found: %s\n", entry->d_name);
        dlclose(handle);
    }
    closedir(dir);
    return 0;
}

This could lead to a major security issue : If my application runs as root, or has admin privileges, that means any unprivileged attacker can execute code as a privileged user by producing a shared object containing a function named as the known symbol (here, function).

What can I do to secure my plugins folder? How can I check if the shared objects I load are secure?

This is a follow-up of this question.

It is a general concern. Security should be in mind of every software developper, be it security of its application or of the whole system. Here, the whole system can be compromised by an attacker because of my code. — Magix, Jan 11 '16 at 14:02
Because anyone could have put it in the folder, including a malicious attacker. — Magix, Jan 11 '16 at 14:04
Send me an email with the URL of your question if you want more. We might even talk on the phone (if you give me some number to call) in French — Basile Starynkevitch, Jan 11 '16 at 14:13

score 3 · Answer 1 · answered Jan 11 '16 at 13:19

The only thing you can do in this case is to only allow a privileged user to write files in the plugin directory.

The moment you call dlopen on an unknown file you have already lost. Notice that you don't even need to call a function from it, a call to dlopen is enough since the shared object can have constructors that will be run automatically wether you want it or not.

You can't check if the shared objects are secure. To do that would be equivalent to solving the halting problem.

score 2 · Accepted Answer · edited May 23 '17 at 11:44

I believe you cannot secure your plugin in the general case. A malicious user could do arbitrary things in its plugin (including emitting some C code at runtime then forking a compilation of it and dlopen-ing, JIT compiling machine code in memory, etc...). Remember that dlopen-ed (or mmap-ed) plugins are sharing the virtual address space of the process running their loading program.

^{My MELT [meta-] plugin for the GCC compiler is doing exactly that: generating C or C++ code at runtime, compiling it on the fly, dlopen-ing it. But it is not malicious.}

Notice that (as answered by Art), dlopen(3) is running arbitrary initialization plugin code (before you do any dlsym to retrieve a function from its "function" name). Read about __attribute__((constructor)) in GCC.

If you are extremely ambitious (years of work, worth a PhD...) you might generate the code of the plugin while doing some code proof or sound static analysis on it.

^{(Since you are like me near Paris, France, look into the works of Xavier Leroy -INRIA- e.g. CompCert, Emmanuel Chailloux -LIP6-, Julia Lavall & Coccinelle -LIP6-; read also about Frama-C & GCC MELT; but understand that there is no silver bullet....; you could send me an email mentioning the URL of your question)}

Read also about the halting problem, Rice's theorem, trusted computing base and proof-carrying code. Your request is undecidable or at least intractable.

You could consider some dual approach: have a trusted procedure to "sign" or "stamp" good plugins (so the sysadmin is in charge of telling that such and such plugin is good), and only dlopen a plugin when it has been "certified" or simply "human-approved" somehow. Perhaps as simple as keeping a (trusted and safe) database or text association between trusted plugin names and their md5 signatures, and computing the checksum then checking that before the dlopen ...

^{A good heuristic when programming is to ask very often to oneself: Am I trying to solve the halting problem? J.Pitrat's blog has interesting insights....}

does it means every single call to `dlopen()` can lead to a security issue ?! — Magix, Jan 11 '16 at 13:58
Yes, of course. Actually, having any kind of function pointer is already a security issue — Basile Starynkevitch, Jan 11 '16 at 13:58
As a side note, verifying that the directory containing the plugins is owned by a trusted user and group and is not world-writable, and that the plugin file is also owned by a trusted user and group, not world-writable, and has exactly one hard link, before opening it, usually suffices. It is still suspect to a race wrt. renaming a parent directory (although you can try to mitigate that by checking all parent directories, too). Most applications (e.g. Apache) use a fixed trusted (or "system") directory in lieu of those checks, though. — Nominal Animal, Jan 11 '16 at 15:27

How can I secure the plugins I load?

2 Answers2

Linked