💾 Archived View for thrig.me › blog › 2022 › 12 › 09 › w3m-security.gmi captured on 2023-03-20 at 18:24:01. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
w3m's security is not very good; it lacks the pledge and unveil support that Firefox and Chromium have been subjected to on OpenBSD. Even if w3m is restricted with pledge and unveil there is a lot an attacker can do; w3m makes use of system(3) which means /bin/sh must be allowed and that lets an attacker run anything they want.
Or, you custom compile your own w3m that cannot run /bin/sh; in this case w3m must be rewritten to always download files instead of forking them out to an image viewer or whatever. Or, you write custom code with fork(2) and execl(3) instead of throwing who knows what in a string over to system(3). (And the security of image or PDF viewers may not be the best...)
In general, instead of the bad system call
cmd = myExtCommand(browser, shell_quote(url), FALSE);
system(cmd->ptr);
one might instead use
pledge("... exec proc ...", NULL);
unveil("/usr/local/bin/set-buffer-tmux", "x");
...
signal(SIGCHLD, SIG_IGN);
pid_t pid = fork();
if (pid < 0) { // TODO handle error here
} else if (pid == 0) {
execl("/usr/local/bin/set-buffer-tmux", "set-buffer-tmux", url, 0);
_exit(127);
}
which of course is longer, but better avoids an attacker doing something naughty to whatever is in cmd->ptr. With the pledge and unveil that only allows specific commands to be run they cannot run other random programs as easily as they might otherwise.
Back to w3m.
extbrowser will be problematic, though you may still want some means of easily putting URL into the X11 selection or tmux paste buffer; an attacker could probably do lots if allowed to run arbitrary tmux commands, probably less if they can only pipe to xsel, or more if they gain access to the X11 environment directly. Another option might be to log the URL somewhere and then have other tools pull URL out of a known file, but that is not very good on the easy front.
A wrapper script at least will prevent w3m having full access to tmux.
#!/bin/sh
exec tmux set-buffer "$1"
Yet another problem is the external editor, though that might be skipped if you instead do forms in some... larger... browser, or not at all. Otherwise, an attacker could probably do lots, depending on the editor command, which for vi on OpenBSD probably should be `vi -S ...` and obviously not run through the system(3) interface.
w3m is rather distinct; steps here might be to fiddle with the User-Agent and other headers so that w3m looks like some common no-JS browser. This may not help much if the IP you use is always pretty unique?
And remember to remove the ~/.w3m/cookie file now and then.
Note that removing the User-Agent header is bad; a stackoverflow site issued an error, and probably other sites will be problematic as well. Forge something common into the User-Agent field, and try to line up the Accept headers with whatever it is you are faking? What a mess is HTTP.
One downside of this is that you're supporting a custom fork of w3m. I probably should review other command line web browsers one of these days...