Friday, January 03, 2025
It's more like computer security theater than actual security
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_cmdis some setup and teardown around asystem(3)call with the user's editor and the temporary file. This is not good for security, as it allowsw3mto 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
~/.sshand 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 ofw3mto 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 viaimsg_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.
What I find annoying is the lack of any type of attack as an example. It's always “data from da Intarwebs bad!” without regard to how it's bad. The author just assumes that hackers out there have some magical way of executing code on their computer just by the very act of downloading a file. The assumption that some special sequence of HTML can open a network connection to some control server in Moscow or Beijing or Washington, DC and siphon off critical data is just … I don't know, insane to me. Javascript, yes, I can see that happening. But HTML?
And then I recall the time that Microsoft added code to their programs to scan JPEG images for code and automatically execute it, and okay, I can see why maybe the cargo cult security mumbo-jumbo exists.
What I would like to see how opening a text editor with the contents of an HTML <TEXTAREA> could be attacked.
What are the actual attack surfaces?
And no,
I won't accept “just … bad things, man!” as an answer.
What, exactly?
One possible route would be ECMA-35 escape sequences,
specifically the DCS and OSC sequences
(which could be used to control devices or the operating system respectively),
although I don't know of any terminal emulator today that supports them.
Microsoft did add an escape sequence to reprogram the keyboard
(ESC “[” key-code “;” string “p”)
but that's in the “private use” area set aside for vendors.
This particular attack vector might work if the editor is running under a terminal or terminal emulator that support it, and the editor in question doesn't remove or escape the raw escape sequence codes. I tried a few text editors on the following text (presented as a hexadecimal dump to show the raw escape sequence):
00000000: 54 68 69 73 20 69 73 20 1B 5B 34 31 6D 72 65 64 This is .[41mred 00000010: 1B 5B 30 6D 20 74 65 78 74 2E 0A 0A .[0m text...
None of the editors I tried (which are all based on the command line and thus, use escape sequences themselves to display text on a terminal) displayed red text. The escape sequence wasn't run as an escape sequence.
Another attack might embedding editor-specific commands within the text.
This is a common aspect of some editors,
like vi.
And I can see this being concerning,
especially if the commands one can set in a text file include accessing arbitrary files or running commands.
A third attack could be an attempt to buffer overflow the editor, either by sneaking in a huge download (like say, a file with a single one gigabyte line) or erroneous input (for example, if the editor expects a line to end with a CR and LF, send an LF then CR). Huge input is a bit harder to hide, but suble erroneous input could cause issues.
This is why I feel such articles are bad—by not talking about actual threats they enforce a form of “learned helplessness.”
Everything is dangerous and we must submit to onerous measures to keep ourselves safe.
Sprinkling calls to pledge() aren't the answer.
Yes,
it helps,
but not thinking critically about security leads to a worse experience overall,
such as having to manually edit a file which would still be subject to all three of the above attacks anyway.
By identifying the attacks,
then a much better way to mitigate the attacks could be found
(in this case,
an editor that strips out escape sequences and does not support embedded commands;
and yes, I know I have a minority opinion here—sigh).
And to address the bit about parsing HTML—is parsing really that fraught with danger? All you need to parse HTML is to follow the explicit (and in excruciating detail) HTML5 specification. How hard can that be?
