Security Hoop

In w3m, to edit a form textarea,

    ...
    f = fopen(tmpf, "w");
    if (f == NULL) {
        /* FIXME: gettextize? */
        disp_err_message("Can't open temporary file", FALSE);
        return;
    }
    if (fi->value)
        form_fputs_decode(fi->value, f);
    fclose(f);

    if (exec_cmd(myEditor(Editor, tmpf, 1)->ptr))
            goto input_end;
    ...

exec_cmd is some setup and teardown around a system(3) call with the user's editor and the temporary file. This is not good for security, as it allows w3m to execute by default anything. One tentative improvement would be to only allow w3m to execute a wrapper script, something like

    #!/bin/sh
    exec /usr/bin/vi -S "$@"

or some other restricted editor that cannot run arbitrary commands nor read from ~/.ssh and send those files off via internet connections. This is better, but why not disallow w3m from running anything at all?

    if (pledge(
          "cpath dns fattr flock inet proc rpath stdio tty unveil wpath",
          NULL) == -1)
       err(1, "pledge");

Here we need the "proc" (fork) allow so downloads still work, but "exec" is not allowed. This makes it a bit harder for attackers to run arbitrary programs. An attacker can still read various files, but there are also unveil restrictions that very much reduce the access of w3m to the filesystem. An attacker could make DNS and internet connections, though fixing that would require a different browser design that better isolates the "get stuff from the internet" parts from the "try to parse the hairball that is HTML" code, probably via imsg_init(3) on OpenBSD, or differently complicated to download to a directory with one process and to parse it with another. That way, a HTML security issue would have a more difficult time in getting out to the interwebs. However, with pledge and unveil and not doing much in any given w3m instance (so an attacker cannot rummage around in w3m's memory looking for goodies from other pages visited) the security is a bit better than the default, which allows w3m to read all files and run all programs, come what may.

Here's where the hoop comes in: making it difficult to exec an editor (or anything) means that textarea in forms are now broken. The user must instead jump through some hoop. A fairly simple hoop is to tell the user (me, so the UI being bad for ordinary users is irrelevant) what the temporary file is, let them mangle that file as they will, then continue on:

    ...
    f = fopen(tmpf, "w");
    if (f == NULL) {
        /* FIXME: gettextize? */
        disp_err_message("Can't open temporary file", FALSE);
        return;
    }
    if (fi->value)
        form_fputs_decode(fi->value, f);
    fclose(f);

    fmTerm();
    printf("%s\n[Hit any key when done]", tmpf);
    fflush(stdout);
    fmInit();
    getch();
    ...

Granted, I should probably stop reading the Orange Site as that's about the only place I still use HTML forms on the internet in w3m, but we all have our weaknesses.

This trick can also be used when passing things off from an ordinary user to root, or some other account; the first user writes a file somewhere, and then maybe by some filesystem change notification or periodic polling the other process as some other user ingests (carefully!) what the other process wrote. More complicated, but perhaps safer than having the first user simply "sudo ..." some random command, given all the security issues that can be found in random commands, sudo, or allowing the attacker to run arbitrary shell code via some whoopsie or another.